Before submitting your app to the Store, take some time to review your app’s manifest and the information and files it references. Mostly concentrate on the Application UI tab in Visual Studio’s manifest editor. If you haven’t noticed or installed recent Visual Studio updates, the VS team improved the editor by bringing all of the app’s UI elements into the Application UI tab. Earlier, bits of UI like the Store logo were on the Packaging tab, which made it easy to miss. Now it’s all together, plus, it shows you every scaled version of every graphical asset (there’s so much to scroll now you can’t get it into one screen shot):

manifesteditor1 manifesteditor2

Here’s what to pay special attention to:

  1. Make sure that all logos (logo, wide logo, small logo, and store logo) are all representative of your app. Avoid shipping an app with any of the default graphics from the VS templates. Note that the Store logo never shows up in the running app, so you won’t notice it at runtime.
  2. Double-check how you’re using the Show Name option along with Short Name and/or Display Name. Go to the Start screen and switch your app tile between square and wide, and see if the tile appears like you want it to. In the graphics above, notice how the app’s name is included on the tile images already, so having Show Name set to “All logos” will make the tile look silly (see below). So I’d want to make sure I change that setting, in this case, to “No logos.” However, if my square tile, perhaps, did not have the app name in text, then I’d want to set it to “Standard logo only.”
    manifesteditor3
  3. If you set Short Name, its text will be used on the tile instead of Display Name.
  4. Be aware that if you’re using live tiles, the XML update for a tile can specify whether the display/short name should be shown in the branding attribute. See my post on the Windows 8 Developer Blog, Alive with Activity Part 1, for details.
  5. If you don’t have specific scaled assets, reevaluate your choices here. Remember that if you don’t provide a specific version for each given pixel density, Windows will take one of the others and stretch or shrink it as needed, meaning that the app might not looks its best.
  6. Examine the relationship between the small logo, your specified tile background color, and any live tile updates and toast notifications you might use. Live tiles and toasts can specify whether to show the small logo, and the tile background color is used in both instances. If you have a mismatch between the small logo edge colors and the background color, you’ll see an obvious edge in tiles and toasts.

 


Side-loading apps, which bypasses the Windows Store, is typically used for enterprise apps as well as running private betas and handling other limited-distribution scenarios. In many cases, you probably do want to collect feedback from your users. However, side-loaded apps do not have the Rate and Review command in their settings panels as do those that are acquired from the Store (see Guidelines for app settings). So the easy answer to the question in this post’s title is no, at least not automatically through the Store mechanism.

Is there a backdoor, perhaps? Nope. Side-loading means there isn’t a record in the Store database for the app, so there’s no app identity to which to attach ratings and reviews.

That said, the goal of ratings and review for a side-loaded app is very different than for those in the Store. In the latter case, ratings and reviews are important for marketing and visibility of the app. For more limited distribution, that’s not the case, and you’re really looking primarily to collect actionable feedback.

With that in mind, there are a few incremental approaches you can take depending on how much data you want. For starters, just a simple mailto: link in a settings command will make it easy to email feedback. This takes only a couple lines of code (see Mixing links and flyouts in Settings (WinJS) for some examples of links).

With a little more work, you can set up a web page with a feedback form, show that in a settings flyout using an iframe or webview, and have that page email the results to you. Another incremental step would be to have the page save feedback in a simple database, so you could query it and save yourself the data-entry step from the email approach.

In fact, for a beta app, having queryable data like this is much more useful than the data the Store could collect, which you can only browse on your product page anyway. A web form, as described above, could also gather more specific feedback that you wouldn’t get through a simple Review text field.

With all this in mind, putting in the extra work to collect feedback is well worth it!


For this post, let’s focus on section 3.5 of the requirements:

3.5 Your app must fully support touch input, and fully support keyboard and mouse input

Your app must provide visual feedback when users touch interactive elements.

Your app must not use an interaction gesture in a way that is different from how Windows uses the gesture. The Windows 8 touch language is described in Touch interaction design.

There are a number of things going on here that are worth thinking about more carefully.

The first sentence basically says that the app has to support multiple input modalities. To “fully support touch input” means that the app must be fully usable with only touch, which should be obvious given the increasing number of touch-only devices. This means that an app cannot have UI or features that are only accessible through a mouse or through a special keystroke. Usually this isn’t much of an issue, because using pointer events lets you handle touch and mouse with the same bit of code anyway.

