It’s been a while since my last post on the topic of notifications in Windows 8, so I’m going to pick things back up and cover the two remaining notification options: push notifications and raw notifications. If you’re new to my blog (or even it not), there’s a link list to the right so you can catch up on the other posts.

Personalizing the User Experience

Push notifications are one of the hallmarks of a personalized application experience. The primary difference from the other notification mechanisms discussed so far is that the application itself does not set the delivery schedule. In the push notification scenario, a Windows 8 application is merely a subscriber to a hosted service that is responsible for triggering the notification and sending it to interested parties.

Think of a weather application that alerts you to severe storms in the area or a retail application that informs you when an item you are tracking is on sale. A chat application is another prototypical example; we’re all accustomed to seeing a toast message when a friend wants to get hold of us. In all of these scenarios, a “third-party’ owns the notification context; they decide what is important to send out and when.

How it works

There’s a bit of plumbing involved in push notifications, but the good news is that most of that plumbing is maintained and managed for you.

As you can see from the image below, there are four primary actors, two for which you are wholly responsible and two that are provided by Microsoft as part of the platform:

• Windows Store App: is, of course, your awesome Windows 8 application
• Cloud Service: is a service that you build (or tap into) that is responsible for two things
• keeping track of the devices/users that are running your app
• generating content that will be pushed to a subset (typically) of those users via a tile or toast notification.
• Windows Notification Service (WNS): is a Microsoft-provided cloud service that is responsible for sending out the notification to the targeted clients
• Notification Client Platform (NCP): is a subset of the Windows 8 OS that interacts with WNS and passes the relevant notifications to the app running on the given device.

The other primary element of this workflow is something known as a notification channel, which is a unique URI that identifies a single user on a single device for a single application (or secondary tile).

Here's a closer look at each step of the workflow:

As you can see, Steps 1 and 4 are the only two you have to write any code for, and Step 1 is little more than one API call!

The Cloud Service is as involved and complex as you want it to be, but in terms of the workflow is a black box. As long as it manages the OAuth exchange and provides a tile or toast template to WNS, all is well. I’ll take a deeper dive into Steps 4 and 5 in my next blog post, leveraging Windows Azure Web Sites to host the service.

Design Considerations for Push Notifications

A well executed push notification strategy can make your application become a vital part of your users’ digital experience, encouraging frequent visits to your app. Conversely, a poor execution may have the effect of a car alarm (who pays attention to those any more?) or, worse, result in the user uninstalling your application. While each application’s scenario and user base will have its unique characteristics, there are some common themes to consider when formulating what that experience will be in your app.

Can You See Me Now?

Never, ever assume your user will see a given notification. There are numerous ways that a user may disable notifications or otherwise not receive notifications from your application:

• A user can turn off notifications via the PC Setting option accessible via the Settings charm; she may elect to do this for all applications or on an app-by-app basis.
• Notifications can be turned off temporarily – “quiet time” – via the notifications icon on the Settings panel (see right).
• Applications with notifications typically expose the option to turn notifications off in the application-specific Settings flyout.
• A toast notification that’s initiated while the user is off-line will not be delivered. A tile or badge notification will be cached, but only the latest is retained for delivery unless the notification queue is enabled (in which case up to five notifications can be cached).
• The notification channel can expire (as of this writing after 30 days), and notifications delivered to a inactive channel will be dropped. A best practice is to renew the notification channel for your application each time it is launched and then refresh the directory of channels maintained by your Cloud Service as necessary. If the application might not be launched for extended periods of time, consider using a maintenance trigger to refresh the channel. Consult the Push and periodic notifications client-side sample for code that implements a maintenance task for this purpose.

Delight. Don’t Annoy.

There is no magic sauce here, and the ‘formula’ differs based on the type of application and the expectation of the users; nevertheless, there are a few things to keep in mind.

• Specific and context-sensitive notifications should be delivered as soon as possible, but do remember there is no guarantee they will be seen by the user. There is no directory of undelivered notifications that you can consult, so if there is information you want the user to see, consider backing up that notification with application functionality that will display potentially missed – but still relevant – notifications to the user when they do revisit your application.
• Generic content that’s more broadly delivered, like a stock quote or weather update, should be sent with a cadence of no more than once every 30 minutes. More frequent delivery runs the risk of both annoying the users and having the requests throttled by WNS.
• Consider the context of the application when the notification is received to determine if that notification should occur. A prime example is a toast notification received while the application is in the foreground. In most cases, you’ll want to suppress the notification and just incorporate the content of the notification within the UI as a matter of course. For instance, I don’t want to see notifications of e-mails arriving when I’m in my mail application and can clearly see them appear in my in-box. If you decide a notification should not be presented to the user, your code can cancel that notification via an event handler for PushNotificationReceived.

Be Careful Out There!

First and foremost, don’t transmit sensitive information like passwords or bank account numbers. Beyond that though, note there are at least two publically accessible services involved in the delivery of push notifications: your Cloud Service and WNS.

The connection between your Cloud Service and WNS must be over SSL and is secured via the OAuth 2.0 protocol. The Cloud Service maintains – and must secure – the application’s package security identifier (SID) and client secret. That information is sent to WNS to obtain an OAuth token to make requests to WNS, so if the SID and client secret are compromised a malicious service could initiate push notification to your application’s users.

The connection between your application and the Cloud Service is completely at your discretion. Over that connection will pass the notification channel URIs of your users’ devices along with additional metadata or profile information your service uses to determine which users should receive which notifications. Given the potential sensitivity of that information, it’s also recommended this connection be secured by SSL.

Additionally, you’ll want to ensure the persistent storage location that your Cloud Service uses for the client notification channel URIs and other information is also secure and perhaps encrypted. Each of the notification channel URIs should be validated as targeting the notify.windows.com domain before being acted upon. If your storage is compromised, and a rogue party surreptitiously substitutes an alternative server endpoint, you could unknowingly divulge your application package SID and client secret.

Course Correct.

Consider using HTTP headers and response codes from the exchange with WNS to get a somewhat rough idea of the effectiveness of your notification strategy.

Push notification requests can include an optional HTTP header, X-WNS-RequestForStatus, which, when set to true, causes WNS to include an X-WNS-DeviceConnectionStatus header in the HTTP response with one of three values:

• connected: the device is online and connected to WNS.
• disconnected: the device is offline and not connected to WNS.
• tempconnected: the device temporarily lost connection to WNS (e.g., a 3G connection was lost, or the user turned off the wireless hardware switch on a laptop).

The X-WNS-NotificationStatus response header also has one of three values providing some insight into the disposition of the notification.

• received: the notification was received and processed by WNS.
• dropped: the notification was explicitly dropped because of an error or because the client has explicitly rejected these notifications. Toast notifications will also be dropped if the device is offline.
• channelthrottled: the notification was dropped because the app server exceeded the rate limit for this specific channel.

With X-WNS-DeviceConnectionStatus you may be able to better target when you are sending your notifications by building a profile of the number of connected users at different times of the day.  X-WNS-NotificationStatus can’t tell you how many are receiving the notification, but it can give you a lower bound on how many are being rejected (dropped).

Of course, there’s the HTTP status code of the request to WNS itself, several of which can give some insight into your user base. A 410, for instance, indicates the notification channel is no longer valid, which may mean a user hasn’t run the app recently (or you need to reassess how you are refreshing your client notification channels in code).