Following from yesterday's Store Q&A, I have another collection for live tiles. Note that WNS here refers to the Windows Push Notification Service.

Question: The code sample on Quickstart: Sending a push notification is written in C# but says C++ in the title. How do I do this in C++?

Answer: This code on MSDN is meant to be used from a ASP.NET web service, not an app, hence being written in C#. All that you need to do from an app is post a channel URI to that service, then the service uses the code in PostToWns whenever it needs to send an XML payload to that channel. Presumably this service is running all the time, so push notifications happen regardless of whether the app is running at all. Posting to WNS from an app is generally unnecessary, as a running all can just send the XML update to the appropriate WinRT API to have it show up on the tile or toast as needed. Going to WNS would be a very roundabout way to accomplish the same thing. If you'd like your service to trigger push notifications to other devices, then you'll need a service endpoint for that purpose. Windows Azure Mobile Services makes this much simpler; see Alive with Activity, Part 3: Push notifications and Windows Azure Mobile Services on the Windows Developer Blog.

Question: How do I test the different scaled images for my tiles, such as those in my manifest?

Answer: Scaling goes into effect on devices with different pixel densities (dpi), which is a different concern from screen size. A 1920×1200 screen (like my 15.7” laptop screen or my 24” desktop monitor) are 96dpi devices so Windows employs a 100% scaling. If, however, I had the same resolution on a smaller screen, like the 10.6” on a Surface Pro, then Windows will employ 140% scaling, and then use alternate graphics. You can test your scaled images in the Visual Studio simulator or through Blend’s device tab. In the latter, for instance, you’ll see that the different options indicate the scaling %’s in effect:

6-6 (Blend resolutions)

See Guidelines for scaling to screens and Guidelines for scaling to pixel densities for the differences between screen resolution and DPI considerations.  


Question: I've read your book's Chapter 16 [13 in the first edition] with the sample HelloTiles web service to support live tiles. Is there a step-by-step guide to creating a web service in Visual Studio? I'm new to the services scene.

Answer: The main thing is to first understand how the backend in your chosen language gets at the data it needs. In PHP, you might be accessing a MySQL database, which would be very common. In that case, you could try starting at That would show how to extract the data you want, then it’s a question of wrapping that up into the XML payload.

All this really means is using the PHP echo function to output the XML with the values of variables inserted. The samples that these pages show are outputting HTML, but you’d simply be outputting the XML instead. You can then extend the service by allowing URL parameters, for which you’re use parse_url in PHP to get at the individual components (see You can then feed those parameters into your database queries to customize what’s being returned.

Those URL parameters would simply be part of what the client app includes in the URL it gives to Windows for periodic tile updates…Windows will just send a request to that URL. If that’s your PHP page, then your code executes, you process the parameters, run the query, then emit the XML as output (the request response). If it’s properly formatted, you’ll then see the tile update. In ASP.NET you’re pretty much doing the same thing, just in another language, e.g. querying a SQL Server database but again emitting the XML as the “page” that you’re server-side code is generating. You can find many tutorials on, such as

Again, these tutorials as going to show creating a web page response (HTML), but you’ll just be emitting the XML instead. Generally speaking, Visual Studio is better set up for ASP.NET/WebMatrix than it is PHP. WebMatrix was designed to be a closer analog to PHP than the full ASP.NET (where you basically never see the HTML or XML output). Also, Windows Azure Mobile Services will be making it easy to create an endpoint without having to spin up a whole service of your own.  Keep an eye on that.


Question: Can I use a push notification to reset a live tile previously updated with a push notification, other than just waiting for it to expire?

Answer: Not really. There's not a general purpose "reset" with WNS. One thing you can try is to send your real notifications with a particular tag (X-WNS-TAG), then send another one later with the same tag and a very short expiration time. However, there's no guarantee that the update will go through, so it's not foolproof. In the end, it's probably better to come up with some other interesting content as a generic tile update that would serve as your "clear".  

Question: How do I set an expiration time for a push notification?

Answer: Calculate the number of seconds that you want the update to live from the time you post to WNS. Include that value in the X-WNS-TTL header.  

Question: I understand that WNS does guarantee deliver of push notifications. How often will WNS attempt delivery of cached messages when messages have the X-WNS-Cache-Policy set?

Answer: See notifications will be delivered automatically when the device next comes online. They may be dropped by the server after a few days if the device is not seen.

Question: Does WNS support multicasting a single push notification to multiple device endpoints?

Answer: WNS doesn't offer this directly, no. Toolkits built on WNS can offer such capabilities. however.

Question: How do I handle expiration of an OAuth token for push notifications? To be specific says, "An access token is returned in the HTTP response if the cloud service successfully authenticated. This access token can be used in notification requests until it expires." How does one detect the expiration – the response shown in doc doesn’t include expiry or a refresh token. Will the POST to WNS return a 403 or some other code and then I need to reissue request for a new access token? What’s the recommended approach for handling the scenario in code?

Answer: The recommended approach is to store an access token and push notifications using that access token until an error code is returned.  At that point, the app service should reauthenticate with WNS and request a new access token for pushing notifications (again using that token until an error code is returned). The documentation states that WNS uses the 401 error code to indicate that an access token has expired.        

Comments are closed