Getting ready for the Windows Phone 7 Exam 70-599 (Part 2)

This is the second part of my article series to prepare you for Microsoft's new Windows Phone 7 exam that will be available starting July 14th. For a short introduction and overview of the exam as well as a list of general learning materials please take a look at the first article. The official outline of the measured skills breaks down the topics into the following parts:

• Designing Data Access Strategies (19%) (this article)
• Designing and Implementing Notification Strategies (17%) (this article)
• Working with Platform APIs, Tasks, and Choosers (21%)
• Designing the Application Architecture (21%)
• Designing the User Interface and User Experience (22%)

In the last article we've seen what your data access strategies are, both for remote data as well as local storage. We've also briefly mentioned the limitations of network connectivity on the phone and what features of the platform help you deal with these. In this part, we turn on Push Notifications and surrounding topics.

A note on the MSDN documentation: all online resources in the MSDN library for the Windows Phone documentation are now the pre-release documents for Windows Phone OS 7.1 ("Mango"). The original documentation for Windows Phone OS 7.0 (which the exam is likely based on) can be downloaded for offline use here (CHM format). Often there's little difference or it is likely that the changes have no effect on the exam; however in some cases this might not be the case or there are options available in "Mango" that are not part of the RTM release, so you should carefully compare the different versions, and if in doubt, base your learning on the 7.0 documentation.

Designing and Implementing Notification Strategies

The Microsoft Push Notification Service is a feature in Windows Phone that offers you as a developer the possibility to send data to your application on one or more specific devices. Whether that data is send to your application directly, used to notify the user with a system message ("toast") or to update a tile on the user's start screen depends on how you set up the feature with your application, and also on whether your application is currently running or not. The Push Notifications section on MSDN can be found here. In the 7.0 offline documentation it is located at "Application Features/Push Notifications".

Plan for and implement push notifications in the application

"This objective may include but is not limited to: choose method for notifying user of application’s state/status (tile, toast, RAW); respond to notifications; registration for notifications"

The idea of sending notifications to the phone is simple to understand. However, the involved infrastructure and the architecture of that feature is a bit more complex, and hence it's important to gain a good understanding of it. Basically there are three involved parties:

1. The phone itself. Obviously your application needs to be installed on one or more devices and the feature set up, so notifications can be received and are meaningful to the user.
2. Your own service that does the actual sending of notifications. This can be a service running on one of your servers, the cloud, or even a stand-alone application like in some of the samples (usually impractical).
3. Microsoft's Push Notification Service (MPNS) is the link between your service and the individual devices. Your application has to acquire the necessary information from MPNS so your service can send notifications, and your service in turn sends those notifications to the MPNS to have them delivered to the devices.

From this it becomes clear that there's not direct end-to-end connection between your services and the devices. Instead, the workflow looks like this: in your application (on the phone), you have to acquire a channel from the MPNS that can be used to send notifications to the device. This is an URL which is unique for every device. Your application then needs to send that URL to your own service, where it can be stored for later use. The channel URL can change over time, and it's your application's responsibility to make sure your own service always has the current URL. From that point on, your service can send notifications to that URL (in the form of HTTP posts). This is not a direct connection to the device; instead, you post these notifications to the MPNS, which in turn makes sure it gets delivered to the device. This can happen instantly if the device has a connection, or at a later point in time if it hasn't. Once the notification is delivered to the device, what happens there depends on the type of notification you sent (more on this below). I strongly recommend reading the MSDN overview and the additional articles on Push Notifications that explain this process in detail.

• MSDN: Push Notifications Overview for Windows Phone
• MSDN: Receiving Push Notifications for Windows Phone

Note: Because most samples for Push Notifications include both the sending and receiving side, I'll compile a more complete list of useful links below instead of duplicating the links in the sections for the client and server side.

The Different Kinds of Notifications

There are three different kinds of notifications you can use with your application, all with different requirements and different purposes. Two of them with immediate feedback to the user, and the last one without a visual representation. In your application, you can and have to configure each of these notifications separately.

(Source)

First we have the so-called toast notifications which are similar to the ones you get when you e.g. receive new texts or are notified of wireless networks within reach and similar situations. These notifications are meant to be used with important information that should draw the user's attention immediately and consist of a title and sub title. The small application icon of these notifications cannot be changed. Note that you need to ask the user for permission to use toast notifications and give them the possibility to turn them off in your application settings.

Tile notifications enable you to update your application's tile, which consists of three parts: the background image, the title text, and a counter overlay that can display a number up to 99. These notifications are meant for information that doesn't need the user's immediate attention, but are convenient to be shown without having to open the actual application. For tile notifications, the application needs to be pinned to the start screen.

The third kind of notifications are called Raw Notifications and are arbitrary blobs of data that are send to your application. Raw Notifications do not create any visual feedback automatically, and are discarded on the MPNS server side if your application is not running. The payload size if limited to 1 KB and can be used to push data to your application when it is running, as opposed to e.g. a polling mechanism which would be more wasteful on battery and networking resources.

• MSDN: Types of Push Notifications for Windows Phone
• MSDN: Certification Requirements specific to Push Notifications Applications

