Periodic notification overview (Windows Store apps) (Windows)

1 out of 1 rated this helpful - Rate this topic

In this article

How it works
URI location and XML content
Polling Behavior
Expiration of tile and badge notifications
Periodic notifications in the notification queue
Related topics

Periodic notifications, which are sometimes called polled notifications, update tiles and badges at a fixed interval by downloading content directly from a cloud service. To use periodic notifications, your client app code specifies two elements:

The Uniform Resource Identifier (URI) of a web location that Windows polls for tile or badge updates for your app
How often that URI should be polled

Periodic notifications enable your app to get live tile updates with minimal cloud service and client investment. Periodic notifications are a good delivery method for distributing the same content to a wide audience.

How it works

Periodic notifications require that your app hosts a cloud service. The service will be polled periodically by all users who have the app installed. At each polling interval, such as once an hour, Windows sends an HTTP GET request to the URI, downloads the requested tile or badge content (as XML) that is supplied in response to the request, and displays the content on the app's tile.

Note that periodic updates cannot be used with toast notifications. Toast is best delivered through scheduled or push notifications.

URI location and XML content

Any valid HTTP or HTTPS web address can be used as the URI to be polled by Windows.

The cloud server's response includes the downloaded content. The content returned from the URI must conform to the Tile or Badge XML schema specification, and must be UTF-8 encoded. You can use defined HTTP headers to specify the expiration time or tag for the notification.

Polling Behavior

You will call these methods to begin polling:

When you call one of those methods, the URI specified in the call is immediately polled and the tile or badge is updated with the received contents. After this initial poll, Windows continues to provide updates at the requested interval. Polling continues until you explicitly stop it, your app is uninstalled, or, in the case of a secondary tile, the tile is removed. Otherwise, Windows will continue to poll for updates to your tile or badge even if your app is never launched again.

The recurrence interval

You specify the recurrence interval as a parameter of the methods listed above. Note that while Windows makes a best effort to poll as requested in that parameter, the interval is not precise. The requested poll interval can be delayed by up to 15 minutes at the discretion of Windows.

The start time

You can specify a particular time of day to begin polling, through an optional method parameter. Consider an app that changes its tile content just once a day. In such a case, we recommend that you poll close to the time that you will update your cloud service. For example, if a daily shopping site publishes the day's offers at 8 AM, it would be best to perform the poll for new tile content shortly after 8 AM.

If you provide the start time parameter, the first call to the method polls for content immediately. Then, regular polling starts within 15 minutes of the provided start time.

Automatic retry behavior

The URI is only polled if the network is available. If the network is available but the URI cannot be contacted for any reason, this iteration of the polling interval will be skipped and the URI will be polled again at the next interval. If the computer is in an off, sleep, or hibernated state when a polling interval is reached, the tile or badge will be polled when the computer returns from its off or sleep state.

Expiration of tile and badge notifications

By default, periodic tile and badge notifications expire three days from the time they are downloaded. Therefore, it is a best practice to set an expiration on all periodic tile and badge notifications, using a time that makes sense for your app, to ensure that your tile's content does not persist longer than it is relevant. When a notification expires, the content is removed from the tile or queue and is no longer shown to the user. An explicit expiration time is essential for content with a defined lifespan. It also assures the removal of stale content if your cloud service becomes unreachable, or if the user disconnects from the network for an extended period of time.

Your cloud service can set an expiration for each notification by returning the X-WNS-Expires HTTP header to specify the expiration date and time. The X-WNS-Expires HTTP header conforms to the HTTP-date format. For more information, see StartPeriodicUpdate or StartPeriodicUpdateBatch.

For example, during a stock market's active trading day, you can set the expiration for a stock price update to twice that of your polling interval (such as one hour after receipt if you are polling every half-hour). As another example, a news app might determine that one day is an appropriate expiration time for a daily news tile update.

Periodic notifications in the notification queue

You can use periodic tile updates with notification cycling. By default, a tile on the Start screen shows the content of a single notification until it is replaced by a new notification. When you enable cycling, up to five notifications are maintained in a queue and the tile cycles through them.

If the queue has reached its capacity of five notifications, the next new notification replaces the oldest notification in the queue. However, by setting tags on your notifications, you can affect the queue's replacement policy. A tag is an app-specific, case-insensitive string of up to 16 alphanumeric characters, specified in the X-WNS-Tag HTTP header. Windows compares the tag on an incoming notification with the tags of notifications already in the queue. If a match is found, the new notification replaces the queued notification with the same tag. If no match is found, the default replacement rule is applied and the new notification replaces the oldest notification in the queue.

You can use notification queuing and tagging to implement a variety of rich notification scenarios. For example, a stock app could send five notifications, each about a different stock and each tagged with a stock name. This prevents the queue from ever containing two notifications for the same stock, the older of which is out of date.

For more information, see Using the notification queue.

Enabling the notification queue

To implement a notification queue, you must first enable the queue for your tile. The call to enable the queue needs to be called only once in your app's lifetime, but there is no harm in calling it each time your app is launched.

Polling for more than one notification at a time

You must provide a unique URI for each notification that you'd like Windows to download for your tile. By using the StartPeriodicUpdateBatch method, you can provide up to five URIs at once for use with the notification queue. Each URI will be polled, at or near the same time, for a single notification payload, which should contain XML for both the wide and square versions of the notification. Each polled URI can return its own expiration and tag value.

Periodic notification overview (Windows Store apps)