Windows Phone 8.1 Universal App Push Notifications (WNS) – Part 1
In this posts I will help you out to create a full blown Windows Notification Service (WNS) push notification environment for Universal Windows Phone 8.1 apps. After reading this series and stealing the code (which is not a crime in my opinion 🙂 ) you are able to handle push notifications for your Windows Phone apps. There is some documentation about this subject on the www, but using that information forces you to fit some peaces together to get a complete solution. Well, in this post I did that for you. So enjoy.
After reading this tutorial you are able to handle push notifications for your Windows Phone apps.
The way of sending push notifications to your Windows Phone device is changing over time. Each upgrade of the Mobile software, has its impact on the way push notifications must be handled. To make everything more difficult, there is not one but there are two ways to send push notifications to a Windows device. However for universal apps, you should stick to Windows Notification Service or in short WNS. But it took me some time to figure that out.
Another thing that wouldn’t help much is that I (and maybe you too) can handle the MSDN docs very well. For some reason, I find the documentation almost for every subject unclear and is almost always incomplete. Furthermore, the docs always force you to read another article and another, while you need the full picture at once. With as background some years of Android programming experience I can assure that Google Android documentation is much more clear about every subject. Well maybe, Microsoft should visit Google to learn how to do it. But, enough about that. I put all necessary knowledge in these blog articles so let’s move on and enjoy push notifications for Windows Phone.
What are push notifications?
Push notifications are small XML-based or string-based messages that can be pushed by you as app owner to your Windows Mobile app. Sending a push message means sending an HTTP request to a Microsoft server. More about that later.
There are four different tastes of push messages:
- Toast messages
- Tile messages
- Badge messages
- RAW notification messages
Toast messages are the little messages at the top of your device’s home screen that are shown for some seconds, containing text and possibly an image accompanied with a sound played. A toast will end up in the notification list. Clicking on it will result in opening one of the windows in your app.
Tile messages will influence the app tile on the home screen. It is possible to change the content (images and text) of your app’s tile on the home screen by sending a push messages.
Badge message will influence your tiles too by adding an icon to it or remove it if you want. Instead of an icon, an amount can added to the tile, this is for example generally done by e-mail apps to show the amount of unread messages on the home screen.
Raw notification messages
Raw notification messages are special ones but therefore very interesting. All push message types described above have not in any way interaction with your apps program logic. In the above cases your app isn’t informed when such push notification has arrived. But, the Raw notification is a notification that works something like an Android app acts when a Google’s Cloud Messaging service push notification arrives.
Let’s explain it. A RAW notification is directly sent to your app’s program logic, therefore you need to implement a background service in your app that is able to catch and interpret custom formed (aka: raw) notification messages. The nice thing is that the app is woken up when you send a push notification to it. However, the down-side is, doing this very often, will result in your app be a battery drain. So be careful.
When the notification is delivered to your app’s program logic you are free to decide what to do with it. Store the pushed data to your app’s database, showing a toast message to put in the notification panel or, when the app on the front of the phone, update the UI according to the data received.
Pricing and limitations?
When you build your own service to send and manage the push messages to send to the Microsoft WNS server, it is is as free as possible. There is a good reason, as Microsoft you want to deliver a good user experience to your users. However, if you are a little bit lazy, you can use, among others, the Azure Notification Hubs. This solution helps you manage large amounts of app instances. This service is free for low volumes and pay at higher volumes. You can save money by doing it yourself but you need to accept the extra effort it needs.
There are limitations on the push notifications volume that you send to the Microsoft WNS servers. As far as I could find on the www there are limits on the amount of messages per app instance (your app on a single device) per day of 500 messages. However, these are limits mentioned not for WNS but for the older (Windows Phone 8.0 Silverlight) Microsoft Push Notification Service (MPNS). However, having limits on push notifications is very uncommon for these kind of services if you take the services of Google (Android) and Apple (iOS) in account.
If you know what the exact limits are, please let us know!
There are also limitations on reliability. Microsoft doesn’t guarantee that a push notification message is delivered on time or delivered at all. Normally it will, but you shouldn’t use it for very (time) critical applications. In other words, creating an app delivering emergency messages to doctors using push notifications is a really bad idea. On the other hand, an app delivering news alerts when they occur, is no problem as long as you waive all legal responsibilities in your apps license agreement (especially for our US friends 🙂 )
Furthermore there are limits on the size of the push notification message. For badge, tile and toast these are limited to what fits on the screen. However, for the raw notification message the limit is 5K of data, which is (in my opinion) quiet reasonable.
Why and when push notifications?
The reason that push notifications are introduced on all kind of platforms has everything to do with saving valuable battery energy. Microsoft don’t want you to suck their mobile phone user energy. If you want to do updates of data for your app very often or you want to inform the device immediately if something changes, push notifications are the way to go. As an alternative BackgroundTasks can be used to run updates. However, Microsoft don’t want you to update your app with a higher frequency than of each 30 minutes. So, in short, if you want immediate updates to your app users or you want to update your app more frequently, use push notifications.
Before we dive into programming push notifications, it is important to know how Microsoft implemented this technology. I will not dive into it deeply, but it is important to have a level of understanding before we start programming. As mentioned before, sending a single push notification to a single app on a single device means sending a HTTP request containing the push notification type (tile, toast, badge or raw), content and an app push notification identifier to the Microsoft WNS platform. The WNS server, on his hand, will deliver the push notification to your Windows Phone app magically.
A “channel” is the push notification identity of a single instance of your app on a single device.
Before you are able to send the push message to the WNS server, you need to identify your push notification enabled app that is running on a Windows Phone device somewhere. So you need to implement functionality into your app that get the push notification identity and informs a web service, that is owned by you, about the app’s push notification identity. Microsoft calls an apps push notification identity a “channel”. So, a “channel” is the push notification identity of a single instance of your app on a single device. To make it more clear, a channel has the same role to a push notification as that a mobile phone number has to a call or sms-message.
When the channel, which is practically an url, is delivered to your web service, you can do with it what you want. In common scenarios you will combine the channel data with some relevant app settings. Depending on these app settings (for example alert search terms in case of news alert app) you can decide the right moments to send a push notification via the Microsoft WNS service to your app. Your public available web service must store the app settings and channel somewhere in a data store. This data store can be controlled by some kind of push notification service that is able to decide when and to which device a notification should be delivered.
Technical details of how to build the above scenario will be part of the next post of this series. I hope you enjoyed it, please comment if you feel to do so.