In this blog post I will discuss some communication options for device and services scenarios. Looking at it from a higher level, we can differentiate between device initiated and service initiated communication. However on most devices, there is a fundamental difference between the two:
- the service has the capability to listen for incoming requests and therefore implementing device initiated communication is as straight forward as sending the request (REST, WS-*, …) to the service endpoint
- most device platforms don’t provide the capability of exposing a service endpoint and dis-encourage from listening/polling for requests, which makes pushing data to a device quite a bit more challenging
Actively pushing information to mobile devices is a common requirement. That’s why the different device platforms offer capabilities which take care of push notifications in a bandwidth and battery friendly way. This is achieved through a client component which takes care of receiving the message and then dispatches it to the App on one side, and a service component which facilitates the interaction with the client component.
Let’s have a look how this works for Windows Store Apps:
- to receive push notifications, the Windows Store App simply requests a so called channel URI from the Notification Client Platform (which represents the client component of Windows 8 notification capabilities).
- this URI is used to identify the device and App and needs to be shared with services that should send notifications to this App. To do so, the service provides a function which allows the App to register its channel URI (in other words, the service simply receives and stores the different channel URIs)
- to actually send a notification to a Windows Store App, the service authenticates itself to the Windows Push Notification Service (which is a service run by Microsoft) and makes the request to send the notification message to a specific channel
- the Windows Push Notification Service sends the message to the requested device (there is not guarantee for delivery)
- on the client side, the Notification Client Platform simply dispatches the message according to the channel URI
Since there is a strong coupling between the client and the service component, it shouldn’t come as a surprise that the different device platforms provide you with different notification services:
- Windows 8 – Windows Push Notification Service (WNS)
- Windows Phone – Microsoft Push Notification Service (MPNS)
- iOS – Apple Push Notification Service (APNS)
- Android – Google Cloud Messaging (GCM)
However the really good news is that Windows Azure Mobile Services makes sending push notifications to the above mentioned platforms very easy: It not only provides you with an easy way to configure the services on its portal, but it also provides objects for implementing the service and SDKs for the client. This makes the request for a Windows Store Channel URI as simple as the following line of code:
channelURI = pushNotificationChannelManager.
Once the mobile service knows about the channelURI, it simply can send a push notification using the server side object model:
push.wns.sendToastText04(channelURI, “this is my message”);
As already mentioned, the server side scripting of Mobile Services doesn’t only provide a push object for Windows Store Apps but also one for APNS, GCM and MPNS.
I’m lovin’ it…