To wrap up this Q&A series and following from yesterday’s Live Tiles Q&A, I have a few more specifically related to toasts. Do note that half of yesterday’s post applies to tiles and toasts equally, specifically those parts related to WNS.

 

Question: Do scheduled toasts work in Connected Standby mode?

Answer: Yes. Typically an app that wants this behavior also needs to be lock screen-capable, and the user will need to add that app to their list of lock screen apps through PC Settings.

 

Question: Is it possible to set the background color of the toast to be different from apps default background color?

Answer: No, the toast background color is tied to the app’s tile background color. This is an aspect of branding so that users can visually see where the notification is coming from. This is one reason why apps cannot access the current system color scheme, otherwise they’d be able to spoof system notifications.

 

Question: I’ve found that is my server sends more than 7 toast notifications only the first 7 will actually appear. Is this a known limitation? Can it be modified on a per app basis?

Answer: Only three toasts can be displayed on the screen at once, and there is a fixed limit on the number of toasts that will be queued for later display. These are per-user limits, shared between apps. An app cannot increase it’s own limit. If there is need to show more information from an app, consider aggregating those notifications such that fewer needs to be send.

 

Question: Can I configure locally-issued toasts to only appear when my app is in the background?

Answer: Not directly, as the toast API doesn’t have such an option. You’ll need to monitor your app’s visibility state directly and suppress notifications when you’re visible.

 

Question: Is it possible for a desktop app (full trust) to suppress notifications like the user can do through PC Settings?

Answer: Toast Notifications will be dropped if the QUNS state is QUNS_PRESENTATION_MODE or QUNS_RUNNING_D3D_FULL_SCREEN. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb762533(v=vs.85).aspx.


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 http://www.sitepoint.com/publishing-mysql-data-web/. 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 http://php.net/manual/en/function.parse-url.php). 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 http://www.asp.net/get-started, such as http://www.asp.net/web-pages/tutorials/data/5-working-with-data.

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 http://msdn.microsoft.com/en-us/library/windows/apps/hh465435.aspx#pncodes_x_wns_cache.Cached 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 http://msdn.microsoft.com/en-us/library/windows/apps/hh465435.aspx 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.        


I found I had a collection of various questions and answers about the Windows Store, so I thought today to bring them all into one post.

 

Question: How do you detect that the user cancels an in-app purchase within requestProductPurchaseAsync? It doesn’t return an error in this case.

Answer: If the user cancels the purchase, the requestProductPurchaseAsync method will still invoke your completed handler, as the dialog was successfully displayed. It only produces an error if the dialog couldn’t be shown. What then determines whether the purchase was successful is whether or not there’s a change in the CurrentApp.licenseInformation object once the dialog is finished. An easy way to do this is to consolidate license handling within the CurrentApp.licenseInformation.licensechanged event. If the in-app purchase goes through, this event will be fired; if the user cancels, there won’t be any event and the app can just continue as usual. It all depends on whether you want to take additional action in response to the cancellation rather than purchase success.

Alternately, within the completed handler for requestProductPurchaseAsync you can get CurrentApp.licenseInformation, then call its lookup(productId) method and check the isActive flag for that in-app purchase.

 

Question: Is there a cached copy of the app’s licenseInformation object for offline scenarios?

Answer: Yes, license information is always kept up to date for apps, including in-app purchases. Apps do not need to cache license information separately for offline situations.

 

Question: Are receipts available offline?

Answer: No, you need to be online to access receipts.

 

Question: Is there a way to get the most recent version of my app in the Store so I can compare the current version that’s running?

Answer: At present the Windows Store and the WinRT APIs don’t support this. That is, you can get the running app’s version from Windows.ApplicationModel.Package.current.id.version, but there isn’t an API to get the version in the Store. Developers who require this for whatever reason typically create a web service endpoint that can respond with that information (clearly you’d update that service’s response when you update the app in the Store). Do be mindful to not pester the user about updates, because the Store already provides a means for that; use it sparingly.

 

Question: If I have an update command in my app, how do I send the user to the Store to install the update?