The second half of the scentence is a little sketchy to my mind. Depending on how you read it, it might say “the app must be fully usable with only keyboard, as well as with only mouse,” or it can be read that “the app must be fully usable with keyboard and mouse together.” From what I’ve seen, certification makes the latter interpretation.

At the same time, I strongly encourage developers to provide complete keyboard-only interfaces as well as mouse-only interfaces. In doing so, you make the app much more accessible for people with disabilities. That’s really the reason why the UI guidelines for desktop apps that have been around for many years suggests things like keyboard accelerators for menus that can also be used with a mouse.

In this context I often think of a classmate of mine within the Electrical/Computer Engineering department at the University of Washington when I was an undergraduate there. Sometime in our senior year, he severed his spinal cord in a skiing accident and became a quadraplegic. But he still completed his degree, often using a computer keyboard with a rod that he held in his mouth. To this day I admire his determination to carry on despite his permanent injury, which means making a little extra effort of support full keyboard interactions and not rely on the mouse for some of it.

Anyway, the last two sentences of section 3.5 above apply only to touch interaction, and are pretty clear. The visual feedback requirement is important because it lets the user know that the app has detected the touch–a piece of glass, in other words, doesn’t give the tactile response that a keyboard or mouse does, so the acknwoledgement of input has to be visual. For this, the pointer down and pointer up animations in the animations libraries provide standard visual responses.

As for gestures, the point here is to avoid forcing users to retrain themselves for the sake of your app, which ultimately lowers their efficiency across the rest of the system. It’s a reminder that your app is not the only one running on the device, so be a good, cooperative player and avoid “innovating” in places like input where you’ll just cause confusion.

The last thing I’ll add regarding input is not part of Store ceritification, but also good to think about: sensors. As I wrote in my book, I like to think of sensors as another form of input, one that is a fresh area that’s open to all kinds of innovation. And because there’s nothing in Store certification related to how you use inclinometer, the compass, gyros, etc., you can be very creative here!


In WinRT, a number of APIs return a Windows.Foundation.Collections.PropertySet object. Two examples are the localSettings and roamingSettings objects within Windows.Storage.ApplicationData.current, whose values propert is a PropertySet.

In JavaScript, doing a simple for…in iteration on a PropertySet will give you not only the properties in that set, but also its methods, which is often unexpected. For example, the following code:

var ls = Windows.Storage.ApplicationData.current.localSettings;
ls.values[“property1”] = “value1”;
ls.values[“property2”] = “value2”;
ls.values[“property3”] = “value3”;

for (var key in ls.values) {
    console.log(“values[“ + key + “] = “ + ls.values[key]);
}

will not only output “values[property1] = value1” for each of the three values, but will also give you stuff like:

values[addEventListener] =
function addEventListener() {
[native code]
}

This comes as a result of how the PropertySet is projected from WinRT into JavaScript. It sort of works like an array, but not really, so you get this kind of behavior.

Seeing this, one option is to use the iteration methods of the PropertySet, meaning to call its first method to obtain an iterator, then using the iterator’s cumbersome current/moveNext semantics. This isn’t particularly enjoyable code to write in my mind.

Fortunately, there’s an easier way, which Luke Hoban provided based on an old blog post by Douglas Crockford, http://yuiblog.com/blog/2006/09/26/for-in-intrigue/, in which he points out that for…in includes all the keys in an object’s prototype and not just those in the object itself. To prevent this, you have to use the hasOwnProperty method to check where the property is coming from. So this modification of the code above will produce the expected output:

for (var key in ls.values) {
    if (ls.values.hasOwnProperty(key)) {
        console.log(“values[“ + key + “] = “ + ls.values[key]);
    }
}

Better still, in Windows Store apps we can rely on the more intelligent behavior of EcmaScript 5’s forEach iterator, and just do the following:

Object.keys(ls.values).forEach(function (key) {
    console.log(“values[“ + key + “] = “ + ls.values[key]);
});

This produces the same results with a simpler construct.


Apps need to be prepared for a variety of display sizes. For one, a user can switch view states at any time, putting the app into snapped view, filled view, and fullscreen landscape. The user can also rotate a device to switch to portrait automatically (on devices with appropriate sensors). These are the basics for a tablet device like a Surface.

