Choosing MPNS or WNS for a Windows Phone Silverlight 8.1 app

Article
05/20/2016

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

Using Windows Notification Service (WNS) in a Silverlight 8.1 app

The Windows Notification Service (WNS), and its associated APIs, represents the common push notification service platform being used by all Windows Phone Store apps today, and in the future.

Benefits of using WNS in your Silverlight 8.1 app

The following lists some of the benefits of using WNS and the Windows Runtime APIs for tiles, toast and badges in your Silverlight 8.1 app.

Notifications are delivered within 5 seconds to devices connected to a network
No more certifications to manage. WNS uses OAuth instead of SSL certification.
The same service and APIs can be used for all Windows Phone Store apps, offering the potential for code sharing/reuse and lower maintenance costs.
Take advantage of new features. The following table lists some of the new features that are only available to your app if you are using WNS and the new Windows Runtime APIs.

WNS feature	Description
Periodic polling	Update tiles and badges by periodically polling for content updates from a cloud service.
Tile notification queue	The ability of a tile to display a rotation of up to 5 updates.
Larger tile template catalog	Over 40 templates to choose a tile layout suited to your needs.
Raw notifications	The ability to wake up your app or start a background task by sending it a raw notification.
Expiration time on a tile update	By setting an expiration time, the tile will revert to its default.
Manage your toast notifications in action center	You can use the new APIs to send notifications directly into action center, categorize notifications and selectively remove and replace notifications in action center.

To learn more about WNS, see Push notifications using the Windows Notification Service

Upgrading from MPNS to WNS in your Silverlight 8.1 app

When upgrading, the following needs to be considered.

To upgrade you Windows Phone 8 project to Silverlight 8.1, see Upgrade Windows Phone 8 apps to Windows Phone Silverlight 8.1.
Once you have upgraded your project, opt into WNS in the project’s WMAppManifest.xml file.
If you raise toast notifications from your app, make sure to set the ToastCapable = true in your app's Package.appxmanifest file.
There is no equivalent tile template for the legacy Cycle tile template. You will have to rethink the design of this scenario in your app. For example, you could consider using the tile notification queue and a peek template.
If you were using the Flip tile template, you can achieve a similar behavior using the peek tile templates or by using a tile notification queue.
You can render custom tiles from a background task using XamlRenderingBackgroundTask and RenderTargetBitmap.
You should detect the first launch of your app, replacing any pinned tiles with new tiles and associate them with push notification channel if appropriate.
When using the RequestCreateAsync to pin a secondary tile to the user's start screen, the app will be deactivated. This is a different behavior from how this API works in an app running on a PC. Because of this behavior, any code called after RequestCreateAsync is not guaranteed to run before the app is deactivated. To avoid this potential issue, you should update a pinned tile in the Deactivated event of your app. To see an example of this pattern, download and run the Updating a pinned tile on deactivation Windows Phone Silverlight 8.1 sample.
Make sure to use the Sivlerlight page-centric navigation model when supplying launch parameters. For example, “/Page2.xaml?how=toast”. This is different than using these APIs in a Windows Phone Store app, where you pass arbitrary strings in the launch parameters to do frame navigation.
When you have completed your migration to WNS, you should confirm that you’ve addressed the following actions.
- You have no using statements in your code for any of the namespaces for the .NET notification APIs that were listed in the preceding table of APIs.
- You are using the new Windows Runtime notification APIs that were listed in the preceding table of APIs.
- You have moved all tile definitions into Package.appxmanifest.
- If your app uses secondary tiles, you have code in place to loop over all pinned secondary tiles and update their templates.
- If your app updates a secondary tile when it is created and pinned, you have used the pattern recommended in the above for updating on the deactivated event in your app.

To learn more about Tiles and the templates available to your app, see Tile and tile notification overview.

Using MPNS in a Silverlight 8.1 app

If you are already using MPNS in your app, this is the lowest initial cost to you in terms of development time, requiring little work on your behalf in order to continue using MPNS and the legacy APIs. However, this choice comes with some compromises. You will not be able to take advantage of the new features that WNS enables, as outlined in the preceding section. It is also more difficult to share or reuse code in this part of your app with Windows Store apps, since those apps have to use WNS and the new Windows Runtime APIs. This is not an issue if you only have Windows Phone 8 and Silverlight 8.1 apps. However, as soon as you start to build Windows Store apps, you will either have to maintain two push notification code bases or eventually upgrade to WNS. If you decide to continue to use MPNS for your Silverlight 8.1 app, keep in mind the following issues.

Required code changes when using MPNS in your Silverlight 8.1 app

While all legacy .NET APIs are supported on Silverlight 8.1, there are some minor differences in how some of these behave on Silverlight 8.1. The following list describes these changes.

BindToShellTile and BindToShellToast always succeed.
IsShellTileBound and IsShellToastBound always return true.
BindToShellTile doesn’t need a URI list anymore, but doesn’t break if you give it. Previously, without this list or without a site being in this list, you couldn’t point to images on that site. Now, you can omit the list or omit a specific site from the list and the image can still be downloaded.
Find always returns null, so the notification channel must be created at every launch or resume of your app.

App server considerations when using MPNS in your Silverlight 8.1 app

Avoid URI length restrictions since the length of the URI used has increased to over 200 characters
Avoid domain whitelisting. The reason is that our domain structure (http://*.notify.live.net) may change over time.
Set the timeout of 15 seconds when sending notification web requests.
Use the authenticated MPNS endpoint if your service will send more than 500 messages to a device within a 24 hour period.
The 406 error code indicates either an unauthenticated cloud service has reached the per-day throttling limit for a subscription, or when a cloud service (authenticated or unauthenticated) has sent too many notifications per second.

To learn more about MPNS, see Push notifications using the Microsoft Push Notification Service

Share via