Answer: You can do this through Windows.System.Launcher.launchUriAsync with an ms-windows-store: URI (in an instance of Windows.Foundation.Uri). Use of this URI scheme is documented on Linking to your app. To link to your app’s page in the store, use a string created with “ms-windows-store:PDP?PFN=” + Windows.ApplicationModel.Package.current.id.familyName. To go to the overall updates page, use ms-windows-store:Updates.

 

Question: Can an app hide select in-app purchases? Say that I want to show a certain purchase only a particular date, perhaps to offer a special combination of features A and B together instead of separately. Can I do this, and will it affect certification?

Answer: The Store itself doesn’t show in-app purchases to the user: this is completely under the app’s control. That is, you simply filter the product listings you get from ListingInformation.productListings and show only those you want. In this case your combined A+B product would be a separate product listing that you create through the Store dashboard, but at runtime you’d determine when to display it. It just shows up as another in-app purchase so won’t be an issue with certification.

 

Question: Along these same lines, if in an update to my app I no longer want to offer A and B separately, just the A+B combination, how do I approach that?

Answer: Because you cannot remove A from the Store (you have no guarantee that all users will update the app), the app update will need to filter out those in-app purchases that it longer wants to appear. Simply said, because each product has its own Id, the updated app can basically have a built-in list of productIds that it just won’t show in its UI.

 

Question: My app failed certification because of a crash. How do I know what happened?

Answer: In late January 2013, the Store began to include crash reports from the certification process. For details, see Crash reports help you certify your Windows Store app on the Windows Developer Blog.

 


As the WinRT API is laced with async methods, having a robust approach to testing async behavior is very helpful for producing a robust app. Here are a few keys suggestions.

First, test re-entering a page multiple times when that page starts async operations. That is, navigate to a page that starts those operations, navigate away, then navigate forward again. Repeat a few times. Ideally what’s happening in the code is that any unfinished async operation is canceled then you leave the page. Otherwise this test can produce redundant operations that could collide.

More generally, the suggestion above means to plan and test for cancelation. With this, look at behaviors in your UI that depend on async operations either being started or completing, such as enabling/disabling controls.

You can also insert random delays in your code for async calls. In JavaScript this would mean creating a promise with WinJS.Promise.timeout(<delay>) and adding that to your chain. In C#/VB, use await Task.Delay inside an #ifdef DEBUG.

In JavaScript, because we don’t have #ifdef and because a new promise inserted into a chain needs to deliver meaningful results from the previous step in the chain, a good approach is to create a function that has as its return value a function that can serve as a completed handler in the chain. For example, assume you have a chain like this:

operation1().then(function (result1) {
return operation2(result1)
}).then(function (result2) {
return operation3(result2);
}).done();
You can create a function like this to create a delaying completed handler, where the debugMode flag would be a global variable that determines whether to create a delay promise with the previous result in the chain, or just deliver it through WinJS.Promise.as which adds very minimal overhead:

function insertDelay(delay) {
return function (result) {
if (debugMode) {
return WinJS.Promise.timeout(delay).then(function () { return result; });
} else {
return WinJS.Promise.as(result);
}
}
}

Inserting into the chain would be like this:

operation1().then(function (result1) {
return operation2(result1)
}).then(insertDelay(1000))
.then(function (result2) {
return operation3(result2);
}).done();

 


In any discussion about animations, the GPU always comes up for good reason: anything that runs in the GPU will simply perform better in terms of UX and power consumption. If you hear the term “independent animation,” this refers to an animation that fully runs in the GPU. A “dependent animation” is one that runs on the UI thread.

In JavaScript, anything that you animate directly within setInterval, setTimeout, and requestAnimationFrame is a dependent animation, because you’re clearly doing all the work in code. This is unavoidable in many scenarios, like games, but then the point of the game is to play with graphics and animations so you’re not quite as worried about the GPU. It’s worth noting that at present, apps written in JavaScript don’t have access to the GPU outside of doing independent animations via CSS. Eventually I imagine that WebGL will become available which should change that story.

