I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.
In my last post in this series I discussed working with the gestures. In this post I’ll look at push notifications.
What & Why
Let’s start by addressing what push notifications are and why you should use them.
To get an understanding of what push notifications are let’s get an understanding of windows mobile development up until this point in time.
For illustrative purposes, let’s use the above picture of some people pulling on a rope.
- The people pulling on the rope represent your application.
- The object they are pulling against, more than likely another team of people, represent a web service you have that serves data to your application.
- The rope represents the data your application needs.
There are a couple of difficulties with this common approach of pulling data from a web service.
First, your application has to figure out a schedule of when to pull data from the service. If there is an important update that needs to get to your application, the service has no way of notifying the app. It could be that the critical notification doesn’t get pulled by the application until it is no longer relevant due to a time lag.
Second, and this is a key factor with mobile apps, every time you request data from the web service the cell radio, or wi-fi connection will have to be activated. Frequently polling will result in a degradation of battery life. You certainly don’t want to be the creator of an application that gets a reputation for killing a phone’s batter.
Let’s contrast the polling model with the push model used by push notifications.
For illustrative purposes, let’s use this nice picture of a grandfather pushing his grandchild.
In this illustration, the grandfather represents your web service, and the grandchild represents your application. Unlike the polling scenario, your application doesn’t have to do anything to get notifications. Instead the web service is able to send the notifications directly to your application.
This solves the issues we talked about with the polling model in that we no longer have to worry about potential latency due to the application’s polling schedule, and we will have better battery life on the device as we no longer have to constantly activate the cell radio or wi-fi connection to poll for data.
Now that we know what push notifications are, let’s dive into the architecture.
There are a number of moving pieces you have to work with when using push notifications.
The first of course is your application. The second is the Microsoft Push Notification service. This is a service hosted by Microsoft and available for you to consume freely for your Windows phone applications. This service provides you with a dedicated and persistent channel to use to send information and updates to a windows phone application from a web service.
Here’s how you conceptually use push notification:
- The first thing you have to do when using push notifications is to establish this channel by requesting a Uri from the Microsoft Push Notification Service.
- Once you have the Uri from the push notification service you need to share it with something, that something is a web service that you create. Once the service is created, you’ll send the uri for your phone’s dedicated communication channel to the web service. You now have the infrastructure in place to send push notifications to your windows phone application.
- When you send a notification from your web service, it will actually be routed to the Microsoft push notification service.
- From there, the notification will get sent to the application.
- Your web service will receive a response code indicating whether or not the message was delivered.
It’s important to keep in mind that the push notification service does not provide you with end-to-end confirmation that your message was delivered from your web service to the windows phone application. The response will tell you if the device is connected or disconnected and whether or not your message was queued for delivery. However, you’re service will not be informed as to the success of the delivery.
With an understanding of the underlying architecture in place, let’s look at the different types of notifications available to us and how we can use them.
The first type of notifications are we’ll take a look at are toast notifications. Toast notifications are system-wide notifications that do not disrupt the user workflow or require intervention to resolve. Let’s say you’re using the search application. If you were to receive a toast notification, it would display at the top of the screen for ten seconds before disappearing. If the toast notification is tapped, the application that sent the toast notification will launch. The notification can be dismissed with a simple flick of the finger.
Two text elements of a toast notification can be updated:
- The title is a bolded string that displays immediately after the application icon.
- The sub-title is a non-bolded string that displays below the title.
The result looks something like this:
The second type of notification we’ll look at is the tile notification. Every application has a tile, or image, that is displayed if the user pins the application to the Start screen. This tile can be updated with a push notification.
There are three elements of the Tile can be updated:
- The tile’s background image can be a local resource or a remote resource.
- The tile’s title, which is a string of text can be updated as well. It must fit a single line of text and should not be wider than the actual tile.
- The count property which is simply an integer value from 1 to 99. If there is not count value it will not display.
This allows you to do something like in the image below:
The final push notification that you can utilize is the raw notification. If you don’t want to update the Tile or send a toast message, you can instead send raw information to your application. If your application is not currently running, the raw notification is discarded on the Microsoft Push Notification Service and is not delivered to the device. The payload of a raw notification has a maximum size of 1 KB.
Before wrapping up this post I want to call out a few considerations you’ll want to keep in mind when using push notifications in your windows phone applications.
If you’re going to use push notifications in your application, you should consider enabling the user to opt into and out of the notifications. In fact, if you use toast notifications you are required to ask the user if he or she wants to receive the notifications, and you must allow the user to turn off the toast notifications if they so desire.
Ask yourself if the data your sending from your service to windows phone contains personally identifiable information. If it does you should rethink your strategy as you really shouldn’t be sending this type of information through push notifications.
Finally, each device has a 15 channel limit when it comes to push notifications. If the user already has 15 apps installed that are using push notification channels, when your application attempts to register a push notification channel, it will encounter an exception. Be prepared to handle this scenario in your applications.
That’s it for push notifications. I’ll wrap this series up with a look at location services.
Previous posts in this series