Push notification is one of the most important features of mobile apps. Users use it a lot and take it for granted that you incorporate this feature in your app. But underneath the apparently realtime popup/toast of a message, lives a whole system of providers and notification hubs to make that possible.
First of all, there are three major notification providers: Google, Apple and Microsoft. It looks like pushing message to all three stores is hard but AMS makes it easy.
In this example we push to a Windows Store app (part of the default generated AMS example solution). But It’s almost the same on eg IOS or Android. Apart from the client code which differs on each platform (See http://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-windows-phone-get-started-push/ for different client support) the AMS server code is all the same.
Coding! Let us start with the first, most important step: reserve your future app name in the store of choice. In return you will be granted some secret key(s) which you have to use for push notification to the users of your app.
Fill these secret keys in on the Push tab in the Azure Mobile Services portal. There is plenty of room for all the settings (Facebook, Google, MSFT). There is rather no push notification from Twitter 🙂
So let’s add some code in the service which will push messages. In this example I push a notification if a note is inserted in the database by the default available TableController (part of the generated code when the service was created initially).
Although this is an example using a WNS native toast, it is clear we only have to define the message and we have to push it once. AMS will take the message and distribute it over all the notification hubs configured.
Did you notice the “DATABASE” tag? I have given this message a conditional tag. So only clients which are registered (interested) for messages with this tag, will receive it. It should be possible to send one message specifically to one user!
So now let’s go to the client, because we want to receive that message. We have to register for push messages.
Here we do a couple of things. First we unregister for any tags we could be registered to already. This is nice if the tags change often. Afterwards we register for the messages with tag “DATABASE”. We can enter any amount of tags but for now it’s this one.
Why do we register? Because the push notification messages will be shown, whether we are using the app (it is currently opened, in use) or we are not. As long the app is installed on the machine (and run once), push notification from that app could reach us. And if so, if the user tabs on the toast, the app will be instantiated (if not already open).
But maybe you do not want the notification to be shown while the app is open. Or you want to present it in a whole new way (with sound of something blinking). That’s why I added the event handler and added the function.
Inside that function I can parse the message and decide if I want to show it the regular way or not (using the args.Cancel).
So call the Initialize function when you know which kinds of messages you want to receive. Or omit the tag if you want them all 🙂 I have put it inside the Onlaunched event in app.xaml.cs.
But there is still one thing to do!
We must have permissions from the user to receive push notification for our app. Or at least, the user must be made aware of the fact we are using push notifications. This is done with the ‘toast capability’. Double-click the Package.appxmanifest in the Windows Store app, and on the application tab, select Yes for Toast Capable!
And this is all there is to tell about Push Notification support (at least the most important part).
Start the AMS app and insert a Todo Item. Within minutes, usually seconds or mostly within a second, a popup will appear.
Is this cool or not?
Push notification is part of all versions of Azure Mobile Services. But the free version has some restrictions (What do you expect? It’s free…) See the pricing for more information.