Windows 8 Notifications: Overview
Hopefully you’ve had a chance to experience Windows 8 – Windows reimagined – by downloading the Windows 8 Release Preview, but even if you haven’t gotten your hands on it yet, it’s clear that more than any other release, Windows 8 enables an intensely personal experience.
Clearly Windows 8 design with its touch-first philosophy are front and center in creating that personal experience, but just as important is how your application proactively interacts with your users, keeping them informed of changes in application state like, say, the arrival of a new social media update. As you build applications for the Windows Store, consider ways your application can anticipate and thereby delight your users by using key paradigms such as tiles and notifications.
There are two primary dimensions in which to classify notifications : the user experience and the delivery method.
User experience
Toast notifications aren’t really new; you’ve undoubtedly seen them in Microsoft Outlook or perhaps your favorite social media client application. They are designed for time-sensitive delivery of personalized content, an instant message from your friend, for example. They typically indicate a feature or event you should attend to in a running or idle application, and clicking on the toast should launch the application into an appropriate context for the given notification. Keep in mind though that toast notifications can be missed or completely turned off by the user, so they shouldn’t be considered a guaranteed delivery mechanism.
Tile notifications are reflected on the Start screen, so are generally more useful for notifications to applications that are not currently running (since the user wouldn’t likely see the Start screen while already in your application). Tile notifications are what gives Windows 8 and Windows Phone applications their distinctive ‘glance and go’ characteristic – you can quickly read the subject line of your latest e-mail, see the current weather conditions, or check how your favorite stocks are faring without even launching an application!
Badge notifications can be thought of as a specialized type of tile notification. The badge refers to one of eleven glyphs or a numeric counter with a value from 1 to 99 that is displayed in the lower right corner of a tile. The numeric badge notification on the Windows Store tile (see left) indicates how many applications have updates available. For a media player, you might use various glyphs to indicate whether the player is paused or playing.
Raw notifications don’t have a direct user experience and are instead used to run a background task on behalf of an application while that application is not running. Applications that deliver regular content may choose this approach to ‘prime the pump’ by downloading the next article to local storage so when the user subsequently runs the application she doesn’t have to wait for content to be delivered. Actually, she wouldn’t even need to be on-line since the desired information would have already been downloaded!
Delivery Method
Local notifications are triggered by a running application and used to inform the user immediately of some change in the state of the application or perhaps new content of interest, which the application itself is responsible for generating or discovering.
Scheduled notifications take local notifications one step further by enabling the developer to indicate that a given notification should be delivered based on the time of day; the canonical example is a meeting reminder. Note that the application doesn’t need to be running for a scheduled notification to appear.
Periodic notifications are ostensibly scheduled notifications that recur at discrete intervals (ranging from every half an hour to daily); however, they differ in that the content for the notification is hosted on a URL endpoint that is then polled at the desired interval. Periodic notifications keep the user abreast of events that are generated externally, with the implication that such events occur at a regular interval, and intermediate changes are not critical to relay.
Push notifications are the most powerful and decoupled of the notification mechanisms, but they are also the most complicated architecturally. By leveraging the Windows Push Notification Service, push notifications enable delivery of notifications to your application at a pace not determined by the application itself, but rather generated from your own or third-party web services that manage and deliver the content.
Take a look at the following chart for some sample use cases, and note that not all notification types are available for each delivery method. For example, raw notifications really only make sense when another service is pushing content to your application. I’ve also included a row indicating which delivery methods require the application to be running (only local does). The Content Source refers to how the notification content is generated. In local and scheduled notifications, the content is assembled by the application, perhaps via its own processing or by polling external services; periodic and push notifications rely on external services to supply data to your application using a pull and a push metaphor, respectively.
Local | Scheduled | Periodic | Push | |
---|---|---|---|---|
Example Use Case | ||||
Toast | show newly unlocked game badge | “15 minute warning” appointment reminder | show instant message chat invitation | |
Tile | update high score game tile | show high/low tide times | display daily lunch special | display friend’s latest social media update |
Badge | reset number of unread messages | update commute time (in minutes) for favorite route | update number of e-mail messages | |
Raw | download latest version of product catalog | |||
App must be running? | yes | no | no | no |
Content source | internal | internal | external | external |
Over the next several articles I’ll take a closer look at how to set up the various types of notifications as part of your application. I’ll start with some of the common programmatic concepts and then look more specifically at local and scheduled notifications, periodic notifications, and finally push notifications. Depending on the user experience and nature of the application you’re writing, you may choose to leverage one or more of these delivery methods within the same program.
Comments
Anonymous
February 05, 2013
Hi Jim, thanks for the great article, i have one question though - which notification services might have been used to display notification such as auto play, family safety etc. the reason i ask is i do not seem to turn the notification off and it does not get displayed under PC Settings.Anonymous
February 05, 2013
I do not know for certain, but would suspect those are not going through the same notification engine as regular apps do, even though they may expose themselves similarly.Anonymous
February 22, 2013
Is there a way to view all my scheduled notifications? Where are they stored in the system? CheersAnonymous
February 24, 2013
Arsany, the ToastNotifier and TileUpdater classes each have methods that you can used from within an app to enumerated the scheduled notifications (and perhaps delete them), but that would be on an app by app basis.Anonymous
February 28, 2013
Hi Jim, I'm looking for a pattern that will allow me to have a running app that is "listening" for events from external sources which then causes an action in the app. i was looking at some combination of a windows service running on the win 8 device that exposes a url. The external device calls the url. When the url is hit, it raises some sort of event that the app can respond too. e.g. load a page in the app, not a toast / tile type event. This looks like some combination of a RAW app running event. would this work ? Do you have any suggestions ? TIA B...Anonymous
March 04, 2013
Bruce, It's close to a raw notification, but that involves background tasks which require the user give it 'special status' on the lock screen, something you can't really control or count on. If the device exposes a URL that would seem to expose an attack vector and/or involve firewall negotiation, etc., not to mention you can't really implement a windows service as part of a Windows 8 store application. Opening a socket might be an approach as well. What type of app experience are you trying to convey - it might help to have a more concrete example (presuming that's something you can share).