Updated November 8, 2014 12:09 am - The concept of push notifications (PN) is not new and is used by others in the industry. With that said, the Microsoft PN (MPN) service includes a cool twist that gives developers the power to create the impression that their application is always connected by displaying relevant information even while not running through the Live Tile displayed on the Start Screen. But before I dive into the guts of MPN, let’s explain what PNs are and why we need them.
To better understand PN, we need to remember that the end user experience is the first and foremost characteristic of Windows Phone (WP) design. A positive end-user experience is the number one WP design goal. This tenet has major implications for how WP works, not just in terms of its new UI and the interaction model it drives, but also with the application platform (the API for developers). Push notification is one obvious mechanism to ensure a coherent and deterministic end user behavior that allows you to communicate with the end user even when your phone application is not running on the phone.
“OK, all this is very nice, but why do we need PN in the first place?” you ask.
The answer is simple. The WP application model doesn’t allow you to write code that will run in the background while another application occupies the foreground (in other words, it does not allow 3rd party multitasking). But there are a growing number of “always connected application” scenarios that require background services to listen for changes and events. Come to think of it, most phone applications today have some network-related feature, whether updating scores and achievements in games, grabbing and displaying content from the cloud, or the latest trend, social applications.
The common denominator of all these scenarios is that each of them has a Web application or cloud service (we’ll use the term cloud services to include Web applications) that needs to communicate with the phone in order to notify the user that something of interest has happened. In general, if you want your application to be able to listen for updates and messages from the cloud, you have a few options. First, while your application is running in the foreground, you can poll the cloud service. Second, while your application is not in the foreground you can run a background service with a piece of code that will continue polling the cloud service and will awaken your application, bringing it back to the foreground when it’s needed.
Both options are expensive in terms of battery usage for the simple reason that you are using the radio transmitter – either 3G (or similar) or Wi-Fi – to communicate with the cloud service. Either way, you are using a lot of energy on a device that has relatively little energy (small form factor, small battery). However, the first option is somewhat limited in time and scope, so we can live with it, as its impact on battery consumption is somewhat limited. The real problem lies with the second scenario, where your code is running in the background, potentially 24×7, and slowly but surely draining the battery dead, leaving the user with a useless phone in the middle of the day. And here is the catch –the user doesn’t always associate a given application with power device battery life. The user reaction is that this phone simply sucks.
Remember, in the beginning of this post we said that in the WP design the end user experience is the first and foremost characteristic? Therefore, to resolve the problem of background processes draining the battery, WP does not allow multitasking, which means you can’t write any background services.
But if your application is not running and you can’t write background services that will listen for updates from the cloud service, how will your cloud service update the phone and application? An alternate mechanism had to be created to allow cloud services to communicate with WP devices at all times independently of a specific application. Push notification services allow your cloud services to have a certain level of interaction with the end user, even when your application is not running.
What Is a Push Notification?
For the developer, a PN message is a means to an end. Its main purpose is to trigger the user to launch your WP application. PN gives you the option to send messages in the form of notifications to a WP device, and even if your application is not running at the moment the message arrives, the message is handled by the WP for you and presented, most of the time, to the user in a predefined manner. PNs are an integral part of WP Shell and are integrated with the Quick Launch area of the phone’s Start experience (the main phone screen), and as an overlay on top of any running application (including any Shell screen).
For the end user, PNs are a visual way for the phone to tap on the user’s shoulder saying – “Hey, something interesting just happened. Why don’t you take a look?” The user is unaware of how these messages arrive as long as they are displayed correctly and within the proper context.
- Toast notifications display as overlay messages on the user’s current screen
- Tile notifications drive a change to a tile shown in the Quick Launch area of the phone’s Start experience
There is a third notification type, the Raw Notification, which is has no visual representation. I’ll cover this in future posts.
A toast notification is displayed as an overlay message on the user’s current screen. This overlay is displayed on top of any given screen, including any running application, as long as it is not your application, and on top of any Shell screen. A toast notification is very interruptive, so as a developer you need to use it sparingly, making sure that the notification is important enough to warrant bothering the user, as the user always has the option to block all of your application’s notifications.
The following image shows such a notification messages displayed as an overlay on top of the Start screen. In this example, a weather application displays a toast notification if a severe weather alert is in effect.
A tile is a visual, dynamic representation of an application or its content within the Quick Launch area of the phone’s Start experience. As you can see in the following image, there are multiple tiles. Some are square while others, like pictures, are bigger rectangles. The important thing to remember about tiles is that each tile has an icon and two strings associated with it. As a developer, if your application tile is pinned to the Start Screen, it means you can send a tile PN message, changing the content of your tile.
With tile PNs, you can control the tile’s background, change its image, and control the two strings. The background image can be any valid URI to an image either on the phone or in the cloud. The first string is the title of the tile (bottom right corner) and the second string is the count. You can read more about How to: Create and Modify an Application Tile. Using a tile PN to change the tile enables you to update the tile when needed, so the next time users look at their Start screens, they see the latest and greatest information related to your application, and can decide whether to click on the tile to launch your application.
Now that we understand what PNs are, the next post covers how they work.