This topic discusses the notification options available to deliver tile and badge updates and toast notification content: local, scheduled, periodic, and push. A tile on the Start screen or a toast notification can get information to your user while the user is not directly engaged with your app. The nature and content of your app and the information that you want to deliver can help you determine which notification method (or methods—you're not restricted to just one) is best for your particular scenario.
Notification delivery methods
There are four mechanisms that an app can use to deliver a notification:
- Local
- Scheduled
- Periodic
- Push
This table summarizes the 4 notification delivery types.
| Delivery method | Use with | Description | Examples |
|---|---|---|---|
| Local | Tile, Badge, Toast | A set of API calls that send notifications while your app is running, directly updating the tile or badge, or sending a toast notification. |
|
| Scheduled | Tile, Toast | A set of API calls that schedule a notification in advance to update at the precise time you specify. |
|
| Periodic | Tile, Badge | Notifications that update tiles and badges regularly at a fixed time interval by polling a cloud service for new content. |
|
| Push | Tile, Badge, Toast, Raw | Notifications sent from a cloud server, even if your app isn't running. |
|
Local notifications
Updating the app tile or badge or raising a toast notification while the app is running is the simplest of the notification delivery mechanisms; it requires only local API calls. Every app could have information to show on the tile, which would be useful or interesting to the user, even if that content changes only when the user launches and interacts with the app. Local notifications are also a great way to keep the app tile current, even if you also use one of the other notification mechanisms. For instance, a photo app tile could show photos from a recently added album.
We recommended that your app update its tile locally on first launched, or at least immediately after the user makes a change that your app would normally reflect on the tile. Doing so ensures that the tile is current when the user leaves your app.
While the API calls are local, the notifications can reference web images. However, for tile notifications, if the web image is not available for download, or perhaps is corrupted, the notification won't be shown to the user. If a web image used in a toast notification is unavailable or corrupted, a placeholder image is used.
Local notifications do not expire, but it is a best practice to set an explicit expiration time.
For more information, see these topics:
- App tiles and badges sample
- How to send a glyph or numeric badge in a local notification
- Quickstart: Sending a tile update
- Quickstart: Sending a toast notification
Scheduled notifications
Scheduled notifications are identical to local notifications except that they can specify the precise time when a tile should be updated or a toast notification should be shown. Scheduled notifications are ideal for situations where the content to be updated is known in advance, such as a meeting invitation. If you don't have advance knowledge of the notification content, you should use a push or periodic notification.
By default, scheduled notifications expire three days from the time that they are delivered. If needed, you can override this default with an explicit expiration time.
For more information, see these topics:
- How to schedule a tile notification
- How to schedule a toast notification
- Guidelines and checklist for scheduled notifications
Periodic notifications
Periodic notifications give you live tile updates with a minimal cloud service and client investment. They are also an excellent method of distributing the same content to a wide audience. Your client code specifies the URL of a cloud location that Windows will poll for tile or badge updates, and how often the location should be polled. At each polling interval, Windows contacts the URL to download the specified XML content and display it on the tile.
Periodic notifications require the app to host a cloud service, and this service will be polled at the specified interval by all users who have the app installed. Note that periodic updates cannot be used for toast notifications; toast notifications are best served by scheduled or push notifications.
By default, periodic notifications expire three days from the time that the polling occurs. If needed, you can override this default with an explicit expiration time.
For more information, see these topics:
- Periodic notification overview
- How to set up periodic notifications for badges
- How to set up periodic notifications for tiles
Push notifications
Push notifications are ideal for those situations where your app has real-time data or data that is personalized for your user, such as social network updates, incoming messages, or game invitations. Push notifications are also useful in situations where the data is time-sensitive in a way that would not suit periodic notifications, such as sports scores while the game is happening. Push notifications are also best for content that is generated at unpredictable times, such as breaking news or instant messages.
Push notifications require a cloud service that will manage push notification channels and choose when to send notifications to specific users.
By default, push notifications expire three days from the time that they are received by Windows Push Notification Services (WNS). If needed, you can override this default with an explicit expiration time.
For more information, see these topics:
- Push notification overview
- Quickstart: Sending a push notification
- How to authenticate with the Windows Push Notification Service (WNS)
- How to request, create, and save a notification channel
- Guidelines and checklist for push notifications
Related topics
- Push and periodic notifications sample
- Toast notifications sample
- Scheduled notifications sample
- Delivering notifications
- The notification queue
- How to use the notification queue
- Quickstart: Sending notifications to a secondary tile
Build date: 10/26/2012