Here is an overview of the notification type characteristics:

Plan for and implement push notifications on the server

"This objective may include but is not limited to: when to use toast, tile, and raw; plan for receiving the unique device URL"

Implementing the server side to Push Notifications requires some planning and considerations. The Windows Phone SDK does not provide any framework or out-of-the-box features specific to the required communication between the phone and your service regarding Push Notifications. This of course makes sense, because usually an infrastructure for communication between your application and your services often has already been established, and the platform also offers enough possibilities to communicate with services you can simply use for this. In addition to the obvious requirement to send the unique MPNS URL that identifies and enables sending notification to a particular device to your own service, there are a whole lot more things to take care of, some of which not quite as obvious. Some of these are:

• Establish some sort of infrastructure in your service to maintain the list of devices and URLs, and create the possibility to update those entries when the MPNS URL changes.
• The notification URL is a sensitive piece of information. After all, it enables (indirect) access to a user's device to send information to it. The consequence is that you should treat it as such, meaning to secure the transmission of the URL from the device to your service, and also make sure that the URL is stored in a secured manner.
• For the same reason, you should provide a mechanism in your application that allows the service to "invalidate" an URL, forcing the application to request a new one.
• Consider implementing a so-called authenticated web service. This not only increases security, but also removes some limits imposed on those services that do not implement this feature (like a limited number of notifications per period of time).
• When you send out notifications using the MPNS you don't receive a confirmation that the data has actually been transmitted, but you do get information about whether the device you're trying to send to is currently available and has a network connection or not, and you also do get a detailed response what let the operation fail in case of an error. It is recommended to keep track of this and e.g. throttle the sending of notifications when the device is not available over a longer period of time, or to implement backoff algorithms when the notification queue is full.

Here are some valuable links on MSDN regarding the server side of Push Notifications:

• MSDN: Sending Push Notifications for Windows Phone – Explains all the details of the HTTP posts you need to perform to send notifications, in particular the header and payload formats.
• MSDN: Best Practices for your Web Service
• MSDN: Push Notification Service Response Codes for Windows Phones – Details about the possible response codes when you send notifications, what they mean and how to react accordingly.
• MSDN: Setting Up an Authenticated Web Service – Explains the required steps to enable HTTPS communication and remove the 500 notifications per day per subscription limit.
• Windows Phone Developer Blog: Push Notification Status – Gives a sophisticated explanation of the status codes regarding devices that are returned from the MPNS.
• Windows Phone Developer Blog: Server Side Helper Library – This library makes it easier for you to handle the server side challenges of Push Notifications, and looking at the implementation details helps understanding the concepts at code level.

Common Resources for Push Notifications

The following lists a variety of resources that demonstrate and/or talk about implementation of Push Notifications on the client and server side equally.

• Windows Phone Developer Blog: Understanding Microsoft Push Notifications (Part 2, Part 3) – While the first two parts give insights into the theoretical concepts and architecture of the feature, the last part shows how to implement a sample in code.
• App Hub: Push Notifications for Windows Phone Development – A very sophisticated example including a video walkthrough and source code download; contains theory as well as explanations about creating the service and client, including how to move the service to Windows Azure.
• Channel 9: Push Notifications Jump Start – A video introduction to Push Notifications; Contains references to the weather sample from the Training Kit.
• Andrea Boschin: Understanding Push Notifications – Nice explanation of the different stages and phases of Push Notifications, and sample source code for download.
• MSDN: Code Samples for Windows Phone 7 – Contains three very simple samples for Tile, Toast and Raw Notifications, based on the sample code that can be found in the How-to articles of MSDN.

Create and update live tiles

"This objective may include but is not limited to: update background image, numbers, and text"

In addition to use Push Notifications to update your application's tile, you can also make use of a "shell tile schedule" to periodically update the tile from a service URL. The MSDN page here contains a basic introduction to the topic. Make sure that you don't get confused by the additional content (secondary tiles etc.) that is introduced with the upcoming Mango update. In the version 7.0 offline documentation, you can find the corresponding topic in "Application Features/Push Notifications/How to: Update Your Tile Without Push Notifications for Windows Phone".

The idea is to automatically download a (potentially new) background image for your application from a remote URL either once or periodically. You can also specify the maximum number of times this should happen, and delay the start time if you want. It's noteworthy that just like with Push Notifications, some restrictions apply – you cannot download images bigger than 80 KB, and the download cannot take more than 60 seconds. Also, the minimum allowed interval is one hour, which means you cannot update the tile more frequently than that.

• MSDN: Schedule Tile Updates for Windows Phone 7

Summary

This part of the exam and series was all about Push Notifications and Tile updates. Again, although the idea behind it is simple and easy to understand, the involved technical details require a bit more effort. The best way to learn about it is to study the available samples and try to add new features to them, or build an own Push Notification application from scratch. And even if the upcoming Mango update adds new features that will make it unnecessary for certain application scenarios to deal with Push Notifications, what you learn here is still not in vain. They are and will be one of the fundamental concepts that help provide Windows Phone's unique user experience.