A while back one of my associates asked for an “ideal spec” for a Windows 8 developer on behalf of a partner who was looking to hire such a person. I won’t presume to have the ‘ideal,’ but here is a list that you might find helpful in your own recruiting efforts:

It would be best, of course, to find a developer with experience in one or more of the language/presentation layer choices for building apps: HTML/CSS/JS, C#(VB)/XAML, C++/XAML, and C++/DirectX. Experience in more than one is a big plus because of the platform’s support for writing mixed-language apps via WinRT components. And of these, DirectX experience is more specific to doing graphics apps vs. those with layout and data.

Other attractive qualifications:

  • Understands how to work with web services and web-based databases.
  • Strong testing skills and understanding of testing methodology. This will make a huge difference in delivering a top-quality app; those apps produced by developers who’ve never had to test much at all (e.g. many web-only developers) tend to have more bugs and fail Store certification more often.
  • Experience with Visual Studio a plus, as this reduces learning curve and helps productivity, though the tools can be learned, of course.
  • Experience in measuring and improving performance a plus, as again this will help produce a top-quality app, especially with web services.
  • Ability to learn and understand a platform, not just an app’s internals, which helps in understanding how to integrate all the platform features of Windows 8 into an app
  • Understands caching strategies for producing a mobile app that can operate with or without connectivity.
  • Respects the role of designers and enjoys working with them and maintaining a strong relationship–this will happen!
  • Experience with Windows Azure, Azure Mobile Services, and/or Windows Notification Service (WNS) a plus, especially for working with live tiles and notifications.
  • Familiarity with authentication, e.g. OAuth.
  • Mobile dev experience in general is a good thing.

Another place we’ve seen many apps fail Store submission is with 4.1.1 of the Windows Store Certification Requirements (v4.0). It’s title is “Your app must have a privacy statement if it is network-capable.” It basically says that if you declare any network-related capabilities in your app manifest, you need to have a privacy policy available from two places specific places.

To the point of being network-capable, the requirement states, “If your app has the technical ability to transmit any user’s personal information, you must maintain a privacy policy.” While you could interpret this statement to suggest that an app that doesn’t collect any kind of personal information at all, e.g. just downloads posts from a public blog, doesn’t need a privacy policy, it’s best to err on the side of a more general meaning. The phrase “if your app has the technical ability” means that whether or not you collect any personal information, declaring those capabilities in the manifest means that you do, in fact, have the ability. So you want to have a privacy policy.

The requirement then states where that policy must be accessible: “You must provide access to your privacy policy in the Description page of your app, as well as in the app’s settings as displayed in the Windows Settings charm.”

The short of this means that you need to have a web page somewhere with the privacy policy, preferably in every language that you support in your app, though this is not explicitly spelled out (after all, page translators can be used on your page). That page is what you link to in your app’s description. [Addendum: This is required because it allows users to check the privacy policy before installing the app, rather than after the fact.]

In your Settings pane, then, you can make the privacy policy accessible in one of two ways. First, you can just create a link to that same web page, which opens the browser to display it. No problem there. Second, you can create a flyout panel that contains the text directly, often by using an iframe that loads its contents from your web page. I use this latter approach in the Here My Am! app in Chapter 17 of Programming Windows 8 Apps in HTML, CSS, and JavaScript, where I do have localized versions of the policy on my web site and include those within an iframe (as shown below in German).

The bottom line: set up privacy policy pages in your supported languages on a web site, and be sure to link to that page in your app Description and through your Settings, and don’t risk failing certification for such a basic matter.


This is something we saw with a number of early partners. In the app manifest, in the Application UI section of Visual Studio’s editor, there’s an option called Show name with a variety of options:

By default, this is set to “All logos” meaning that the value in the “Display name” field (also on the Application UI section), or the value in the “Short name” field, if given,  will appear on the lower left of a tile as shown here:

As you can see here, the display name/short name text is redundant with the app name that’s already on the tile. To remove it, select one of the other options in the Show name drop-down.

It’s a good thing to double-check before submitting an app to the Store. Having a name show on a tile when the graphic shows a name too won’t cause the app to fail certification, but it does look a little silly.

