Developers sometimes ask about handling devices with different screen sizes, and whether that was something you’d could do with media queries in addition to the media queries for the different view states (snapped, filled, fullscreen-landscape, and fullscreen-portrait).

The answer is really to use adaptive (aka responsive) layout techniques with CSS so that you don’t really worry about screen size—you’re typically only writing media queries for the view states, since the relative positioning of items in the page layout can change quite a bit between them. In those view state media queries, you might be changing the size of an element that contains a grid layout div, or that of a ListView, or some other control, where that size change will trigger a resize event that a control like ListView picks up to refresh its layout. Apps also use the same event to change the layout of a ListView according to view state, such as switching between GridLayout (2D) and ListLayout (1D, vertical).

It’s worth noting that inside media queries there are the vh and vw units (viewport height and viewport width) that can be used like px, em, etc. That is, saying height: 6.5vh in CSS will give you 6.5% of the height of the app window. You can certainly accomplish the same thing with a CSS grid, where you know that certain fractional rows/columns will essentially come out the same thing. For example, if you have a grid that’s styled to 100% width and height, and use –ms-grid-columns: 1fr 1fr 1fr 1fr; that’d be the same as using –ms-grid-columns: 25vw 25vw 25vw 25vw. Or –ms-grid-columns: 25% 25% 25% 25%. But if that element was only 50% width, then the 1fr and 25% values will scale, but the 25vw would not, unless the display width itself changed.

I mention those because if you have layout that’s not strictly proportional and does depend on screen dimensions, you can use vh and vw like this, or you can standard media queries against width and height, combined with the view states, as needed. For example, say in snap view you’ll have your base layout for a 768 vertical dimension, but if you’re on something greater than, say, 1200, you might want to include another piece of information in the header or such. In that case, the extra element would be present in the HTML, then you’d have a media query like this:

