At times you will want to keep the
user apprised of some change that happen on the server. Although you
could write a background agent ,
making network requests every 30 minutes might not be often enough. You
might also decide that you want to determine when to update a phone
remotely (as close to the data as possible). So instead, you should use
the phone’s ability to receive messages from the cloud. These messages
are called push notifications.
Push notifications enable
your application to register a particular phone to receive these
notifications. After the phone is registered, you can send messages
from an Internet-connected server to Microsoft’s Push Notification
Service (MPNS). This service is hosted by Microsoft and enables your
messages to reach users’ phones (and deals with the hard problems of
out-of-range and powered-off phones). Using push notifications does
require that you have a way to communicate with a service you are
responsible for; typically this is a web service hosted on a public
Internet server. You can see the general flow of push notifications in Figure 1.
FIGURE 1 Push notification message flow
Using push notifications requires several steps, but they are all fairly straightforward:
• Your app opens a push notification channel.
• Your app receives a special URL that can be used to send messages to this specific phone.
• Your app sends that URL to a service that wishes to send you notifications.
• Sometime later, the service can post a new message to MPNS using the special URL from the phone.
• The MPNS finds your phone and sends the message to the phone.
Push notifications can be used to do three
tasks on the phone: alert the user with a toast notification, update a
Live Tile, and send your application raw
messages. You will see how to do all three, but let’s start with the
basics so that you can learn how all the moving parts work together.
1. Push Notification Requirements
Using push notifications comes with several requirements. To use push notifications, you must do the following:
• Add the push notification requirement to your WMAppManifest.xml file:
...
<Capabilities>
<Capability Name="ID_CAP_PUSH_NOTIFICATION"/>
</Capabilities>
...
•
Alert the user in the user interface of the application (usually during
the first launch of your application) that you are using push
notifications.
• Allow the user to disable push notifications.
You can have only one push notification channel
per application. In addition, a limited number of applications on a
phone can use push notifications. When you first open your HTTP
notification channel, you might receive an error message stating that
the channel could not be opened. This is typically thrown when there
are too many push notification applications on the phone.
2. Preparing the Application for Push Notifications
To get started, you will need an instance of
a class that will register your application for push notifications as
well as listen for certain events (for example, notifications, errors,
and so on). This class is called HttpNotificationChannel.
When you launch your application the first time, you will register this
instance of the application (specifically the application on this
particular phone) with the MPNS by creating a new instance of the class and passing in a channel name that is specific to the application (for instance, the app name):
HttpNotificationChannel myChannel =
new HttpNotificationChannel("MYAPP");
The name of the channel is usually the name of
the application, but because you can have only one channel, it is not
important that this name be unique to the phone or user. On subsequent
launches of your application, you can get the channel by calling the
static Find method using the name like so:
HttpNotificationChannel myChannel =
HttpNotificationChannel.Find("MYAPP");
In practice, determining whether this is the
first invocation can be tedious, so you should just try to find the
channel, and if it is not found just create it like so:
public class PushSignup
{
const string CHANNELNAME = "FunWithToast";
private HttpNotificationChannel _myChannel = null;
public void CreateChannel()
{
try
{
if (_myChannel == null)
{
// Attempt to get the channel
_myChannel = HttpNotificationChannel.Find(CHANNELNAME);
// Can't Find the Channel, so create it
if (_myChannel == null)
{
_myChannel = new HttpNotificationChannel(CHANNELNAME);
...
This way, you won’t need to worry about keeping state on the first invocation of your application.
After you have a valid channel, that channel
will give your server access to a special URI that is used to send push
notifications. Again, the channel is a little different, depending on
whether it was newly created or located with the Find
method. You would think that you should be able to take the newly
created channel and retrieve the URI, but that only works on existing
channels (that is, channels located with Find):
...
// If the channel uri is valid now, then send it to the server
// Otherwise it'll be registered when the URI is updated
if (_myChannel.ChannelUri != null)
{
// Use the ChannelUri to tell your server about the phone
}
...
Newly created channels will get the URI asynchronously. To know when the URI is available, you need to register the ChannelUriUpdated event on the channel object. When this event is fired, you can use the ChannelUri. In practice you should handle this in both cases to ensure that any changes to the URI are caught and reported:
_myChannel.ChannelUriUpdated += myChannel_ChannelUriUpdated;
...
void myChannel_ChannelUriUpdated(object sender,
NotificationChannelUriEventArgs e)
{
// Use the ChannelUri to tell your server about the phone
}
After you have the channel open and a way to get the ChannelUri, you’re ready to set up the server side of the equation.