But also remember that as WIndows 8 runs on many different kinds of devices, there are many other ways that display properties can be changed.

For example, think of everything that can happen through the Display settings in Control Panel. The user can rotate a display directly (as when using a desktop monitor that swivels), which will change a view state to fullscreen portrait as well. The user can change display resolution, which clearly changes the size of fullscreen and filled views, as well as the vertical dimension of a snapped view.

On multi-monitor systems, the user can also change which monitor is assigned to run Windows Store apps, which potentially has the same effect as changing display resolution if those monitors are different.

A user could also plug an external display into a device: monitors, projectors, and so forth. Depending on how the user configures that display–duplicating the main device, extending the display, or switching exclusively to the external display–the screen resolution can change as well as the pixel density. For example, a Surface Pro has a 1920×1080 screen that puts the 140% scaling into effect because it’s only a 10.6″ screen. But plug it into a monitor with the same resolution and the scaling can revert to 100%. (This means that the app will see an effective resolution change from approxmately 1366×768 to 1920×1080.)

The bottom line is that apps really need to watch for the relevant resize event (such as window.resize in JavaScript) and update their layout both for window/screen dimensions and pixel density–and don’t overlook the non-obvious cases when running some tests. It’s good to try all the things described here.

Beyond this, two other software features could be cause for resizing the app: app bars and the soft keyboard. By default, these appear as overlays on the app’s canvas, and with the keyboard Windows will also pan the app up automatically to make room. If you want more sophsiticated behavior, though, you can handle the events when these become visible and update your layout more precisely.


The short of it is, sort of. There are differences between the user-agent strings of the two if you really need to know. There’s was a lively discussion on this subject in the Internet Explorer forum last year where you can learn more: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/7ecb58ca-1869-451b-920e-a27fed69a470. It’s also worth pointing out an old bit of documentation at http://msdn.microsoft.com/en-us/library/hh801221.aspx.

But it really boils down to feature detection, because the two browsers are meant to be interchangable.


When using WinJS page controls to implement pages and navigation in an app, it's important to understand that any and all CSS that is loaded on behalf of those pages is cumulative. Because page controls are just performing DOM replacement within the context of the app's root page, you get the benefit of preserving the global JavaScript context but at the same time get the sometimes-frustrating behavior of preserving all the CSS styles as well.

For example, let's say the app's root page is default.html and its global styles are in css/default.css. It then has several page controls defined in pages/page1 (page1.html. page1.js, page1.css), pages/page2 (page2.html. page2.js, page2.css), and pages/page1 (page3.html. page3.js, page3.css). Let's say that page1 is the 'home' page and is loaded into default.html at startup. This means that the styles in default.css and page1.css have been loaded.

Now the user navigates to page2. This causes page1.html to be dumped from the DOM, but its styles remain in the stylesheet. So when page2 is loaded, page2.css gets added to the overall stylesheet as well. This means that any styles in page2.css that have identical selectors to page1.css will overwrite the latter's. The same thing happens also when the user navigates to page3–the styles in page3.css get loaded and overwrite those that already exist.

The tricky part is what then happens if the user navigates back to page1. Because the apphost's rendering engine has already loaded page1.css into the stylesheet, page1.css won't be loaded again. This means that any styles that were overwritten by other pages' stylesheets will not be reset to those in page1.css–basically you get whichever ones were loaded most recently.

The same thing happens with .js files, by the way, as those are not reloaded if they've been loaded already. The lesson here is to not duplicate variable names between those files.

On that thought, there are two ways to get around the CSS issue. One is to just use a global stylesheet (i.e. default.css) and not do much in the individual page .css files unless you're certain it's local. The second way is to make sure that each page has a top-level div with a page-name class, e.g. <div class="page1">, which allows you to then scope all style rules in page1.css with the page name, e.g.

.page1 p {
    font-weight: bold;
}

This will prevent collision between all the page<n>.css files.

Another place where this can arise is if you try to use the ui-light.css and ui-dark.css WinJS stylesheets in different pages of the same app. Because there are only two files here, whichever one is used first will be overwritten by the second, with the effect that subsequent pages that refer to ui-light.css will still appear with the dark styles.