When you support live tiles, there are situations where you do want the name or a badge logo to appear on the tile, even though you don’t show the name for the default tile. For these purposes, use the branding attribute in the tile update XML. See Chapter 13 of Programming Windows 8 Apps with HTML, CSS, and JavaScript, in the “Branding” section (page 585) for details.

 

 


With requirement 6.2 of the Windows Store Certification Requirements (v4.0), all apps must have an age rating. Be sure to follow the guidelines because they are taking very serious from everything I've seen, and many apps fail on this simple basis.

One of the key bits to pay attention to is the following statement:

If your app provides a user with uncontrolled: (i) access to online social networks, or (ii) sharing of personal information with third parties, including other gamers or online acquaintances, then you must assign it a Windows Store rating of at least 12+.  For such activity to be considered "controlled", your app must include parental control features that require parental permission to use such sharing features, and you must identify those and explain their functionality in the Notes to testers.

To make this story short, if your app uses the Internet, carefully evaluate your usage to understand whether you need the 12+ rating or not. Also see Giving Your App an Age Rating.

You also want to make sure that any terms of service you link to from your app indicates ages that are compatible with your chosen age rating with the Store. One partner I worked with a while back failed for this reason: their terms of service said something about a person needing to be 14 years or older to agree, but the app was rated for an age lower than that. This meant that a young user could acquire the app from the Store but wasn't technically allowed to use it due to the terms of service.

It's good to note that earlier versions of the Store certification requirements specifically called out manifest capabilities like geolocation and webcam as requiring a 12+ age rating in and of themselves. This has been refined to allow apps with a 3+ rating, for example, to use the webcam, so long as it does not allow uncontrolled sharing of pictures. So a 3+ app can take pictures from the webcam and let a preschooler doctor themselves up, no problem, but sharing the results via a social network would require parental consent in the app.


Thanks to M. Dirksma on the Building Windows Store Apps with HTML5/JS Forum for this one. It applies to the first edition of Programming Windows 8 Apps in HTML, CSS, and JavaScript.

When running versions of Here My Am! that use an iframe element to host the Bing Maps web control (Chapters 2-7; in Chapter 8 this is replaced with the Bing Maps SDK control), there is a possibility that the iframe isn’t instantiated before the app attempts to set the geolocation. This can throw an exception.

The solution to this–a good practice for any situation where you might depend on iframe content being loaded, is to place that dependent code inside a handler for the iframe’s load event. M. Dirksma’s solution is as follows:

document.getElementById("map").addEventListener("load", function () {
    var gl = new Windows.Devices.Geolocation.Geolocator();
    gl.getGeopositionAsync().done(function (position) {
        lastPosition = { latitude: position.coordinate.latitude,
            longitude: position.coordinate.longitude };
        callFrameScript(document.frames["map"], "pinLocation",
            [position.coordinate.latitude, position.coordinate.longitude]);
    }, function (error) { console.log("Unable to get location."); })
    ;
}, false);

This should prevent the error and avoid any odd timing issues.


A couple of links in my first edition book (out of 1400+) managed to get past my process for checking and validating them. Pages numbers are in the PDF:

For checking links, I found a very helpful add-in for Microsoft Word (2010…now waiting for one that works with Office 2013!) from ablebits.com. See http://www.ablebits.com/word-links-manager/index.php for details. The product as a 15-day free trial, and a license costs $9.95. This was well worth it for how much time it saved me in the last weeks of production!


In various pieces of sample code, within the SDK samples as well as those in my book, you’ll often see the following syntax that appears somewhat cryptic (as does much of JavaScript!) to the uninitiated:

this.<some_function>.bind(this));

For example, when wiring up app bar buttons in the book’s Here My Am! examples, you’ll see this code:

var appbar = document.getElementById(“appbar”).winControl;
appbar.getCommandById(“cmdRefreshLocation”).addEventListener(“click”, this.tryRefresh.bind(this));
appbar.getCommandById(“cmdPickFile”).addEventListener(“click”, this.pickFile.bind(this));
appbar.getCommandById(“cmdRecentPictures”).addEventListener(“click”, this.recentPictures.bind(this));

