Keep track of all the latest news and events on developer tools and technologies you care about
by Andy Wigley, Microsoft Technical Evangelist.
A few weeks ago, Microsoft announced the release of Windows Azure SDK V2.1 which is a major update containing many new features and enhancements. One of the standout features was GA (General Availability) of Windows Azure Notification Hubs as part of our official Windows Azure SDK. Windows Azure Notification Hubs is a service that makes it easier to send push notifications from your backend systems out to your mobile clients. In the preview release available since January 2013, only Windows Store and iOS clients were supported, but with this full release support extends to all your mobile clients across all platforms: Windows Store, Windows Phone 8, iOS, and Android.
Push Notifications are an important tool for the modern mobile app developer. Modern apps running on smartphones and tablets operate on the whole only when the user activates them and interacts with them. When they lose focus, the operating system suspends them so that they do not use precious resources of the device – chiefly battery – unnecessarily. This aspect of their behaviour is the key differentiator from traditional desktop apps, which may run continuously as they were designed for running on a PC that is permanently connected to network and mains power.
But what happens if your app is concerned with time-sensitive information, such as football scores or stock price movements? You need a way of notifying users of your app of the information that is important to them, and you need to be able to do it even when the app is not currently active on the mobile device. Enter push notifications, which allows the app developer to create a solution where backend logic, perhaps running on premises or in a Windows Azure Worker Role or a scheduled job in Windows Azure Mobile Services can send unsolicited messages to mobile devices where their app is installed and display a toast pop-up message or update the information shown on a tile.
All the major mobile platforms have their own flavour of push notifications. Windows 8 has WNS (Windows Notification Services), Windows Phone has MPNS (Microsoft Push Notification Services), iPhone and iPad has APNS (Apple Push Notification Services) and finally Android has GCM (Google Cloud Messaging). All these work in essentially the same way: the mobile app registers with its push notifications services layer and gets back a unique handle ( a token or URI), and it needs to register that handle with a custom web service that the app developer creates, and which contains the backend logic of the app. When the backend logic determines that it needs to send a notification, it sends the message along with the handle from the device to the push notification service, and the notification service takes care of delivering it to the device, storing it for later delivery if the target device is currently offline.
In the specific case of a solution for Windows Phone, it looks like this. The device registers for push notifications1 and receives a unique URI (the channel URI) which it then sends off to your cloud service2 (your own web service) and the web service maintains a list of all subscribers for this app. Then when the backend logic has something to communicate to the devices, it reads the list of subscriber channel URIs and sends the tile/toast/raw payloads to the subscriber URIs3. The subscriber URIs are actually endpoints hosted on MPNS (Microsoft Push Notification Services), so MPNS actually takes care of delivering the payloads.
Seems simple enough, right? Except that building a real world push notifications solution is in fact quite hard. In a real world app, when you post to MPNS you get back a response that gives you information about the state of the phone app subscription. There’s a whole page in the documentation about what you might get back: Push Notification Service response codes for Windows Phone and even if you ignore most of that, at the very least you should be removing subscribers from your list if you get a 404 Not Found response back, indicating that the subscription channel URI you posted to is no longer valid.
In fact, writing backend logic to send push notifications and correctly react to the Push Notification Service response codes is complicated, time consuming and costly. And if you want to send push notifications to more than one client platform at the same time, such as Windows 8, iOS and Android, you multiply the complexity of your solution a hundred times.
Whether your app runs on only one family of mobile clients, or maybe on all four, Windows Azure Service Bus Notification Hubs enables you to access an easy-to-use, multiplatform, and scaled-out push infrastructure, which greatly simplifies the implementation of push notifications for both consumer and enterprise applications for mobile platforms. It handles much of the complexity of storing and managing the list of subscribers and the delivery of notifications so you can focus on the implementation of your backend logic and not worry about a subscription web service and the management of it, not have to worry about the differences between MPNS, WNS, APNS and GCM notifications.
Notification Hubs considerably reduces the push-specific code that runs in the app backend. Devices are only responsible for registering their push notification service handles, and the back-end responsible for sending platform independent messages to users or interest groups.
You can use Notification Hubs to:
You program against a common API to send push notifications to a variety of mobile platforms, including Windows Store, Windows Phone, iOS and Android. You can choose to send platform-specific notifications or broadcast a single platform-agnostic notification to all users. A few lines of code gives you the power to reach either all devices on a single platform or all iOS, Android and Windows devices at once.
You can interact with Notification Hubs from any backend application, whether it’s on premises or hosted in the cloud. There are client APIs that make it easy to interact from .NET clients, but the REST API means that you can access Notification Hubs from any connected application.
In most applications, users will specify some kind of preference on the notifications they want to receive. For example, in a live sports scores app, the app user will specify their favourite team and will want to be notified only for information relevant to that team.
You can easily support this using a feature called tags. You can easily record one or more tags for an end user which are stored along with their push notifications system token(s), then when you send a notification, you can specify that it should only be sent to users who have registered a particular tag.
A complementary feature called Templates allows developers to specify the exact format of the notification that each user receives based on each of their preferences. By using templates, there is no need to store the localization settings for each of your customers or to create hundreds of tags. You just need to register the templates that specify the correct language with a Notification Hub and send a single message from your backend logic with all the localized content. Once your Notification Hub receives that single message, it will extract the correct localized message for each targeted user from the message.
One of the major advantages of Windows Azure is that you can easily scale out to support larger numbers of users as required. So it is with Notification Hubs: your backend logic only needs to send a single message to the Notification Hub, and it will automatically handle the pub/sub scale-out infrastructure necessary to scale your message to every active device with incredibly low latency, and millions of push notifications will be fired off to your users. Think how it would be if you had to scale out your own custom registration service to handle that kind of traffic?
To start sending push notifications to every user on every device, you will need a Windows Azure account. Sign up for the free trial here.
You can watch the Notification Hubs //BUILD/ presentation here.
Here are some useful resources to allow you to dig deeper into Windows Azure Notification Hubs:
o Windows Azure Notification Hubs Overview
o Get started with Notification Hubs – Windows Phone
o How To: Windows Azure Notification Hubs (Windows Store Apps)
o How To: Windows Azure Notification Hubs (iOS Apps)
o How To: Windows Azure Notification Hubs (Android Apps)
o Use Notification Hubs to send breaking news (shows how to use tags to send push notifications to different groups of subscribers)
And finally, to read about an example of how to build a Windows Phone app that uses Windows Azure Notification Hubs and download a sample, please see my blog Push Notifications made easy: Using Windows Azure Notification Hubs with Windows Phone.