The solution to this particular problem comes from the fact that where the styles differ, those in ui-light.css are scoped with a CSS class win-ui-light and those in ui-dark.css are scoped with win-ui-dark. This means you can just refer to whichever stylesheet you use most often in your .html files, then add either win-ui-light or win-ui-dark to individual elements that you need to style differently. (Thanks to Scott Salam for this one.)

The other way of avoiding collisions is to specifically unload and reload CSS files by modifying <link> tags in the page header. You can either remove one <link> tag and add a different one, toggle the disabled attribute for a tag between true and false, or change the href attribute of an existing link. These methods are demonstrated for styling an iframe in the CSS styling and branding your app sample, which swaps out and enables/disables both WinJS and app-specific stylesheets. Another demonstration for switching between the WinJS stylesheets is in scenario 1 of the HTML NavBar control sample  (js/1-CreateNavBar.js):

function switchStyle() {
    var linkEl = document.querySelector('link');
    if (linkEl.getAttribute('href') === "//Microsoft.WinJS.2.0 /css/ui-light.css") {
        linkEl.setAttribute('href', "//Microsoft.WinJS.2.0 /css/ui-dark.css");
    } else {
        linkEl.setAttribute('href', "//Microsoft.WinJS.2.0 /css/ui-light.css"); 
    }
}

The downside of this approach is that every switch means reloading and reparsing the CSS files and a corresponding re-rendering of the page. This isn’t much of an issue during page navigation, but given the size of the WinJS files I recommend using it only for your own page-specific stylesheets and using the win-ui-light and win-ui-dark classes to toggle the WinJS styles.


Background tasks, depending on the conditions which trigger them, can run when their associated app is also running. The question then arises: how can the background task communicate with the app?

As noted in yesterday’s post, a background task can write to the app’s appdata areas, which is the way for the background task to pass information to the app. The app, for that matter, can also store information there for a background task to find when it’s next run.

When the background task writes data, the question then becomes how the background task can tell the app that there’s new data available.

There are two ways to do this. First is the completed event that’s part of the BackgroundTaskRegistration class. The app gets an instance of this class back from BackgroundTaskBuilder.register when it sets up a background task, after which it can then assign a handler for completed. This works well, then, for a background task that does some work that the app wants to pick up when the task is completely finished. Because the app knows which background task was associated with that particular handler, it knows where to look for the appropriate appdata.

The Background task sample in the Windows SDK uses completed handlers all over the place to give visual output when a task is complete (and also as it supports progress). In the JavaScript version of the sample, the handler is found at the end of the js/global.js file. The attachProgressAndCompletedHandlers function earlier in that file is where the handlers are assigned, and this function is called from the earlier registerBackgroundTask that call the WinRT APIs.

The second means of communication works at any time during execution of the background task, which is calling Windows.Storage.ApplicationData.signalDataChanged. This will raise a Windows.Storage.ApplicationData.datachanged event in the app (assuming it’s listening), as is also raised when Windows roams new app data from the cloud. The trick here is that the event doesn’t receive any indication of what data, exactly, was changed, so it needs to go examine any data that it expects might have changed.

Clearly, though, if an app only has one or a small number of background tasks that write to local appdata, then there’s not much to go inspect (it’s less likely that a background task would write to roaming appdata, though that’s not out of the question). So it’s workable–it just takes a little more work!

To see this in action, take the aforementioned sample, and navigate to the Tasks project (a C# project) and open SampleBackgroundTask.cs. Within PeriodicTimerCallback, add the following after the line that starts with settings.Values[key] == …:

Windows.Storage.ApplicationData.Current.SignalDataChanged();

The in the main project of the sample (again using the JavaScript variant), open js/sample-background-task-with-condition.js and add the following at the end of the ready method near the top (after the line that reads SampleBackgroundTaskWithCondition.updateUI();)

Windows.Storage.ApplicationData.current.ondatachanged = function (appdata) {
    console.log(“Appdata changed.”);
}

Set a breakpoint on console.log, then run the app and go to scenario 3. Click the Register button which will execute the ondatachanged assignment above. Then pull down the Suspend menu where you can trigger the SampleBackgroundTaskWithCondition:

background task selection

After the task does it’s work (you’ll see progress reported), it will call SignalDataChanged which should hit your breakpoint.