Previously I took a look at incorporating Local and Scheduled Notifications into a Windows 8 application, and with this post I’ll move on to the first of what I consider ‘external notification’ mechanisms – periodic notifications.
Bookmark-worthy References for Periodic Notifications
Periodic notification overview
Guidelines and checklist
Tile guidelines and checklist
Badge guidelines and checklist
Sample: Push and periodic notifications
My loose description of periodic (and push) notifications as ‘external’ or ‘decoupled’ is rooted in the observation that content delivered via periodic and push notifications is not typically initiated or provided by the Windows 8 application itself.
With periodic notifications, the Windows 8 application is a subscriber to content hosted at a URI that specifies the XML template for the tile or badge notification (toast is not supported for periodic notifications). Whatever content is at that URI at the regularly recurring time (from 30 minutes to daily) is what the Windows 8 application will use. It’s up to some 3rd party service or application to update that URI’s content at the appropriate interval - providing information on the daily special at a given restaurant, for example.
When designing your application’s notification strategy, be aware of a few “what if’s” impacting the delivery of periodic notifications:
By default, tile and badge content expires three days after it is received, at which point the notification will no longer be shown to the user. You can tailor the expiry to your application’s unique needs by having the endpoint that serves the notification template include the HTTP response header X-WNS-Expires, with a value set to the date (in UTC) at which point the tile (or badge) should no longer be shown.
Remember that if the device is disconnected when a notification is set to occur, that loop of the notification interval is skipped. Consider, for instance, a scenario where a application has registered for hourly notification updates, but the computer hasn’t been connected to the internet for two days. Without an explicit expiration policy for that notification, the user will continue to see the last received “hourly” notification, which is now 48 or more hours old and may contain stale or even invalid information. It follows that in cases where a generic or default tile is preferred over specific - but stale - content, utilizing the X-WNS-Expires header appropriately can result in a better user experience.
The notification queue can be utilized with periodic notifications as well. To recap, you can enable the notification queue (an action required only once during an application’s lifetime) to permit up to five distinct tile notifications to be in play at any given time. Those notifications will cycle at a pace and order that is managed by the Windows runtime; however, the application can subscribe to different URIs (up to five) as the sources of those notifications. Each of the URIs will polled at the same discrete interval (from 30 minutes to daily), but the content can expire individually at different times since the HTTP response for each URI can include a distinct X-WNS-Expires header.
When using the notification queue – with any type of notification delivery mechanism – the notification template can specify a tag value (a string of up to 16 characters) that differentiates the notifications in the queue. If a new notification arrives with the same tag as an existing one, the new notification replaces the current one with that tag; otherwise, the new notification simply pushes the oldest notification out of the queue.
You might leverage tags, for instance, for an application that displays stock quotes in the tile. If each notification includes a tag corresponding to the ticker symbol, then up to five different ticker symbols can cycle within in the tile. As new quotes come in, that content replaces the previous notification instance for the same ticker (tag). With periodic notifications, the tag value is passed in as an HTTP header, X-WNS-Tag.
Unlike the case with local and scheduled notifications, the Windows 8 application doesn’t have any involvement in constructing the notification, so it’s incumbent on the notification provider to ensure the XML being hosted – wherever it’s hosted – is UTF-8 encoded and complies with the tile or badge schema. Note that toast notifications cannot be used with the periodic delivery mechanism.
Periodic notifications are handled primarily by the Windows runtime; the Windows 8 application merely opts in by calling one of three APIs, two for tiles and one for badges:
By the way, it’s a best practice to refresh the registration for periodic updates whenever your application launches or activates; each call to start a periodic update replaces the current registration.
As you might expect, there are stopPeriodicUpdate methods on both the TileUpdater and BadgeUpdater classes to discontinue the updates; however, the current tile (or badge) will persist until it expires. If you want to clear the tile (or badge) immediately, you can use the clear methods available on the updater classes and/or send a local notification to replace the content.
Also, note that if you want to immediately start subscribing to a different URI endpoint, you can call startPeriodicUpdate (or startPeriodicBatchUpdate) without calling stopPeriodicUpdate explicitly. The new registration will supplant the existing one.
The Push and periodic notifications client-side sample in the Windows Dev Center is a good reference for your own implementation, but in order to run it successfully you’ll need to host your template content on some HTTP or HTTPS URI endpoint.
And guess what – there’s a cloud for that! In much the same way as I showed how you can use Windows Azure storage to serve images, you can use it to house the tile or badge template content – and that’s what I’ll take a look at in my next blog post.