Windows Notifications Demystified

Users only spend a limited amount of time in our apps; anything we developers can do to invite them back into our apps increases user engagement. One of the best tools for doing this in Windows Store apps are notifications such as toasts, tiles and badges. We can trigger timely and appropriate notifications from outside (mostly from a cloud service) for Windows Store app users, even when our app is not actively running. The goal for using things like live tiles, badge updates and toast notifications is simple: keep the user feeling connected and engaged to your app. In this article, we take a closer look at Windows Store app notifications and Push Notification architecture, laying the groundwork before we look at how to trigger such Push Notifications from cloud services. Let’s dive in.

Notification Types

Tiles

App Tiles are the front doors to your Windows Store apps, and your first opportunity to make a good impression with the user. Tiles are the representations of your app on the Windows Start screen and, most commonly, the launch pad of how the user starts your app. So, a well-branded app tile with pertinent information invites the user into your app. Tiles come in several sizes, and can display text, images, app branding and notification badges. A sample assortment of tile types is as below.

The anatomy of a tile is based on a non-extensible set of Windows-provided XML templates, as defined in the Tile Template catalog. This is an exhaustive list where each template provides an unique way to present a mix of text and images in varying sizes, based on how the user may have the app tile configured on their start screen. Tile templates can be static or peek; the contents of a peek tile scrolls up and down within the tile space to display the full communication, while static tiles are fixed. A quick sample of a named Tile template, along with the XML needed to construct the tile is shown below.

As we talk Push Notifications later, let’s remember the Tile Template catalog – a large assortment of Tile notifications that can be used to entice the user back into our app. Also, tile notifications can be cycled, automatically rotating through up to five current notifications on the tile, using notification queues.

Secondary Tiles

If the user experience of diving directly to a certain section of the app is beneficial, developers have the option of offering the ability to pin a separate tile on the start screen, called the Secondary Tile. Each Windows Store app decides which content to offer for pinning, but the user chooses whether the secondary tile will be created or deleted; this cannot be controlled programmatically. Secondary tiles allow the user to personalize their start screen with the experiences they use the most, like specific cities for a Weather app or catalogs in a News app. Secondary tiles are different from the main app tile and can receive notification updates independently, still adhering to the Tile Template catalog guidelines. When the user launches an app from a Secondary tile, an activation context or deep link is provided, so that developers get to direct the user experience to a specific part of the app.

Badges

Badges often convey summary or status information specific to your app. They appear on top of the live tiles and may often be confused as a part of the tile itself. Badges, however, stand on their own with matching schema templates and can be updated independent of the app tile. Badges show up usually in the right bottom corner of the tiles and can often be the reason users tap/click on a tile.

A badge can convey either a numeric value from 1-99 or a Windows defined glyph. The numbers are often used to provide information that can be counted, like the number of unread messages in an email app, for instance. The glyphs are non-extensible and provide summary information like social media availability or media playback controls. Two sample badge updates, one with numeric value and the other with a glyph, are shown below.

The available glyphs for use with Windows are shown below, along with their XML equivalent in the badge template.

Toasts

A Toast notification is a transient message shown to the user that contains relevant, time-sensitive information and provides quick access to related content in the parent app. It is like an invitation back into your app. Now, unlike tiles or badges that only show up in the Start screen, a transient toast notification shows up in the top right corner (or left based on the globalization settings) of the user’s screen, irrespective of what the user is up to anywhere in Windows. So, toast notifications can be quite powerful to draw attention, but this calls for restraint as the user has the option of enabling/disabling toasts at any time.

An sample assortment of possible toast notifications is shown below.

Just like tiles, toasts can contain a combination of text and/or images, as per the pre-defined anatomy listed in the Toast Template catalog. A sample toast notification along with the XML template is shown below.

Toasts can optionally be of longer transient duration, be scheduled at specific and recurring times or play sounds upon arrival. In short, toasts are a very powerful notification mechanism in Windows that immediately attracts the user’s attention, with an invite back into the parent app.

Notification Delivery