The use of .bind also appears in other contexts, again from Here My Am!:

var image = document.getElementById(“photo”);
image.addEventListener(“click”, capturePhoto.bind(image));

So what’s happening here? Let’s take a step back and talk about the this keyword more generally.

this is an intrinsic variable that typically refers to the current object context on which a method is called. For example, if I have an object named obj1 and I call its obj1.doSomething method, then this inside doSomething will refer to obj1.

If I just have a global function, on the other hand, this in that context will typically be the same as window (the global context).

Event handlers present a particular difficultly with getting the this context set correctly. If you’ve defined an event handler as a member of some object, say obj1.eventHandler, and pass that function to something like addEventListener or assign it to someOtherObject.onEvent, the element/object raising that event doesn’t have your obj1 object through which to call the handler. That is, when JavaScript resolves an identifier like obj1.eventHandler, the result is just a standalone function object which has no context of where it came from.

As a result, if you do something like document.getElementById(“myButton”, obj1.eventHandler) then the function will be called, all right, but the this object within that handler will contain the global context (window) and not obj1.

The bind method solves this problem. By calling it you say, “here’s the object context through which I want this method called,” which is to say, “make this refer to a particular object when you call the method.” So if you document.getElementById(“myButton”, obj1.eventHandler.bind(obj1)) then the this object within eventHandler will, in fact, be set to obj1.

When you see the this.<event>.bind(this) syntax then, you’re just seeing an object wire one of its own methods up as an event handler and making sure that this will remain the same in the event handler.

So in the Here My Am! examples above, the event handler for the app bar buttons exist as part of the page control where this code appears. The this variable thus points to that page control object, so when the events are triggered, the handlers like tryRefresh, defined in that same page control, will have their this values set to the page control as we want.

In the second example, capturePhoto.bind(image), what we’re doing instead is making sure that the specific image element that was tapped shows up as the this object within the capturePhoto function. There are other ways to do this (getting the originating element for the event, for example), but using .bind here works nicely.


As described in Chapter 16 of Programming Windows 8 Apps in HTML, CSS, and JavaScript, Visual Studio can only debug one type of code at a time. Here’s the relevant excerpt:

When you hit that [JavaScript] breakpoint, step through the code using Visual Studio’s Step Into feature (F11 or Debug > Step Into). Notice that you do not step into the C# code, an effect of the fact that Visual Studio can debug either script or managed (C#)/native (C++) code in one debugging session but unfortunately not both. Clearly, using some console output will be your friend with such a limitation.

To set the debug mode, right-click your app project in solution explorer, select Debugging on the left, and then choose a Debugger Type on the right as shown in Figure 16-3. For debugging C#, select Managed Only or Mixed (Managed and Native). Then set breakpoints in your component code and restart the app (you have to restart for this change to take effect). When you trigger calls to the component from JavaScript, you’ll hit those component breakpoints.

Fortunately, there is a way to debug both types of code at the same time using two instances of Visual Studio:

  1. Launch the app (F5) with Script Only debugging selected. This is the instance of Visual Studio in which you’ll be stepping through JavaScript.
  2. Load the project in a second instance of Visual Studio. Ignore warnings about IntelliSense files being already open, but prepare to wait a little while as VS will build a new copy of that database for this second instance.
  3. In this second instance, set the debugging mode to Native Only, Managed Only, or Mixed, depending on your needs. This is where you’ll be debugging C#/VB/C++ code, as in a WinRT component.
  4. Select the Debug -> Attach to Process… menu command. (You do this instead of running the app a second time.)
  5. Find and select the line for WWAHost.exe in the process list that has your app name in the title column.
  6. Above the list, check the Attach to value. If it says “Automatic: Script code”, press the Select… button and indicate Managed and Native instead. Close that dialog.
  7. Click the Attach button.

Then go set breakpoints in this second instance of VS where you want to step through managed/native code. While this still won’t allow you to step across the language boundaries in a single debugger, it will allow you to step through each code type in the different instances.

Thanks for Rob Paveza for this tip.