The Notification Pipeline
UWP notifications reach a user through three delivery paths that all render through the same XML-based toast template system underneath. Local notifications are raised directly by app code while it's running. Scheduled notifications are queued in advance with a specific delivery time, via ScheduledToastNotification, and fire even if the app isn't running at that moment. Push notifications are delivered by the Windows Notification Service (WNS) from a cloud backend, and are the only path that works when the app is fully closed and the device wasn't expecting anything at that instant.
Cricket analogy: Like a stadium's PA system that announces a wicket instantly during play, local, pre-schedules the lunch-break reminder for exactly 12:40pm regardless of match state, scheduled, and also relays a breaking selection-committee update pushed live from headquarters even when the ground is empty, push — three channels, one PA system.
Toast Notification XML and Adaptive Content
A toast is ultimately an XmlDocument conforming to the adaptive toast schema, most conveniently assembled with ToastContentBuilder rather than hand-written XML strings. The schema defines text bindings for title and body, an optional hero image shown prominently at the top, inline images, and action buttons whose ActivationType can be Foreground (bring the app to front), Background (run a background task without showing UI), or Protocol (launch another app or URI entirely). The finished XmlDocument is wrapped in a ToastNotification object and shown via ToastNotificationManager.CreateToastNotifier().Show().
Cricket analogy: Like a match-report template with fixed slots for the headline, a hero photo of the winning six, and a view-scorecard button — the adaptive toast schema similarly has fixed slots for text bindings, a hero image, and action buttons that a developer fills in.
<toast activationType="foreground" launch="action=viewOrder&orderId=4471">
<visual>
<binding template="ToastGeneric">
<text>Order shipped!</text>
<text>Your order #4471 is on its way.</text>
<image placement="hero" src="ms-appx:///Assets/ShippedHero.png" />
</binding>
</visual>
<actions>
<action content="Track package" arguments="action=track&orderId=4471" activationType="foreground" />
<action content="Dismiss" arguments="action=dismiss" activationType="background" />
</actions>
</toast>Live Tiles and Tile Templates
TileUpdateManager pushes update XML to a pinned Start tile at one of its supported sizes — small, medium, wide, or large — each of which shows a different amount of content, from just an icon and badge on small up to a rich multi-line layout on large. Each tile can hold up to five queued notifications at once, which Windows cycles through automatically over time without any app code needing to run again, giving the appearance of a constantly refreshing tile from a single update call. Separately, BadgeUpdateManager sets a small numeric or glyph badge (like an unread count) in the corner of the tile, independent of the main tile content.
Cricket analogy: Like a stadium's rotating LED perimeter boards cycling through five different sponsor messages in sequence throughout a session — a tile's notification queue similarly cycles up to five queued pieces of content on rotation.
Push Notifications via WNS
To receive push notifications, an app first calls PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync() at startup, which returns a unique channel URI identifying that specific app installation. That URI is sent to the developer's own backend server, which stores it against the relevant user record. When the backend wants to notify that device, it authenticates with WNS using the app's package security identifier (SID) and a client secret generated in Partner Center, then POSTs the notification XML payload to that channel URI — WNS handles final delivery to the device, even if the app is fully closed.
Cricket analogy: Like a broadcaster registering for a unique satellite uplink frequency with the network before every live match, then feeding footage through that specific channel — the app registers a unique channel URI with WNS before the server can push anything through it.
The push notification channel URI is not permanent — it can expire or change, particularly after an extended period offline or an app reinstall. Backends should treat WNS delivery failures (such as HTTP 410 Gone) as a signal to discard the stored URI and prompt the app to re-register a fresh channel.
- Notifications reach users through three paths: local (app-raised), scheduled (queued for a future time), and push (delivered via WNS even when the app is closed).
- All three render through the same adaptive toast XML schema, most easily built with ToastContentBuilder.
- Toast actions have an ActivationType of Foreground, Background, or Protocol, controlling what happens on tap.
- TileUpdateManager updates pinned Start tiles across small/medium/wide/large sizes, each with different content density.
- A tile's notification queue holds up to five updates that Windows automatically cycles through over time.
- BadgeUpdateManager sets a numeric or glyph badge independently of the main tile content.
- Push notifications require registering a channel URI via PushNotificationChannelManager and sending it to a backend that authenticates with WNS using the app's package SID and client secret.
Practice what you learned
1. Which notification delivery path works even when the app is fully closed and the device wasn't expecting anything?
2. What does a toast action's ActivationType of Background do?
3. How many queued notifications can a single live tile hold and cycle through automatically?
4. What must an app obtain before it can receive push notifications?
5. What does a backend server need to authenticate with WNS before sending a push notification?
Was this page helpful?
You May Also Like
UWP Background Tasks
How Universal Windows Platform apps run code while suspended or not in the foreground, using triggers, conditions, and a constrained execution model.
UWP App Capabilities
How Universal Windows Platform apps declare and request access to system resources like the microphone, location, and internet through capability declarations in the app manifest.
UWP Sensors and Devices
How Universal Windows Platform apps read hardware sensors like accelerometers and compasses, query location, and enumerate connected devices such as cameras.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics