Choosing a notification delivery method (Windows Runtime apps)
This topic discusses the notification options—local, scheduled, periodic, and push—available to deliver tile and badge updates and toast notification content. A tile 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 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 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 can have useful or interesting information to show on the tile, even if that content changes only after the user launches and interacts with the app. Local notifications are also a good 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 launch, or at least immediately after the user makes a change that your app would normally reflect on the tile. That update isn't seen until the user leaves the app, but by making that change while the app is being used ensures that the tile is already up-to-date when the user departs.
While the API calls are local, the notifications can reference web images. If the web image is not available for download, is corrupted, or doesn't meet the image specifications, tiles and toast respond differently:
- Tiles: The update is not shown
- Toast: The notification is displayed, but with a placeholder image
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 a subset of local notifications that can specify the precise time when a tile should be updated or a toast notification should be shown. Scheduled notifications are ideal in 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 polls 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 to communicate real-time data or data that is personalized for your user. Push notifications are used for content that is generated at unpredictable times, such as breaking news, social network updates, or instant messages. 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 during a game.
Push notifications require a cloud service that manages push notification channels and chooses when and to whom to send notifications.
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
Scheduled notifications sample