Previous Notification Posts
Leveraging Azure Storage
Using Azure for Periodic Notifications
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.
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.
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:
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.
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.
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:
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.
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.
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:
The X-WNS-NotificationStatus response header also has one of three values providing some insight into the disposition of the notification.
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).