To run a CSS animation in the GPU, the key thing to remember is that you must be animating only the opacity and transform properties of an element. That’s it. You can actually do quite a bit with just these two properties: any kind of fades along with manipulations of size, 2D and 3D rotation, perspective, and so on. It just means that you need to be aware of how you and third-party libraries you might use define animations.

The animations library in WinJS.UI.Animation are all defined to be independent. The little bounce animation for a button click, pointerDown, for example, does a 97% scale transform, and its counterpart, pointerUp, restores the scale to 100%. You could, of course, achieve the same effect through the margin or padding properties, but then the animation would run in the UI thread.

In designing your dynamic UX, then, really become versed in what you can achieve with opacity and transform, and design around that. If, on occasion, you need dependent animations, that’s fine too. Just be careful to not overuse them to keep your app performing its best.



If you plan to use ads in your app with the Microsoft Ads SDK, be very aware that at present you must set the age rating of your app to 12+ or else ads will not appear. This is described on Submitting an App with Ads to the Windows Store. You can still submit an app with a lower age rating but no ads will appear, so you’ll wonder what’s going on. Also be aware that you definitely need a privacy policy for your app when using ads or Store certification will reject it.

Update: one developer has told me that his app in the Kid’s category of the Store is rated at 7+ and ads show up, so there might be an exception for Kid’s apps or the ads SDK has been updated to provide for a lower age rating. Check with the ads SDK for current status.


Two small bits today about a couple of WinRT APIs, or, in the first case, the lack thereof.

Developers sometimes ask how to get at the system colors that the user has assigned to the Start screen. The answer is simply that you can’t. The reason for this is that to prevent apps from spoofing system UI, such as permissions dialogs, which would deceive the user as to who is asking the question. In the design of Windows Store apps, color is specifically used as a branding element for apps, so the system colors are also a branding for Windows. Apps should always use their own coloring for UI.

The second and completely unrelated bit comes from a forum question where a developer wanted to schedule thousands of tile updates in advance (up to the overall limit of 4096!). In some circumstances he wanted to clear all those out and start afresh, but would that the TileUpdater.clear() method didn’t work for this. This is a simply misunderstanding: clear removed only the currently displayed update from the tile. To remove scheduled updates you instead need to use TileUpdater.removeFromSchedule. That docs page also shows how to use this in conjunction with getScheduledTileNotifications to clear all scheduled updates.


In Windows 8, the in-app purchases supported by any given version of an app must be defined with a product ID when the app is uploaded to the Windows Store. This means that you have to update the app in the Store to add additional product IDs. This can pose a challenge to apps that want to offer more dynamic content through in-app purchases, especially media content like books, recipe collections, and so on, where those content collections aren’t necessarily known ahead of time.

In these cases, and app can still download content once a license for the product ID is purchases; the Windows Store doesn’t produce a mechanism for download-on-purchase, but an app can certainly do that itself.

To work with dynamic purchases, the trick is to define a number of placeholder IDs for future in-app purchases when uploading the app. At runtime, when creating your in-app purchase UI, you’ll retrieve the list of product ID from the WinRT API, then have your service (likely the one from which you’d download the content), check those IDs and tell you which ones are presently valid, that is, which ones have real content assigned to them. The app then only displays those products are valid and ignores the rest.

Later on, if the user returns to the in-app purchase UI, additional content might be available and would thus appear. Of course, such an app would likely check with the service periodically to know when new content has been added so it can alert the user and encourage a new purchase!


If you’re looking at using Bing Maps in an app, you easily expect that you’ll get pretty good worldwide data. The geographic coverage of Bing Maps can be found here: http://msdn.microsoft.com/en-us/library/dd435699.aspx.

That said, there are some regions where Bing Maps itself won’t work, as documented on http://msdn.microsoft.com/en-us/library/jj670541.aspx (or http://msdn.microsoft.com/en-us/library/hh852186.aspx): Argentina, Azerbaijani, China, India, South Korea, Morocco, Pakistan, Singapore, Serbia, and Venezuela. That is, if your app is running on a machine located in one of those regions, you won’t get map data because of various geopolicitcal matters.