Glance & Go! Get back to life 🙂 These have been the kind of concepts Windows Phone has been trying to be good at; only time will tell how successful we have been at this game. However, Push Notifications are undoubtedly one of the coolest features of the Windows Phone ecosystem. The Start screen comes alive with Live Tiles and Push Notifications from the cloud. And this gets way better with the next Mango release.
In addition to pinned Application tiles, we can now programmatically create Secondary Live Tiles for our apps; tiles that are deep-linked to bring the user directly to a certain area of the application, often bypassing the start experience when the app is launched under normal circumstances. These livelier secondary Live Tiles also have a nice flip animation built in to expose a back side of the tile with extra information. And just like application tiles, the secondary tiles can be updated with Push Notifications through the Microsoft Push Notification Services (MPNS). In addition, we can now have Deep Toasts — ones with extra parameters and when clicked, not only launch the app; but also gives the developer the opportunity to use the parameters to take the user to a certain part of the application.
A nice walkthrough of these new Mango Live Tile features, along with code samples can be found (here).
All this however raises the question, what needs to change for Push Notifications? Thankfully, not much! We use the same ways to create or re-use Channel URIs from MPNS and convey that to our cloud service for use in Push Notifications. The secondary Live Tiles are each created with a unique URI and we need to inform our cloud service of this extra piece of information so that we may control exactly which secondary Live Tile we update with our Push Notification. And we use the same APIs (BindToShellTile & BindToShellToast) to register our Tile & Toast updates to the Shell, so that the OS processes those incoming Push payloads. That brings us to the main story — so what exactly does your cloud service need to send out in the Push Notification HTTP Post to MPNS? Glad you asked! I often fiddle & have to look up these payloads. So, why not try to compile?
In the present Windows Phone OS 7.0, this is how the Payload looks for a pinned Application Tile Push update:
And, here is what we need to send for a Toast update:
<wp:Notification xmlns:wp="WPNotification"> <wp:Tile> <wp:BackgroundImage>someURI<wp:BackgroundImage> <wp:Count>XX</wp:Count> <wp:Title>someTitle</wp:Title> </wp:Tile> </wp:Notification>
Come Mango or Windows Phone OS 7.1, our cloud service needs to send some extra bits to MPNS to have the fine-grained control of exactly which Secondary Live Tile to update. Here’s the payload to update a Secondary Live Tile; notice the extra ID & back-of-tile bits:
<wp:Notification xmlns:wp="WPNotification"> <wp:Toast> <wp:Text1>someText</wp:Text1> <wp:Text2>someLongerText</wp:Text2> <wp:Toast> </wp:Notification>
And, this is how we should construct a payload for a Deep Toast, so that the app gets a chance to process the extra parameters & navigate the user to a certain part of the application:
<wp:Notification xmlns:wp="WPNotification"> <wp:Tile ID="/MainPage.xaml?someParam=someID"> <wp:BackgroundImage>someURI<wp:BackgroundImage> <wp:Count>XX</wp:Count> <wp:Title>someTitle</wp:Title> <wp:BackBackgroundImage>someURI</wp:BackBackgroundImage> <wp:BackContent>someContent</wp:BackContent> <wp:BackTitle>someTitle</wp:BackTitle> </wp:Tile> </wp:Notification>
That’s it for now. Go ahead & Push enable your WP7 apps — they should sell better & be rated higher compared to their ordinary counterparts.
<wp:Notification xmlns:wp="WPNotification"> <wp:Toast> <wp:Text1>someText</wp:Text1> <wp:Text2>someLongerText</wp:Text2> <wp:Param>/MainPage.xaml?someParam=someID</wp:Param> <wp:Toast> </wp:Notification>
2 thoughts on “Push Notification Payloads”