Windows 8 Notifications: Periodic Notifications
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
Badge guidelines and checklist
Sample: Push and periodic notifications
Decoupled 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.
Design Considerations for Periodic Notifications
Special Delivery
When designing your application’s notification strategy, be aware of a few “what if’s” impacting the delivery of periodic notifications:
- The actual notification request will be issued within 15 minutes of the specified interval; therefore, you can’t rely on precise scenarios like a notification being triggered every hour on the hour.
- Content for a periodic notification is delivered only if the client device is connected to the network. If there is no connectivity or there is a problem accessing the URI, that polling iteration attempt is skipped, and the URI won’t be requested again until the next regularly scheduled interval.
- The first periodic notification poll occurs immediately when the registration is set up (via the startPeriodicUpdate methods discussed a bit later ), so be sure the URI endpoint is ready. If it is not, the notification will fail - albeit silently.
Out with the Old
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.
Notification Queue: Five Times the Fun!
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.
The APIs
Constructing the Notification
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.
Registering the Notification
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:
- TileUpdater.startPeriodicUpdate accepts a single URL location for the tile template XML and the frequency of updates (ranging in discrete intervals from every half-hour to every day).
- TileUpdater.startPeriodicUpdateBatch integrates the periodic tile notification capability with the notification queue. The method accepts a list of up to five URIs (containing tile templates) that are independently polled at the same specified periodicity.
- BadgeUpdater.startPeriodicUpdate accepts a single URL for the badge template XML along with the frequency of updates
There is an optional startTime parameter for each of the three methods above. That parameter specifies when the recurring cycle of polling for new notification content begins; however, there is always an initial poll for content right when the method is invoked, regardless of how far in the future the startTime parameter is set.
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.
Unsubscribing to the Notification
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.
Sample Code
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.