Now that we talked about all the different notification types supported in Windows Stores apps – namely tiles, badges and toasts, how does one fire up these notifications? Let’s look at options we have as developers to deliver such notifications to our app users. There are four:

1. Local – local updates necessitate that the Windows app is being run by the user, and generates a notification update from inside the app. There are well-defined APIs in Windows that allow developers to send out such notifications while the app is running. This works for all of tile, toast and badge notifications.
2. Scheduled – scheduled updates are similar to local, except that the notification delivery is scheduled in future at a precise date and time. This works for tile and toast notifications.
3. Periodic – periodic updates set up a periodic schedule where an external URL source (website or cloud service) is polled at defined intervals to pull down the latest content for notification delivery. This works for tiles and badges.
4. Push – This is the truest form of external content/notification delivery mechanism, since nothing is initialized from the client Windows app. It involves your service, performing a handshake with the Windows Push Notification Service (WNS) to route notification messages to subscribing clients. This delivery mechanism can happen at any time (ideal for real-time scenarios), and works with tile, badge or toast notifications. We’ll take a deeper look at Push Notifications next.

Push Notification Architecture

There are couple of steps involved for developers to enable push notifications in their apps. The Push Notification architecture is represented in the following figure:

My good friend Jeff Blankenburg uses the following real-world scenario to describe how the push notifications architecture works:

Say you got a new house. What’s the first thing you do? You head over to the Post Office to get yourself an address. Next, what good is you knowing the address of your own home? So, you immediately inform your family/friends of your new home address – may be even ask for house-warming gifts. Now, your family/friends acknowledge your new address; but when they need to send you a package, they do not often swing by your house in person. Instead, they normally send the packages to the Post Office asking for delivery to your house address, which in turn, sends out postmen to deliver the packages.

This is very similar to what goes on to empower Windows Store apps with push notifications from the cloud. Here’s a breakdown of the steps involved (the step numbers relate to the figure above):

• Steps 1,2,3 – Your Windows Store app needs to get a unique identifier (the home address) for the device it is running on. The app requests for a unique identifier from the Windows Notification Client Platform, which conveys the message to the Windows Notification Service (WNS) asking for a Notification Channel. The WNS is the Post Office in this story. Upon request, the WNS generates a unique URI as the Notification Channel that identifies the given Windows app on the user’s given device and returns the URI to the caller.
• Step 4 – Next, a Cloud service (family/friends in our story) comes into the play, which is the backend companion to your Windows app. While there are Backend-as-a-Service offerings, this really can be any service that is internet facing. This service however, needs to know about the unique Notification Channel URI for each app subscriber, so it knows where to send the push notifications.
• Next, the cloud service needs to do a little handshake (per OAuth 2 protocol) with WNS to authenticate itself. Our Windows app is obviously registered with the Windows Store, thus receiving a Package Security Identifier (SID) and a Client Secret key.  This needs to be shared with the cloud service, so that it can identify itself while talking to WNS. In return, WNS provides the cloud service with an Access Token, which is to be included in all future communication until the token expires.
• Step 5 – When the cloud service has something important to share with the client Windows Store app, it sends a request to WNS including the payload of the message. What does a notification payload look like? Yep, this is where we go back to the Tile/Toast/Badge template catalogs and choose what’s appropriate. This request to WNS requires authentication through the access token provided before and is in the form of an HTTP Post request at the unique client Channel URI.
• Step 6 – WNS receives the HTTP request containing the notification payload and routes it to the appropriate Windows client device.

Conclusion

In this article, we reviewed the various notification types and delivery mechanisms for keeping your Windows Store app users engaged. We also took a closer look at the architectural pieces behind getting Push Notifications to work for Windows users. Overall, there are lots of choices for developers to keep their users feeling connected to their app at all times. With the stage set, I’ll cover more details on implementing push notifications from the cloud in upcoming articles.

Also, if you are building Windows 8.1 apps in HTML or XAML, Telerik UI for Windows 8 offers a robust toolset of controls and framework pieces. Give the free trial a spin today!

Note: Many of the images used in this article are courtesy of Microsoft.