@media screenand(-ms-view-state: snapped) and (max-height: “1199px”) {

wherein you might set display: none for that extra element.

Within JavaScript you can also obtain window and element dimensions as you need them if you’re working with layout programmatically (such as cases where you need to do some extra computation).

So it really depends on what you need to do, layout-wise, but the platform can provide all the information you need both declaratively and programmatically. You can also use Media Query Listeners (another W3C standard) to get events for view state changes.

The documentation for this property has this to say: “Determines whether or not binding should automatically set the ID of an element. This property should be set to true in apps that use Windows Library for JavaScript (WinJS) binding.”

This is rather enigmatic, and the remarks section doesn’t make it much clearer when it says, “Set this property to true to avoid setting the ID of an element automatically.”

This flag was added late in the developer of Windows 8 to get around a memory leak. What was happening before is that WinJS was automatically creating an ID property for all elements involved in data binding, due to the implementation of its binding engine. However, this introduced the leak because the table in which the wwahost.exe process stores such IDs never gets cleaned up.

Generally speaking, apps didn’t depend on these IDs being created, so the WinJS team could have just made the change internally and no one would’ve noticed. However, it did constitute a breaking change so the optimizeBindingReferences flag was added such that an app that did have that dependency could turn it off.

The bottom line is that apps should set this flag to true and leave it set, thereby reducing the app’s memory footprint.


Working with tiles, badges, and toast notifications is a wonderful way to have your app surface information to the user when it’s not in the foreground or not running at all. Because of this, however, it can be difficult to debug updates or notifications that aren’t working. If there’s something wrong with the XML or the contents of an update, then it might not display at all, which can be difficult to figure out. So I wanted to offer a number of things you can do or check when you encounter problems.

First, consider something like the following scheduled XML payload for a toast notification:

<toast><visual><binding template=”ToastImageAndText04″>
<image id=”1″ src=”ms-appdata:///local/some_image_created_dynamically.png” />
<text id=”1″>Some text 1</text><text id=”2″>Some text 2</text><text id=”3″>Some text 3</text>

Let say you’ve called the necessary APIs to get this up, but it doesn’t appear at the appropriate time. Why? For one, consult the troubleshooting guide that’s found in the docs. But let me add to that some.

For one thing, the XML could be malformed–Windows will reject any tile, badge, or toast where the elements inside <binding> don’t match the template indicated in binding.template. To compare, run the App tiles and badges sample and go to Scenario 5. This is less of a sample and more of tool that lets you generate tile updates, where you can then see the resulting XML. It’s also worth pointing out that the XML text should always be UTF-8 encoded (contrary to the troubleshooting guide’s statement about UTF-16, which is a doc bug). I’ve also found that Windows is somewhat picky about extra line feeds at the top of the XML.

For scheduled notifications, check to make sure that you’re actually scheduling a time in the future. See the Scheduled notifications sample for reference.

Next, be sure that any image.src property is a valid URI, for one, but also make sure that the target image is 1024×1024 or smaller, and 200KB in size or smaller. Windows will not display larger images. In the example above, the overall toast will still appear, but it will have a blank image if Windows can’t find the image file or if the image is too large. In general, a blank image shows up when there is some problem loading that image.

You can also use the event log. In the event viewer, navigate to Application and Services Logs > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI > Operational tile where tile activity takes place. Note that you need to click on the Details tab to see which app was involved as the General tab doesn’t show that.

Speaking of the event viewer, note also that Application and Services Logs > Microsoft > Windows > PushNotifications-Platform > Operational has additional events about push notifications.

For push notifications in particular, it’s absolutely essential that the package ID in your manifest exactly matches what you have in the Windows Store. Using the Store > Associate App with the Store command in Visual Studio will make sure of this.



To continue from my previous post, here are some additional performance tools to know about.

First is a JavaScript memory analyzer that was just put out a short time ago. Read about it here:

Second, here are topics in docs on performance analysis:

Analyzing performance of Windows Store Apps

Timing and Performance APIs (HTML/JS)

Analyzing memory usages in Windows Store Apps (HTML/JS)

Analyzing the code quality of Windows Store apps with Visual Studio code analysis (C#, VB, C++)


Finally, there are two posts on the Windows 8 Developer Blog that are relevant:

How to improve performance in your Metro style app

Tackling performance killers: common performance problems with Metro style apps


When implementing Accessibility support in an app, it's very important to be sensitive to the contrast in images. As I wrote in Chapter 17 of my book:

Technically speaking, high contrast is defined by the W3C as a minimum luminosity ratio of 4.5 to 1. A full explanation including how to measure this ratio can be found on A Contrast Analyzer (from the Paciello Group) is also available to check your images (some of mine in Here My Am! failed the test). Do note, however, that creating high contrast graphics isn’t required for non-informational content such as logos and decorative graphics. At the same time, full-color graphics might look out of place in a high contrast mode, so be sure to evaluate your entire end-to-end user experience under such conditions.

The contrast ratio is what you need when you want to make high-contrast graphics that are still in color–this is what I had to do with the Here My Am! graphics. The original ones I received from Microsoft Press, which I use for "standard" contrast, look like this:


Running the two colors (#FFFFFF and #00B294) here through the contrast analyzer, I'm told that it's ratio is only 2.69:1. So in a graphics editor (I use the free Paint.NET), I tweaked the Value portion of the HSV to proportionally darken the teal color down to #005C36 which gives an 8.13:1 ratio:


This is well beyond the 4.5:1 ratio, and passes all the test of the Contrast Analyzer. (I could have used #00663B which is a touch brighter and passes at 7.09:1). I use this as the high contrast image (color).

Then I needed to make black on white and white on black variants. The easy way to do this in Paint.NET was to first convert to grayscale, then use the Levels adjustment. For black on white, I converted the original (standard contrast) image to grayscale and inverted the colors:


Then I used the Adjustments > Levels command to set the input levels at 0 and 128 with outputs at 0, 1.0, and 255:



This created black on white (light border added):


After this, another Adjustments > Invert Colors command produced the white on black:


The Windows App Certification Kit or WACK, which is part of the Store Certification process, is something you should be running every day during app development to see if it comes up with any problems.

Typically it warns about startup time and suspend time, almost invariably, but it’s good to really watch these conditions because of the automatic deadlines built into Windows. To review, if an app takes more than 15 seconds to create its first window (and thus tear down the default splash screen), and the user switches away, Windows will terminate that app. If the user doesn’t switch away, mind you, the app will continue to launch. With suspend, if the app doesn’t return from its suspending event handler in five seconds, it will also be terminated.

Under optimal conditions, you typically don’t need to worry about these things, but if you’ve learned anything about testing you’ll know that apps seldom run under optimal conditions!

On such non-optimal condition is when there is a lot of disk and/or network activity going on at the same time, such that your app will experience slower than normal response from disk/network APIs. For example, the app might be trying to load file data from its package during startup, or might be trying to make various XmlHttpRequests on suspend. When there’s a bunch of activity going on, an operation that takes half a second normally might take much longer and perhaps cause the app to exceed the time limits.

This means two things. First, be sure to test app launch and suspend when other stuff is going on. Try, for instance, to launch your app as soon as you can after booting the system, when there’s still other disk activity. Or do some intensive operation on the file system (like run the Disk Cleanup tool) and see what happens when you launch or suspend. Try the same things after you’ve started a few large downloads and a few uploads, so your app has to compete with those transfers.

Second, implement your app to be resilient to high latency. If in the above tests you find that startup can take a long time, be sure to implement an extended splash screen to give yourself as much time as you need. For suspend, you can first take the approach to write/transfer as much state data to disk before suspend occurs (i.e. when the data changes), thereby minimizing the work that’s necessary during the event itself. Also avoid making the assumption that you can do the full load of possible work when suspending. If there’s doubt, create a strategy wherein you save the most critical data first, then attempt additional stages of secondary work if there’s still time. The suspending event tells you the deadline for completing your work, so you can keep checking elapsed time after each operation to see if you want to start another.

In any case, running your app under high-latency conditions will also show you where you might increase performance and/or show progress indicators where you haven’t before, because tests under optimal conditions never showed the need for such.


Developers have sometimes asked what apps should do if edge gestures are accidentally invoked, especially for time-sensitive games.

Generally speaking, such apps should pay attention to when they lose focus, which can happen for left/right edge gestures as well as being snapped in favor of another app going into filled view and thus taking the focus. Many games, for instance, pause when snapped (also for playability's sake) and when the charms bar is invoked. The focus events that you can obtain on the top-level app window (e.g. the window object in JavaScript) help you out here.

For top/bottom swipes, these will invoke your own app bar if you provide one (otherwise they have no effect). In this case you can use the beforeShow/beforeHide (WinJS) or Opened/Closed (XAML) events to know when this happens.

More fundamentally, you can also use the events in Windows.UI.Input.EdgeGesture to detect the top/bottom swipes but this is a somewhat lower-level mechanism.

If you haven't seen it, the Designing great games for Windows topic in the docs is also worth a read on many other important points.


In addition to section 1.1 of the Store Certification Requirements, which is general enough to allow rejection of any app that just attempt to wrap a website, section 3.9 come into the picture when you have a legitimate app that wants to use web content in some way:

3.9 All app logic must originate from, and reside in, your app package

Your app must not attempt to change or extend the packaged content through any form of dynamic inclusion of code or data that changes how the application interacts with the Windows Runtime, or behaves with regard to Store policy. It is not permissible, for example, to download a remote script and subsequently execute that script in the local context of your app package.

The wording of this policy certainly allows for hosting web content within an <iframe> element (HTML/JS) apps or a WebView control (XAML apps). A number of reader apps (as for blogs) do this routinely, where the app is processing an RSS feed to provide a nice view of the overall content, then displays specific posts within an iframe/webview. That hosted content can run script within its iframe/webview sandbox.

In such cases, the app typically provides for different view states, handles touch input, provides app bars and appropriate navigation controls, and might implement other OS integration points that clearly add value. That is, while the app is clearly hosting web content, it’s not relying entirely on that hosted content for the user experience.

Now an app might have pages that are entirely created with hosted content, where that web site is set up to provide a user experience that is indishtinguishable from a native app. The tricky part here is supporting functions like snapped view, which would have to be done with responsive CSS design and so forth. The app would also need to pass messages (via postMessage in HTML or InvokeScript in XAML) to implement things like app bar commands.

So would such a thing violate section 3.9 above? It’s something of a gray area. The key factors are (a) whether the hosted content attempts to modify the in-package contents through injection of HTML/JS, and (b) whether you’re attempting to pass script or other data that would cause the main app, which has access to the WinRT API, to behave in a way that either breaks Store policy or changes the behavior of the app from what it says it does.

What’s really at stake here is user safety and confidence. First, dynamic injection of script and other content within the app can pose security risks that the user may not be aware of. Second, such a dynamic nature can deviate well away from what the app says it does in the Store, hence eroding user confidence because it makes it possible for an app to say one thing in the Store and do completely different things at runtime.

This is really to say that all content that interacts with the WinRT API must be included in the app package, so bringing down any kind of script or code and executing that within the app (e.g. in the local context of an HTML/JS app) is not allowed. Bringing down HTML/CSS/JS (or XAML for that matter) and rendering that in a sandboxed viewport of some kind (which includes implementing your own renderer) is allowable.

I’ve seen this come up a number of times recently on the MSDN forums–apps that are using what appears to be a valid relative URI in the app package, like images/someImage.png, but that URI fails to work as expected. This happens from within HTML, CSS, and JavaScript.

Most often this error is caused by using such a reference from inside a WinJS page control, where the context for relative URIs is the page HTML file itself, not the default.html page that into which it’s loaded. That is, from a default.html page in the package root (or a CSS file on that level), a relative URI to a folder that’s exists on the same level in the package will work. However, page controls are typically stored in subfolders, like pages/home/home.html (and .css), in which case a relative URI would start at pages/home and look there.

In such cases, you could go up to parent folders, e.g. ../../images/someImage.png where the first two ..’s would go up from pages/home to the package root. This is somewhat fragile, however, and would break if you ever relocated the page control’s html tile in your project.

The best solution in such cases is to be sure to prefix the URI with a /, as in /images/someImage.png. The leading / means “package root” and properly references resources within the app package. This makes the URI an absolute URI in relation to the package root, and is effectively a shortcut for the true absolute URI form: ms-appx:/// or ms-appx://<package_id>/ (which says the package_id is optional). The leading / is thus the same as prefixing URIs with ms-appx:/// (the triple-slash version).

When in doubt, then, if some URI just isn’t working, especially with page controls, try preceding the URIs with a /.