In the previous post - Understanding Microsoft Push Notifications for Windows Phones, you learned what push notifications (PN) are and why we need them. In this post, we’ll explain a little about how Microsoft Push Notification (MPN) service works behind the scenes and who the different players are.
There are three players in the push notification game:
When a cloud service wishes to send messages to a WP application when your application is not running, it has to use MPN, which is a hosted service in Windows Azure. The MPN Service will send the message in the form of a push notification message on behalf of the cloud service.
But before the cloud service can send notification messages to a WP device, your WP application needs to send some kind of identification that can be used by your cloud service when it POST messages to MPN Service, as shown below in the following image. The WP application opens a notification channel to the MPN service, shown as number 1. By doing so, the application indicates that it wishes to receive push notifications messages. When the channel is created, a subscription end point is created within the MPN servers that allows your cloud service to POST messages to that end point (on the MPN Server), which in return will forward your cloud service message to the target WP device via the that channel, identified by the URI used to POST the message. In response to opening the channel, the MPN server returns a URI to the WP application. This URI represents the notification channel that your cloud service needs to use, and it contains all the information associated with that subscription. This URI is the address to which your cloud application will do an HTTP POST to send a PN message to the device. It is the responsible of your WP application to pass this URI to the cloud service, shown as number 2.
In order to send messages to a WP device, the cloud service needs to do an HTTP POST, indicated as number 3, a well formatted (in XML format and in accordance with the MPN protocol), to the URI that it received from the WP application in step 2. By doing so, the cloud service posts a notification request to the MPN service, which in turn routes the message as a Push Notification to the WP device as either a toast, a tile notification, or raw data directly to the running application depending on the type of notification that is sent, shown as number 4.
Once the WP device receives the PN via the Push Client, it routes the notification to Shell, which in turn can either update the application tile, show a toast if the application is not running, or send the notification message to the already running application.
And that's it. From here on everything else is a detailed implementation of your cloud service and your WP client application, which will be the topic of our next post.
More...
There are three players in the push notification game:
- The backend Web application, or cloud service, that communicates with your Windows Phone 7 application— for example thinks about the Facebook Web site and its companion WP application.
- The Windows Phone device—and not your WP7 application, because if your application is currently running, there is little need to use MPN. But if your application is not running, then the MPN Client plays a major role. The MPN Client is a service running on WP7 that implements the client-to-server protocol.
- Microsoft Push Notification (MPN) Service—that sends messages in the form of push notifications to WP devices on behalf of your cloud services. The MPN service is designed to provide cloud services with a dedicated, resilient, and persistent channel for pushing notifications to a mobile device.
When a cloud service wishes to send messages to a WP application when your application is not running, it has to use MPN, which is a hosted service in Windows Azure. The MPN Service will send the message in the form of a push notification message on behalf of the cloud service.
But before the cloud service can send notification messages to a WP device, your WP application needs to send some kind of identification that can be used by your cloud service when it POST messages to MPN Service, as shown below in the following image. The WP application opens a notification channel to the MPN service, shown as number 1. By doing so, the application indicates that it wishes to receive push notifications messages. When the channel is created, a subscription end point is created within the MPN servers that allows your cloud service to POST messages to that end point (on the MPN Server), which in return will forward your cloud service message to the target WP device via the that channel, identified by the URI used to POST the message. In response to opening the channel, the MPN server returns a URI to the WP application. This URI represents the notification channel that your cloud service needs to use, and it contains all the information associated with that subscription. This URI is the address to which your cloud application will do an HTTP POST to send a PN message to the device. It is the responsible of your WP application to pass this URI to the cloud service, shown as number 2.
Setting up the PN Channel
In order to send messages to a WP device, the cloud service needs to do an HTTP POST, indicated as number 3, a well formatted (in XML format and in accordance with the MPN protocol), to the URI that it received from the WP application in step 2. By doing so, the cloud service posts a notification request to the MPN service, which in turn routes the message as a Push Notification to the WP device as either a toast, a tile notification, or raw data directly to the running application depending on the type of notification that is sent, shown as number 4.
Once the WP device receives the PN via the Push Client, it routes the notification to Shell, which in turn can either update the application tile, show a toast if the application is not running, or send the notification message to the already running application.
And that's it. From here on everything else is a detailed implementation of your cloud service and your WP client application, which will be the topic of our next post.
More...