This blog post was authored by Austin Laugesen, a Program Manager on the Windows Phone team.
– Adam
Microsoft Push Notification Service (MPNS) is an asynchronous, best-effort service that offers developers a channel to send data to a Windows Phone app from a cloud service in a power-efficient manner. The following recommended practices can help you tune your service to work well with MPNS.
This topic contains the following sections
· Setting a timeout for requests sent to MPNS
· Handling new channel URIs
· Using the authenticated endpoint
· Setting your app to respond to specific MPNS responses
Setting a timeout for requests sent to MPNS
We recommend that you set the timeout for your MPNS requests to 15 seconds. For example, if you send notifications to MPNS using ASP.NET, when you create a WebRequest object, adjust its timeout value like this:
HttpWebRequest request = (HttpWebRequest)asynchronousResult.AsyncState;
request.Timeout = 15000;
Handling new channel URIs
When your client app detects a channel URI change, your app must send the newest URI to your service. Your service must retain only the latest channel URI for each client. Consider associating the user’s device ID with their channel URI in your service. Your service can then use the device ID to reconcile whether a channel URI is for a new user, or if it’s replacing an existing channel URI for an existing user.
Windows Phone documentation offers many examples that demonstrate how to set up an app to receive push notifications, including some that show you how you can set up an event handler to respond to changes in the channel URI. See How to Send and receive Tile Notifications for Windows Phone for one way to do this using the PushChannel_ChannelUriUpdated function.
Channel URIs may be up to 1,024 characters long.
Using the authenticated endpoint
Use the authenticated MPNS endpoint if your service sends over 500 notifications to any one client in a 24-hour period, or if you want to send notifications securely. Using the authenticated MPNS endpoint overrides the default daily quota of 500 notifications.
The following resources describe how to use an authenticated MPNS endpoint:
· Setting up an authenticated web service to send push notifications for Windows Phone
· No-quota push notifications using a root Certificate Authority
Also, if your service sends more than 500 messages to a device in one day, it’s important to consider how this affects the battery life of the user’s phone, and whether they are aware of the cost in terms of battery consumption.
Setting your service to respond to specific MPNS responses
It’s common for mobile devices to change network connectivity states. For more information on this, see Transition flow for Device Connection Status. As your service sends notifications to MPNS, MPNS informs your service of the observed connectivity state of the device. Response headers and response codes are detailed at Push Notification Service response codes for Windows Phone. You can handle these responses in a variety of ways. Microsoft recommends these approaches.
|
Response code |
Notification status |
Device connection status |
Subscription status |
Recommendations |
|
200 OK |
QueueFull |
Connect |
Active |
Your service may resend a notification. If it does, it should have an exponential back-off/retry logic on the order of minutes. Resend after 2 minutes; if the same message comes back, resend after 4 minutes, 8 minutes, 16 minutes, etc… up to 32 minutes. |
|
200 OK |
QueueFull |
Temp Disconnected |
Active |
Your service may resend a notification. If it does, it should have an exponential back-off/retry logic. Resend after 1 minute; if the same message appears, resend after 2 minutes, 4 minutes, 8 minutes, and so on, up to 24 hours. |
|
404 Not Found |
Dropped |
* Any Connection Status |
Expired |
Do not send any additional notifications to this URI because it no longer exists. |
|
412 Precondition Failed |
Dropped |
Disconnected |
N/A |
Your service may resend a notification. If it does, it should retry, at most, once an hour over a 24-hour period. If it still fails after 24 hours, your service should no longer send retries for that notification. |
|
503 |
N/A |
N/A |
N/A |
Your service may resend a notification. If it does, it should have an exponential back-off/retry logic. Resend after 5 seconds, if the same message comes back, resend after 10 seconds, 20 seconds, 40 seconds, and so on, up to 30 minutes. |
Resources
· Sending push notifications for Windows Phone
· Push Notification Service response codes for Windows Phone