WP7 app development lessons learned: Your app’s HttpNotificationChannel may die without you knowing it

HttpNotificationChannel is the key class at your Windows Phone 7 app’s side if you want your application to support push notifications. For good introductions on the topic I recommend the following links:

• Push Notifications for Windows Phone
• A Really Long Post About the Windows Phone 7 Push Notification System

But one key piece is missing from these articles: The HttpNotificationChannel between your app and the Microsoft Push Notification Service may die (or corrupt) without you nor Microsoft knowing about it. But your app’s end users will notice.

Background

The “canonical” example of setting up a HttpNotificationChannel from your app looks like this:

            channel = HttpNotificationChannel.Find(ChannelName);

            if (channel == null)
            {
                channel = new HttpNotificationChannel(ChannelName, ServiceName);
                channel.ChannelUriUpdated += ChannelUriUpdated;
                channel.Open();
            }
            else
            {
                RegisterForNotifications();
            }

Basically this means that the first time the app asks for HttpNoticiationChannel (by calling the Find-method), it won’t get anything back so it will create a new one. After this the calls to Find-method will return the available channel.

The problem

The problem is that HttpNotificationChannel.Find may return a channel which doesn’t work anymore. The push notification recipe released by Microsoft bypasses the the subject by stating the following:

We highly recommend that you open (or create) the PN channel and send the push channel URI to your web service each time you initiate the application. Sending the URI every time your application starts, ensures that your web service has the latest URI for your phone.

The recipe points out the example implementation of this (PushContext.cs, Connect-method):

                // First, try to pick up an existing channel.
                NotificationChannel = HttpNotificationChannel.Find(ChannelName);

                if (NotificationChannel == null)
                {
                    // Create new channel and subscribe events.
                    CreateChannel(prepared);
                }
                else
                {
                    // Channel exists, no need to create a new one.
                    SubscribeToNotificationEvents();
                    PrepareChannel(prepared);
                }

But even this example presumes that the call to HttpNotificationChannel.Find(ChannelName) will return a working channel. My instinct on the subject is that the Find-method will always return the channel which has been created by calling the Open-method of HttpNotificationChannel, when the connection has been created in the first place. The Find-method doesn’t check if the channel is actually available or usable.

The solution

The solution to this problem is actually quite easy: The Close-method of HttpNotificationChannel will remove the known association between your app and the Microsoft’s site, making the next call to Find-method return a null, allowing you to create a new channel.

Conclusion

My recommendation is to call the HtppNotificationChannel.Close every time your app is closing. This way your users will get a fresh channel every time they start the application. It’s just up to you as a developer to keep track of the device’s current channel’s uri.