Yesterday, Kevin Marshall wrote a blog post  with a good developer tip: to code defensively for the 15 application limit in push notification. 

I know the post was well intended (as a developer tip) and fair criticism (to platform limit); but a few people got confused or misinterpreted and we ended up with tweets or posts that said “Windows phone allows only 15 live tiles”, or “you must uninstall apps to free tiles”, etc..

Here are a few details you might care to know, so you can plan your app and be a good citizen:

• Yes, the limit is fifteen third party applications can be concurrently subscribed  to receive push notifications (whether that is a live tile or toast).  Parsing it out, the applications that come out of the box (like outlook, people hub, etc.) will not count towards this limit.    So there is no limit on 15 live tiles.  You can have 20+ if you add it up (that is about 2.5 screens worth of tiles on star menu)
• An application is only counted if it has push notification or tiles push enabled and is subscribed to a channel.  If you install an application but you do not enable push, it would not count towards the limit.
• You should not have to go uninstall an application in order to free a slot.  If an application is coded well, it should be prompting users and giving them the option on whether they want to use push notifications and/or live tiles (since there is potential bandwidth charges from the operator when these are pushed).   if the user never agrees or it unchecks the box to subscribe, the application should free the channel; there fore uninstall should not be required.
• Applications that use just scheduled tiles updates do not count towards the limit. If that is all you need be a good citizen and
• If an application subscribes for tile updates, and is never pinned it unfortunately does count. Again, we count the channels.

To handle the error, as Kevin pointed out it is just a matter of listening for the exception, and right error message.  Then prompt user to turn-off push notifications in another app.   There is no API to list the applications using it – and I have not heard of a plan for this API –.

Is the limit too low, Kevin wonders.  Obviously there is no perfect answer as it varies by user. I do know that the product team did research on types of apps, categories, how many a typical user would pin, enable push, etc. and they went with 15 for v1, so it is not an arbitrarily low number.   I saw the data and it made good sense to me.  I also hear that the limit can increase later, as we get more apps and better data.  Full clarification, “can increase” only means we are constantly evaluation. it does not mean the next update will have this limit increased. Nothing to announce.  

Again, the key there is the planning was done for typical users. As developers, we tend to install more apps, and often enable the features just to try them out, but we are also power users that know when and how to turn these off.   On the rest, we will have to trust (and hope) that the data the researchers and planners had for typical users holds us until the limit is increased.

Why is there a limit?  The usual thrive to ensure there is a great user experience, good battery life, quality of service on back-end and front-end, bandwidth (cost) , etc.  Limit will increase as we get right data on how people use push, impact, etc.  Kevin’s feedback on there not being an API to enumerate all push apps is still valid.  I know the product team has heard it (from Kevin, me and others) so I hope that gets addressed or the limits go high enough that the problem becomes a moot point.

Hope that helps. 

My take,  when it comes to push,

1. Don’t panic, code your app to take advantage of the platform. Tiles and push can be a nice differentiator for an app.  Let the user decide (15 is still a good number for average users).
2. Code defensively against this limit. it is not hard (though mitigation prompt to the user is not perfect, but it does leave them in control )
3. Prompt your users and ask if they want to use push, and if you are using live tiles give them the option to turn tiles off too..  If user opts out of both, free the channel.

Happy Windows Phone coding!

I am writing this tiny demo app, that has a TextBox data bound to a ViewModel. 
I want the TextBox to fire notifications to the ViewModel whenever the text changes (as opposed to only firing notifications when the textbox loses focus).
In WPF, this is trivial to do, you just set the UpdateSourceTrigger on the Binding to PropertyChanged  (in fact, I think that is the default).
On the phone, I only see UpdateSourceTrigger supporting:

• Default (which for TextBox appears to be LostFocus ) and
• Explicit.  Which is just telling me to man-up and do it on my own logic.
  No option for PropertyChanged.

What to do? 
[12/5  (Update part 1) -- Updating this post due to enough feedback that the semantic of TextChanged is better than my post’s KeyUp.
I did try that before suggesting KeyUp on my original post but I was seeing TextChanged fire more often than KeyUp (aka more times than I felt necessary).
Now that I have seen there is no big perf hit (since others are doing it with TextChanged) I am back to proper semantics.
Also you made me second guess and I tested on a keyboard and noticed that arrows can even the score firing KeyUp events. 

How about:

1. Setting the UpdateSourceTrigger to Explicit 
2. Listening to TextBox TextChanged event, then firing the explicit update?

Here are the snippets:
In my XAML,

   1: <TextBox x:Name="empIdTextBox" Text="{Binding Id, Mode=TwoWay, UpdateSourceTrigger=Explicit}"                    

   2:             TextChanged="empIdTextBox_TextChanged"/>

   1: private void empIdTextBox_TextChanged(object sender, TextChangedEventArgs e)

   2:     {     

   3:       TextBox box = (TextBox)sender;

   4:       BindingExpression be = box.GetBindingExpression(TextBox.TextProperty);

   5:       be.UpdateSource();

   6:  

   7:     }

   1: public class UpdateSourceOnTextChangedBehavior : Behavior<TextBox>

   2:   {

   3:  

   4:     protected override void OnAttached()

   5:     {

   6:       base.OnAttached();

   7:       this.AssociatedObject.TextChanged += this.OnTextChanged;

   8:     }

   9:  

  10:     private void OnTextChanged(object sender, TextChangedEventArgs e)

  11:     {

  12:       BindingExpression be =

  13:         this.AssociatedObject.GetBindingExpression(TextBox.TextProperty);

  14:       be.UpdateSource(); 

  15:     }

  16:  

  17:     protected override void OnDetaching()

  18:     {

  19:       base.OnDetaching();

  20:       this.AssociatedObject.TextChanged -= this.OnTextChanged;

  21:     }

  22:   }

   1: <TextBox x:Name="empIdTextBox" Grid.Column="1"                 

   2:                 Text="{Binding Id, Mode=TwoWay,UpdateSourceTrigger=Explicit}" > 

   3:          <interactivity:Interaction.Behaviors>

   4:            <local:UpdateSourceOnTextChangedBehavior />                             

   5:          </interactivity:Interaction.Behaviors>          

   6:        </TextBox>         

Yesterday I did a dry-run of my performance talk for today’s Silverlight fire starter.

Conclusion was that the talk is like drinking from a fire-hose. It is tight for 45 minutes, but the content is good and we could not agree on what to cut. It was all too good and useful to cut stuff.  

So,  I am going to cheat   and give you an early preview and a guide to make it easy to follow along.

• Here is the deck (might get a few edits between now and 4:30 PM)
• Here is a cheat-sheet. It is in draft mode. It is incomplete, but if you are a beginner, it should help get you through my 86 mph talk. I  will be updating it and completing it as we go in next few days.  Expect an update over the weekend ( booked tomorrow and hopefully partying with firestarter folks tonight).  Full disclaimer, this is a stream of consciousness draft, very rough, not even spell checked (just realized the latter, but have already published in sky drive).
• Here is the sample code.

Join me today at 4:30 PST. Live at Silverlight fire starter. 
if you can’t make it, check later for final document, including a part 2 and the video recording.

Happy Windows Phone coding!