Microsoft has release a WP7 recipe called the “Windows Phone Server Side Push Notification Helper”. The recipe consist of a demo application which shows how one can send toast, tile and raw notifications. I’m working on an app which requires toast notifications so I decided to try the server side implementation of the app because it really makes the task of pushing notifications from your server to the phone easy. Here’s the only code you need (after compiling and adding the WindowsPhone.Recipes.Push.Messasges into your project):

var message = new ToastPushNotificationMessage (MessageSendPriority.High) {Title = title, SubTitle = subTitle};

message.SendAsync(uri, OnMessageSent );

Nice and simple. But still I manager to spend almost five hours to get this working. My app was receiving the notifications but only on random basis. Sometimes I got the message, sometimes I didn’t. The only way I managed to receive the message with a 100% success rate was by starting the app, sending the message from the server and then closing the app. After the app closed, I got the notification. But what happened when I tried to send an another message after that? Nothing. The server reported that the device had received the message but it didn’t.

I was completely sure that my client was causing the problem. I think I rewrote the whole code about three times and at one point I was sure that my problem had something to do with the Caliburn.Micro. But no. Creating a new Panorama App from a scratch didn’t help at all and it was acting just like the other app.

And then, finally, I gave up and started looking at the server code. I compared the differences between the recipe’s demo application (which was working nicely all the time) with my implementation and then it hit me: The demo app was passing the MessageSendPriority.High in to the message’s constructor, I wasn’t. And what do you know, after making the change into my server the notifications started working as they should! No more randomness, the notifications are hitting my phone with a 100% success rate.

So what is the MessageSendPriority? It seems to be a wrapper around the "X-NotificationClass” –header. The MSDN says this about the possible values:

// Possible batching interval values:
// 2: The message is delivered ... immediately.
// 12: The message is delivered ... within 450 seconds.
// 22: The message is delivered ... within 900 seconds.

This is how the recipe is calculating the value:

int batchingInterval = ((int)SendPriority * 10) + NotificationClassId;

In my case the NotificanClassId was 2 (meaning ToastPushNotificationMessage). By default the SendPriority was Normal, which represents the integer value 1. So, without setting the MessageSendPriority, the messages are delivered with the batching interval value 12, meaning that the message should be delivered in 450 seconds. 

I’m quite sure that this isn’t working correctly because I’m still missing like 100 messages. And this isn’t only an emulator problem because my actual device is missing the notifications also. So the bottom line is, use the MessageSendPriority.High, or if you’re sending the notifications manually, use the following values in the X-NotificationClass -header:

• Tile notification: 1
• Toast notification: 2
• Raw notification: 3

WP7 SDK contains an easy-to-use ProgressBar-control. Unfortunately it has some design problems, most glaringly the fact it is UI thread bound. So if your UI is busy working on something, your ProgressBar will stop animating.

Instead of using the default ProgressBar, you should always use the so-called “PerformanceProgressBar”, a class and style combination created by Jeff Wilcox. Getting things started with the PerformanceProgressBar is easy, just follow the good instructions provided by Jeff.

Most of the WP7 applications use either the Panorama or the Pivot controls. It seems that you can solve most of the UI requirements by just using these two controls. But, some care should be taken. The pivot control at a first glance may look like a perfect solution for apps where the content must be split across hundreds of small views (think book, where each page is presented by a pivot item).

But beware: the PivotControl is a memory hog. An app with 150 empty PivotItems uses over 55MBs of memory. After adding the pivot items, there’s not much of memory left to add the actual content, when the memory limit of 90MB is kept in mind.

PanoramaControl fares much better in a similar test: An app with 150 empty PanoramaItems use only 21MBs of memory.

Out of the box the WP7 emulator offers a way to monitor some performance aspects of a WP7 app by providing the following counters:

• Render thread FPS
• User interface FPS
• Texture memory usage
• Surface counter
• Intermediate texture count
• Screen fill rate

The counters are turned on by default and can be manually turned off by removing the following line in App.xaml.cs (or by changing the flag to false):

<span style="color: #606060" id="lnum1">   1:</span> Application.Current.Host.Settings.EnableFrameRateCounter = <span style="color: #0000ff">true</span>;

Jeff Wilcox has a great article about the different performance counters and it can be reached from his blog.

What is missing from the emulator is a way to monitor the total memory usage of your application. WP7 app shouldn’t use more than 90MBs of RAM so monitoring the mem usage is crucial. Thankfully, Peter Torr comes to the rescue. He has published a class called MemoryDiagnosticsHelper which adds a total memory usage counter to the application. It’s really easy to use and it blends nicely with the built-in performance counters.

To use the MemoryDiagnosticsHelper, first download it from the Peter’s site. Add the class into your project and then add the following line in your App.xaml.cs, just after the line where the EnableFrameRateCounter is set:

<span style="color: #606060" id="lnum1">   1:</span> MemoryDiagnosticsHelper.Start(<span style="color: #0000ff">true</span>);

And that’s all that is required. Now you can start your application and see the total memory usage.

In the past few week I’ve used most of my development time developing Windows Phone 7 applications. Here’s a warning for those who are using MVVMLight: Its EventToCommand-feature is leaking memory. So, if you have for example a ListBox, don’t use EventToCommand to bind any functions to the items. Using WeakReference doesn’t help.

Here’s couple screenshots from one application where a listbox contains around 800 objects and every object is touchable. When using MVVMLight the memory usage looks like this after a while:

And here’s a picture where MVVMLight is replaced by using code behind event handlers:

Here’s couple related issue reports from the Codeplex:

• http://mvvmlight.codeplex.com/workitem/7512
• http://mvvmlight.codeplex.com/workitem/7293

Except for this issue, I really like the library.