The Life Story of a Windows Store App: Characteristics of the Windows Platform - Microsoft Press Programming Windows Store Apps with HTML, CSS and JavaScript (2014)

Microsoft Press Programming Windows Store Apps with HTML, CSS and JavaScript (2014)

Chapter 1 The Life Story of a Windows Store App: Characteristics of the Windows Platform

Paper or plastic? Fish or cut bait? To be or not to be? Standards-based or native? These are the questions of our time….

Well, OK, maybe most of these aren’t the grist for university-level philosophy courses, but certainly the last one has been increasingly important for app developers. Standards-based apps are great because they run on multiple platforms; your knowledge and experience with standards like HTML5 and CSS3 are likewise portable. Unfortunately, because standards generally take a long time to produce, they always lag behind the capabilities of the platforms themselves. After all, competing platform vendors will, by definition, always be trying to differentiate! For example, while HTML5 has a standard for geolocation/GPS sensors and has started on working drafts for other forms of sensor input (like accelerometers, compasses, near-field proximity, and so on), native platforms already make these available. And by the time HTML’s standards are in place and widely supported, the native platforms will certainly have added another set of new capabilities.

As a result, developers wanting to build apps around cutting-edge features—to differentiate from their own competitors!—must adopt the programming language and presentation technology imposed by each native platform or take a dependency on a third-party framework that tries to bridge the differences.

Bottom line: it’s a hard choice.

Fortunately, Windows 8 and Windows 8.1 provide what I personally think is a brilliant solution for apps. Early on, the Windows team set out to solve the problem of making native capabilities—the system API, in other words—directly available to any number of programming languages, including JavaScript. This is what’s known as the Windows Runtime API, or just WinRTfor short (an API that’s making its way onto the Windows Phone platform as well).

WinRT APIs are implemented according to a certain low-level structure and then “projected” into different languages—namely C++, C#, Visual Basic, and JavaScript—in a way that looks and feels natural to developers familiar with those languages. This includes how objects are created, configured, and managed; how events, errors, and exceptions are handled; how asynchronous operations work (to keep the user experience fast and fluid); and even the casing of method, property, and event names.

The Windows team also made it possible to write native apps that employ a variety of presentation technologies, including DirectX, XAML, and, in the case of apps written in JavaScript, HTML5 and CSS3.

This means that Windows gives you—a developer already versed in HTML, CSS, and JavaScript standards—the ability to use what you know to write fully native Windows Store apps using the WinRT APIand still utilize web content!And I do mean fully native apps that both offer great content in themselves and integrate deeply with the surrounding system and other apps (unlike “hybrids” where one simply hosts web content within a thin, nearly featureless native shell). These apps will, of course, be specific to the Windows platform, but the fact that you don’t have to learn a completely new programming paradigm is worthy of taking a week off to celebrate—especially because you won’t have to spend that week (or more) learning a complete new programming paradigm!

It also means that you’ll be able to leverage existing investments in JavaScript libraries and CSS template repositories: writing a native app doesn’t force you to switch frameworks or engage in expensive porting work. That said, it is also possible to use multiple languages to write an app, leveraging the dynamic nature of JavaScript for app logic while leveraging languages like C# and C++ for more computationally intensive tasks. (See “Sidebar: Mixed Language Apps” later in this chapter, and if you’re curious about language choice for apps more generally, see My take on HTML/JS vs. C/XAML vs. C++/DirectX on my blog.)

A third benefit is that as new web standards develop and provide APIs for features of the native platform, the fact that your app is written in the same language as the web will make it easier to port features from your native app to cross-platform web applications, if so desired.

Throughout this book we’ll explore how to leverage what you know of standards-based web technologies—HTML, CSS, and JavaScript—to build great Windows Store apps for Windows 8.1. In the next chapter we’ll focus on the basics of a working app and the tools used to build it. Then we’ll look at fundamentals like the fuller anatomy of an app, incorporating web content, using controls and collections, layout, commanding, state management, and input (including sensors), followed by chapters on media, animations, contracts through which apps work together, live tiles and toast notifications, accessing peripheral devices, WinRT components (through which you can use other programming languages and the additional APIs they can access), expanding your reach through localization and accessibility, and working with the Windows Store. There is much to learn—it’s a rich platform!

For starters, let’s talk about the environment in which apps run and the characteristics of the platform on which they are built—especially the terminology that we’ll depend on in the rest of the book (highlighted in italics). We’ll do this by following an app’s journey from the point when it first leaves your hands, through its various experiences with your customers, to where it comes back home for renewal and rebirth (that is, updates). For in many ways your app is like a child: you nurture it through all its formative stages, doing everything you can to prepare it for life in the great wide world. So it helps to understand the nature of that world!

Terminology note What we refer to as Windows Store apps, or sometimes just Store apps, are those that are acquired from the Windows Store and for which all the platform characteristics in this chapter (and book) apply. These are distinctly different from traditional desktop applications that are acquired through regular retail channels and installed through their own setup programs. Unless noted, then, an “app” in this book refers to a Windows Store app.

What about Windows Phone? The answer is yes! Windows Phone 8.1 supports writing apps with HTML, CSS, and JavaScript using much of what we’ll be learning about in this book for Windows Store apps. However, this capability on Windows Phone happened very late in the production of this book, so I’m able to provide only a few details. I’ve included a brief overview later in this chapter under “Sidebar: Writing Windows Phone Apps with HTML, CSS, and JavaScript,” with pointers to where you’ll be able to find more information.

Leaving Home: Onboarding to the Windows Store

For Windows Store apps, there’s really one port of entry into the world: customers always acquire, install, and update apps through the Windows Store. Developers and enterprise users can side-load apps, but for the vast majority of the people you care about, they go to the Windows Store and nowhere else.

This obviously means that an app—the culmination of your development work—has to get into the Store in the first place. This happens when you take your pride and joy, package it up, and upload it to the Store by using the Store/Upload App Packages command in Visual Studio. To do this, you’ll need to create a developer account with the Store by using the Store > Open Developer Account command in Visual Studio Express (and this account works for both Windows and Windows Phone). Visual Studio Express and Expression Blend, which we’ll also be using, are free tools you can obtain from This also works in Visual Studio Ultimate, the fuller, paid version of Microsoft’s development environment.

The package itself is an appx file (.appx)—see Figure 1-1—that contains your app’s code, resources, libraries, and a manifest, up to a combined limit of 8GB. The manifest describes the app (names, logos, etc.), the capabilities it wants to access (such as media libraries or specific devices like cameras), and everything else that’s needed to make the app work (such as file associations, declaration of background tasks, and so on). Trust me, we’ll become great friends with the manifest!


FIGURE 1-1 An appx package is simply a zip file that contains the app’s files and assets, the app manifest, a signature, and asort of table-of-contents called the blockmap.When uploading an app, the initial signature is provided by Visual Studio; the Windows Store will re-sign the app once it’s certified.

Blockmaps make updates easy The blockmap is hugely important for the customer experience of app updates (which are automatically installed by default in Windows 8.1) and, as a consequence, for your confidence in issuing updates. It describes how the app’s files are broken up into 64K blocks. In addition to providing certain performance optimizations and security functions (like detecting whether a package has been tampered with), the blockmap describes exactly what parts of an app have been updated between versions so that the Windows Store need downloadonly those specific blocks rather than the whole app anew. This greatly reduces the time and overhead that a user experiences when acquiring and installing updates. That is, even if your whole app package is 300MB, an update that affects a total of four blocks would mean your customers are downloading only 256 kilobytes.

The upload process will walk you through setting your app’s name (which you do ahead of time using the Store > Reserve App Name and Store > Associate App with the Store commands in Visual Studio), choosing selling details (including price tier, in-app purchases, and trial periods), providing a description and graphics, and also providing notes to manual testers. After that, your app goes through a series of job interviews, if you will: background checks (malware scans and GeoTrust certification)and manual testing by a human being who will read the notes you provide (so be courteous and kind!). Along the way you can check your app’s progress through the Windows Store Dashboard.1

The overarching goal with these job interviews (or maybe it’s more like getting through airport security!) is to help users feel confident and secure in trying new apps, a level of confidence that isn’t generally found with apps acquired from the open web. Because all apps in the Store are certified, signed, and subject to ratings and reviews, customers can trust all apps from the Store as they would trust those recommended by a reliable friend. Truly, this is wonderful news for most developers, especially those just getting started—it gives you the same access to the worldwide Windows market that has been previously enjoyed only by those companies with an established brand or reputation.

It’s worth noting that because you set up pricing, trial versions, and in-app purchases during the on-boarding process, you’ll have already thought about your app’s relationship to the Store quite a bit! After all, the Store is where you’ll be doing business with your app, whether you’re in business for fame, fortune, fun, or philanthropy.

Indeed, this relationship spans the entire lifecycle of an app—from planning and development to distribution, support, and servicing. This is, in fact, why I’ve started this life story of an app with the Windows Store, because you really want to understand that whole lifecycle from the very beginning of planning and design. If, for example, you’re looking to turn a profit from a paid app or in-app purchases, perhaps also offering a time-limited or feature-limited trial, you’ll want to engineer your app accordingly. If you want to have a free, ad-supported app, or want to use a third-party commerce solution for in-app purchases (bypassing revenue sharing with the Store), these choices also affect your design from the get-go. And even if you’re just going to give the app away to promote a cause or to just share your joy, understanding the relationship between the Store and your app is still important. For all these reasons, you might want to skip ahead and read the “Your App, Your Business” section of Chapter 20, "Apps for Everyone, Part 2," before you start writing your app in earnest. Also, take a look at the Certify your app topic on the Windows Developer Center.

Anyway, if your app hits any bumps along the road to certification, you’ll get a report back with all the details, such as any violations of the App certification requirements for the Windows Store (part of the Windows Store agreements section). Otherwise, congratulations—your app is ready for customers!

Sidebar: The Store API and Product Simulator

At runtime, apps use the Windows.ApplicationModel.Store.CurrentAppclass in WinRT to retrieve their product information from the Store (including in-app purchase listings), check license status, and prompt the user to make purchases (such as upgrading a trial or making an in-app purchase).

This begs a question: how can an app test such features before it’s even in the Store? The answer is that during development, you use these APIs through the CurrentAppSimulator class instead. This is entirely identical to CurrentApp(and in the same namespace) except that it works against local data in an XML file rather than live Store data in the cloud. This allows you to simulate the various conditions that your app might encounter so that you can exercise all your code paths appropriately. Just before packaging your app and sending it to the Store, just changeCurrentAppSimulator to CurrentApp and you’re good to go. (If you forget, the simulator will simply fail on a non-developer machine, like those used by the Store testers, meaning that you’ll fail certification.)

Discovery, Acquisition, and Installation

Now that your app is out in the world, its next job is to make itself known and attractive to potential customers. What’s vital to understand here is what the Windows Store does and does not do for you. Its primary purpose is to provide a secure and trustworthy marketplace for distributing apps, updating apps, transparently handling financial transactions across global markets, and collecting customer reviews and basic telemetry (crash dumps)—which taken together is a fabulous service! That said, the mere act of onboarding an app to the Windows Store does not guarantee anyone will find it. That’s one reality of publishing software that certainly hasn’t changed. You still need to write great apps and you still need to market them to your potential customers, using advertising, social media, and everything else you’d do when trying to get a business off the ground.

That said, even when your app is found in the Store it needs to present itself well to its suitors. Each app in the Store has a product description page where people see your app description, promotional graphics, ratings and reviews, and the capabilities your app has declared in its manifest, as shown in Figure 1-2. That last bit means you want to be judicious in declaring your capabilities. A music player app, for instance, will obviously declare its intent to access the user’s music library but usually doesn’t need to declare access to the pictures library unless it has a good justification. Similarly, a communications app would generally ask for access to the camera and microphone, but a news reader app probably wouldn’t. On the other hand, an ebook reader might declare access to the microphone if it had a feature to attach audio notes to specific bookmarks.


FIGURE 1-2 A typical app page in the Windows Store; by tapping the Permissions link at the upper left, the page pans to the Details section, which lists all the capabilities that are declared in the manifest (overlay). You can see here that Skype declares five different capabilities, all of which are appropriate for the app’s functionality.

The point here is that what you declare must make sense to the user, and if there are any doubts you should clearly indicate the features related to those declarations in your app’s description. Otherwise the user might really wonder just what your news reader app is going to do with the microphone and might opt for another app that seems less intrusive.2

The user will also see your app pricing, of course, and whether you offer a trial period. Whatever the case, if they choose to install the app (getting it for free, paying for it, or accepting a trial), your app now becomes fully incarnate on a real user’s device. The appx package is downloaded to the device and installed automatically along with any dependencies, such as the Windows Library for JavaScript(see “Sidebar: What is the Windows Library for JavaScript?”). As shown in Figure 1-3, the Windows deployment manager creates a folder for the app, extracts the package contents to that location, creates appdata folders (local, roaming, and temp, which the app can freely access, along with settings files for key-value pairs), and does any necessary fiddling with the registry to install the app’s tile on the Start screen, create file associations, install libraries, and do all those other things that are again described in the manifest. It can also start live tile updates before your app is even run the first time if you provide an appropriate URI in your manifest. There are no user prompts during this process—especially not those annoying dialogs about reading a licensing agreement!


FIGURE 1-3 The installation process for Windows Store apps; the exact sequence is unimportant. Any roaming state that exists in the cloud from the app on other devices is automatically downloaded as part of installation.

In fact, licensing terms are integrated into the Store; acquisition of an app implies acceptance of those terms. (However, it is perfectly allowable for apps to show their own license acceptance page on startup, as well as require an initial login to a service if applicable.) But here’s an interesting point: do you remember the real purpose of all those lengthy, annoyingly all-caps licensing agreements that we pretend to read? Almost all of them basically say that you can install the software on only one machine. Well, that changes with Windows Store apps: instead of being licensed to a machine, they are licensed to the user, giving that user the right to install the app on up to eighty-one different devices.

In this way Store apps are a much more personal thing than desktop apps have traditionally been. They are less general-purpose tools that multiple users share and more like music tracks or other media that really personalize the overall Windows experience. So it makes sense that users can replicate their customized experiences across multiple devices, something that Windows supports through automatic roaming of app data and settings between those devices. (More on that later.)

In any case, the end result of all this is that the app and its necessary structures are wholly ready to awaken on a device as soon as the user taps a tile on the Start screen or launches it through features like Search and Share. And because the system knows about everything that happened during installation, it can also completely reverse the process for a 100% clean uninstall—completely blowing away the appdata folders, for example, and cleaning up anything and everything that was put in the registry. This keeps the rest of the system entirely clean over time, even though the user may be installing and uninstalling hundreds or thousands of apps. This is like the difference between having guests in your house and guests in a hotel. In your house, guests might eat your food, rearrange the furniture, break a vase or two, feed leftovers to the pets, stash odds and ends in the backs of drawers, and otherwise leave any number of irreversible changes in their wake (and you know desktop apps that do this, I’m sure!). In a hotel, on the other hand, guests have access only to a very small part of the whole structure, and even if they trash their room, the hotel can clean it out and reset everything as if the guest was never there.

Sidebar: What Is the Windows Library for JavaScript?

The HTML, CSS, and JavaScript code in a Windows Store app is only parsed, compiled, and rendered at runtime. (See the “Playing in Your Own Room: The App Container” section below.) As a result, a number of system-level features for apps written in JavaScript, like controls, resource management, and default styling are supplied through the Windows Library for JavaScript, or WinJS, rather than through the Windows Runtime API. This way, JavaScript developers see a natural integration of those features into the environment they already understand, rather than being forced to use different kinds of constructs.

WinJS, for example, provides HTML implementations of a number of controls, meaning that instances of those controls appear as part of the DOM and can be styled with CSS like other intrinsic HTML elements. This is much more natural for developers than having to create an instance of some WinRT class, bind it to a separate HTML element, and style it through code or some other proprietary markup scheme. Similarly, WinJS provides an animations library built on CSS that embodies the Windows user experience so that apps don’t have to figure out how to re-create that experience themselves.

Generally speaking, WinJS is a toolkit that contains a number of independent capabilities that can be used together or separately. WinJS thus also provides helpers for common JavaScript coding patterns, simplifying the definition of namespaces and object classes, handling of asynchronous operations (that are all over WinRT) through promises, and providing structural models for apps, data binding, and page navigation. At the same time, it doesn’t attempt to wrap WinRT unless there is a compelling scenario where WinJS can provide real value. After all, the mechanism through which WinRT is projected into JavaScript already translates WinRT structures into forms that are familiar to JavaScript developers.

Truth be told, you can write a Windows Store app in JavaScript without WinJS or just pick and choose what parts of the library are to your liking! But I think you’ll find that it saves you all kinds of tedious work. In addition, WinJS is shared between every Store app written in JavaScript, and it's automatically downloaded and updated as needed when dependent apps are installed. We’ll see nearly all of its features throughout this book, and you can always explore what’s available through the Windows API reference (just scroll down to where you see WinJS and its subsidiary namespaces in the left-hand table of contents).

Sidebar: Third-Party Libraries

Apps can freely use third-party libraries by bundling them into their own app package, provided of course that the libraries use only the APIs available to Windows Store apps and follow necessary security practices that protect against script injection and other attacks. Many apps use jQuery 2.0 (see jQuery and WinJS working together in Windows Store apps); others use Angular.js, Box2D, Prototype, and so forth.Apps can also use third-party binaries, such as WinRT components, by bundling them with their app package. See this chapter’s"Sidebar: Mixed Language Apps."

For an index of the ever-growing number of third-party solutions that are available for Windows Store apps, visit the Windows Partner Directory at

Of course, bundling libraries and frameworks into your app package will certainly make that package larger, raising natural concerns about longer download times for apps and increased disk footprint. This has prompted requests for the ability to create shared framework packages in the Store (which Microsoft supports only for a few of its own libraries like WinJS). However, the Windows team devised a different approach. When you upload an app package to the Store, you will still bundle all your dependencies. On the consumer side, however, the Windows Store automatically detects when multiple apps share identical files. It then downloads and maintains a single copy of those files, making subsequent app installations faster and reducing overall disk footprint.

This way the user sees all the benefits of shared frameworks in a way that’s almost entirely transparent to developers. The one requirement is that you should avoid, if possible, recompiling or otherwise modifying third-party libraries, especially larger ones like game engines, because you’ll then produce different variations that must be managed separately.

Playing in Your Own Room: The App Container

Now, just as the needs of each day may be different when we wake up from our night’s rest, Store apps can wake up—be activated—for any number of reasons. The user can, of course, tap or click the app’s tile on the Start screen. An app can also be launched in response to charms like Search and Share, through file or protocol associations, and a number of other mechanisms. We’ll explore these variants as we progress through this book. But whatever the case, there’s a little more to this part of the story for apps written in JavaScript.

In the app’s package folder are the same kind of source files that you see on the web: .html files, .css files, .js files, and so forth. These are not directly executable like .exe files for apps written in C#, Visual Basic, or C++, so something has to take those source files and produce a running app with them. When your app is activated, then, what actually gets launched is that something: a special app host process called wwahost.exe3, as shown in Figure 1-4.


FIGURE 1-4 The app host is an executable (wwahost.exe) that loads, renders, and executes HTML, CSS, and JavaScript, in much the same way that a browser runs a web application.

The app host is more or less Internet Explorer without the browser chrome—more in that your app runs on top of the same HTML/CSS/JavaScript engines as Internet Explorer, less in that a number of things behave differently in the two environments. For example:

• A number of methods in the DOM API are either modified or not available, depending on their design and system impact. For example, functions that display modal UI and block the UI thread are not available, like window.alert,, and window.prompt.(Try Windows.UI.-Popups.MessageDialog instead for some of these needs.)

• The MSApp object, which represents the app host’s capabilities, provides many of the same methods like requestAnimationFrame as it does within Internet Explorer, and it also provides additional features for Store apps.

• The engines support additional methods and propertieson a variety of elements—such as audio, video, and canvas—that are specific to being an app as opposed to a website.

• The default page of an app written in JavaScript runs in what’s called the local context wherein JavaScript code has access to WinRT, can make cross-domain HTTP requests, and can access remote media (videos, images, etc.). However, you cannot load remote script (from http[s]sources, for example), and script is automatically filtered out of anything that might affect the DOM and open the app to injection attacks (e.g.,document.write and innerHTML properties).

• Other pages in the app, as well as webview and iframe elements within a local context page, can run in the web context wherein you get web-like behavior (such as remote script) but don’t get WinRT access nor cross-domain HTTP requests (though you can still use much of WinJS). Web context elements are generally used to host web content on a locally packaged page (like a map control, as we’ll see in Chapter 2, "Quickstart"), or to load pages that are directly hosted on the web, while not allowing web pages to drive the app (a violation of Store policy).

For full details on all these behaviors, see HTML and DOM API changes list and HTML, CSS, and JavaScript features and differences on the Windows Developer Center, As with the app manifest, you should become good friends with the Developer Center.

All Store apps, whether hosted or not, run inside an environment called the app container. This is an insulation layer, if you will, that generally blocks local interprocess communication and either blocks or brokers access to system resources. The key characteristics of the app container are described as follows and illustrated in Figure 1-5:

• All Store apps run within a dedicated environment that cannot interfere with or be interfered by other apps, nor can apps interfere with the system.

• Store apps, by default, get unrestricted read/write access only to their specific appdata folders on the hard drive (local, roaming, and temp).Access to everything else in the file system (including removable storage) has to go through a broker. This gatekeeper provides access only if the app has declared the necessary capabilities in its manifest and/or the user has specifically allowed it. We’ll see the specific list of capabilities shortly.

• Access to sensitive devices (like the camera, microphone, and GPS) and certain classes of peripherals is similarly controlled—the WinRT APIs that work with those devices will fail if the broker blocks those calls because the app hasn’t declared the appropriate capability in its manifest or the user has denied permission at run time. And access to critical system resources, such as the registry, simply isn’t allowed at all.

• Store apps cannot programmatically launch other apps by name or file path but can do so through file or URI scheme associations. Because these associations are ultimately under the user’s control, there’s no guarantee that such an operation will start a specific app. However, we do encourage app developers to use app-specific URI schemes that will effectively identify your specific app as a target. Technically speaking, another app could come along and register the same URI scheme (thereby giving the user a choice), but this is unlikely with a URI scheme that’s closely related to the app’s identity.

• Store apps are isolated from one another to protect from various forms of attack. This also means that some legitimate uses (like a snipping tool to copy a region of the screen to the clipboard) cannot be written as a Windows Store app; they must be a desktop application.

• Direct interprocess communication is blocked between Store apps, between Store apps and desktop applications, and between Store apps and local services. (Exceptions are made for side-loaded apps in enterprise environments, and in some debugging conditions.) Apps can still communicate through the cloud (web services, sockets, etc.), and many common tasks that require cooperation between apps—such as Search and Share—are handled through contracts in which those apps need not know any details about each other.


FIGURE 1-5 Process isolation for Windows Store apps.

Sidebar: Mixed LanguageApps

Windows Store apps written in JavaScript can access only WinRT APIs directly. Apps or libraries written in C#, Visual Basic, and C++ also have access to a subset of Win32 and .NET APIs, as documented on Win32 and COM for Windows Store apps. Unfair? Not entirely, because you can write a WinRT component in those other languages that make functionality built with those other APIs available in the JavaScript environment (through the same projection mechanism that WinRT itself uses). Becausethese components are written in compiled languages, they can execute faster than the equivalent code written in JavaScript and also offer some degree of intellectual property protection (e.g., hiding algorithms either through obfuscation or by using a fully compiled language like C++).

Such mixed language apps thus use HTML/CSS for their presentation layer and JavaScript for some app logic while placing the most performance critical or sensitive code in compiled components. The dynamic nature of JavaScript, in fact, makes it a great language for gluing together multiple components. We’ll see more in Chapter 18, "WinRT Components."

Note that when your main app is written in JavaScript, we recommend using only WinRT components written in C++ to avoid having two managed environments loaded into the same process. Using WinRT components written in C# or Visual Basic does work but incurs added memory overhead and risks memory leaks across multiple garbage collectors.

Sidebar: Assigned Access (Kiosk Mode)

In a variety of scenarios, such as a public kiosk, it’s desirable to allow only a single app to run on a device and to prevent users from accessing most system capabilities like the Start screen. This feature, called assigned access, is configured through PC Settings > Accounts > Other Accounts > Set Up An Account For Assigned Access, where you associate a specific account with the one app that’s allowed for that account. This can also be done through PowerShell scripts. For more information, see Assigned access: FAQ and Assigned Access Cmdlets.

Different Views of Life: Views and Resolution Scaling

So, the user has tapped on an app tile, the app host has been loaded into memory, and it’s ready to get everything up and running. What does the user see?

The first thing that becomes immediately visible is the app’s splash screen, which is described in its manifest with an image and background color. This system-supplied screen guarantees that at least something shows up for the app when it’s activated, even if the app completely gags on its first line of code or never gets there at all. In fact, the app has 15 seconds to get its act together and display its main window, or Windows automatically gives it the boot (terminates it, that is) if the user switches away. This avoids having apps that hang during startup and just sit there like a zombie, where often the user can only kill it off by using that most consumer-friendly tool, Task Manager. (Yes, I’m being sarcastic—Task Manager is today much more user-friendly than it used to be.) Of course, we highly recommend that you get your app to an interactive state as quickly as possible; we’ll look at some strategies for this in Chapter 3, “App Anatomy and Performance Fundamentals.” That said, some apps will need more time to load, in which case you can create an extended splash screen by making the initial view of your main window look the same as the splash screen. This satisfies the 15-second time limit and lets you display other UI while the app is getting ready. Details are in Appendix B, “WinJS Extras.”

Now, when a normally launched app comes up, it might share space with other apps, but often it has full command of the entire screen—well, not entirely. Windows reserves a one pixel space along every edge of the display through which it detects edge gestures, but the user doesn’t see that detail. Your app still gets to draw in those areas, mind you, but it will not be able to detect pointer events therein. A small sacrifice for full-screen glory!

The purpose of those edge gestures—swipes from the edge of the screen toward the center—is to keep both system and app commands (like menus and other commanding UI) out of the way until needed—an aspect of the design principle called “content before chrome.” This helps the user stay fully immersed in the app experience. The left and right edge gestures are reserved for the system, whereas the top and bottom are for the app. Swiping up from the top or bottom edges, as you’ve probably seen, brings up the app bar on the bottom of the screen where an app places most of its commands, and possibly also a navigation bar on the top. We’ll see these in Chapter 9, “Commanding UI.”

When running full-screen, the user’s device can be oriented in either portrait or landscape, and apps can process various events to handle those changes. An app can also lock the orientation as needed, as well as specify its supported orientations in the manifest, which prevent Windows from switching to an unsupported orientation when the app is in the foreground. For example, a movie player will generally want to lock into landscape mode during playback such that rotating the device doesn’t change the display. We’ll see these details in Chapter 8, "Layout and Views."

What’s also true is that your app might not always be running full-screen, even from first launch. In landscape mode, you app can share the screen real estate with perhaps as many as four other apps, depending on the screen size.4(See Figure 1-6.)In these cases it’s helpful to refer to the app’s display area as a view. By default, Windows allows the user to resize a view down to 500 pixels wide, and you can indicate in your manifest that your app supports going down to 320 pixels wide, increasing the likelihood that the user will keep it visible alongside other apps.


FIGURE 1-6 Various arrangements of Windows Store apps—a 50/50 split view on the smaller screen (in front), and four apps sharing the screen on a large monitor (behind). Depending on the minimum size indicated in their manifests, apps must be prepared to show properly in any width and orientation, a process that generally just involves visibility of elements and layout and that can often be handled entirely within CSS media queries.

In practical terms, variable view sizing means that your layout must be responsive, as it’s called with web design, accommodating different aspect ratios and different widths and heights. Generally speaking, most if not all of this can be handled through CSS media queries using theorientation feature (to detect portrait or landscape aspect ratio) along with min-width and max-width. We’ll see distinct examples in Chapter 2. It’s also worth noting that when one app launches another through associations or other contracts, it can specify whether and how it wants its view to remain visible. This makes it possible to really have two apps working together side by side for a shared purpose. Indeed, the default behavior when the user activates a hyperlink in an app is that the browser will open in a 50/50 split view alongside the app.

Apps can also programmatically spawn multiple views, which the user can size and position independently of one another, even across multiple monitors. (For this reason, views cannot depend on their relative placement and should represent separate functions of the app.) An app can even project a secondary view such that it always shows full-screen on a second monitor, as is appropriate for an app that shows speaker notes in one view and a presentation in the other.

In narrow views, especially the optional 320px minimum, apps will often change the presentation of content or its level of detail. For instance, in portrait aspect ratios (height > width), horizontally oriented lists are typically switched to a condensed vertical orientation. But don’t be nonchalant about this: consciously design views for every page in your app and design them well. After all, users like to look at things that are useful and beautiful, and the more an app does this with all its views, the more likely it is that users will again keep that app visible even while they’re working in another.

Another key point for all views is that they aren’t mode changes. When a view is resized but still visible, or when orientation changes, the user is essentially saying, “Please stand over here in this doorway, or please lean sideways.” So the app should never change what it’s doing (like switching from a game board to a high score list) when updating a view’s layout;it should just present a view appropriately for that width and orientation.

With all views, an app should make good use of all its available screen realestate. Across your customer base, your app will be run on many different displays, anywhere from 1024x768 (the minimum hardware requirement) to resolutions like 2560x1440 and beyond that are becoming more common. The guidance here is that views with fixed content (like a game board) will generally scale in size to fill the available space, whereas views with variable content (like a news reader) will generally show more content. For more details, refer to Guidelines for window sizes and scaling to screensand the Windows Design Center.

It might also be true that you’re running on a high-resolution device that has a very small screen (high pixel density), such as the 10.6” Surface Pro that has a 1920x1200 resolution, a 13.3” QHD device, or an 8” device with an even sharper screen. Fortunately, Windows does automaticscaling such that the app still sees a 1366x768 display (more or less) through CSS, JavaScript, and the WinRT API. In other words, you almost don’t have to care. The only concern is bitmap (raster) graphics, with which you’ll ideally provide scale-specific variants as we’ll see in Chapters 3and 8. Fortunately, the Windows Store automatically manages resources across scale factors and languages (for localization) such that it downloads only those resources that a user needs for their configuration.

As a final note, when an app is activated in response to a contract like Search or Share, its initial view might not be a typical app view at all but rather its specific landing page for that contract that overlays the current foreground app. We’ll see these details in Chapter 15, "Contracts."

Sidebar: Single-Page vs. Multipage Navigation

When you write a web application with HTML, CSS, and JavaScript, you typically end up with a number of different HTML pages and navigate between them using <a href> tags or by setting document.location.

This is all well and good and works in a Windows Store app, but it has several drawbacks. One is that navigation between pages means reloading script, parsing a new HTML document, and parsing and applying CSS again. Besides obvious performance implications, this makes it difficult to share variables and other data between pages, as you need to either save that data in persistent storage or stringify the data and pass it on the URI.

Furthermore, switching between pages is visually abrupt: the user sees a blank screen while the new page is being loaded. This makes it difficult to provide a smooth, animated transition between pages as generally seen within the Windows personality—it’s the antithesis of “fast and fluid” and guaranteed to make designers cringe.

To avoid these concerns, apps written in JavaScript are typically structured as a single HTML page (basically a container div) into which different bits of HTML content, called page controls in WinJS, are loaded into the DOM at runtime, similar to how AJAX works. This DOM replacement scheme has the benefit of preserving the script context and allows for transition animations through CSS and/or the WinJS animations library. We’ll see the details in Chapter 3.

Those Capabilities Again: Getting to Data and Devices

At runtime, now, even inside the app container, your app has plenty of room to play and to delight your customers. It can employ web content and connectivity to its heart’s content, either directly hosting content in its layout with the webview control or obtaining data through HTTP requests or background transfers (Chapter 4). An app has many different controls at its disposal, as we’ll see in Chapters 5, 6, and 7, and can style them however it likes from the prosaic to the outrageous. Similarly, designers have the whole gamut of HTML and CSS to work with for their most fanciful page layout ideas, along with a Hub control that simplifies a common home page experience (Chapter 8).An app can work with commanding UI like the app bar (Chapter 9), manage state and user data (Chapters 10 and 11), and receive and process pointer events, which unify touch, mouse, and stylus (Chapter 12—with these input methods being unified, you can design for touch and get the others for free; input from the physical and on-screen keyboards are likewise unified). Apps can also work with sensors (Chapter 12), rich media (Chapter 13), animations (Chapter 14), contracts (Chapter 15), tiles and notifications (Chapter 16), and various devices and printers (Chapter 17).They can optimize performance and extend their capabilities through WinRT components (Chapter 18), and they can adapt themselves to different markets (Chapter 19), provide accessibility (Chapter 19), and work with various monetization options like advertising, trial versions, and in-app purchases (Chapter 20).

Note For a more complete mapping between different app features and the chapters of this book, see the “Feature Roadmap and Cross-Reference” section at the end of this chapter.

Many of these features and their associated APIs have no implications where user privacy is concerned, so apps have open access to them. These include controls, touch/mouse/stylus input, keyboard input, and sensors (like the accelerometer, inclinometer, and light sensor). The appdata folders (local, roaming, and temp) that were created for the app at installation are also openly accessible. Other features, however, are again under more strict control. As a person who works remotely from home, for example, I really don’t want my webcam turning on unless I specifically tell it to—I may be calling into a meeting before I’ve had a chance to wash up! Such devices and other protected system features, then, are again controlled by a broker layer that will deny access if (a) the capability is not declared in the manifest, or(b) the user specifically disallows that access at runtime. Those capabilities are listed in the following table:


When user consent is involved, calling an API to access the resource in question will prompt for user consent, as shown in Figure 1-7. If the user accepts, the API call will proceed; if the user declines, the API call will return an error. Apps must accordingly be prepared for such APIs to fail, and they must then behave accordingly.


FIGURE 1-7 A typical user consent dialog that’s automatically shown when an app first attempts to use a brokered capability. This will happen only once within an app, but the user can control their choice through the Settings charm’s Permissions command for that app or through PC Settings > Privacy.

When you first start writing apps, really keep the manifest and these capabilities in mind—if you forget one, you’ll see APIs failing even though all your code is written perfectly (or was copied from a working sample). In the early days of building the first Windows Store apps at Microsoft, we routinely forgot to declare the Internet (Client) capability, so even things like getting to remote media with an img element or making a simple call to a web service would fail. Today the tools do a better job of alerting you if you’ve forgotten a capability, but if you hit some mysterious problem with code that you’re sure should work, especially in the wee hours of the night, check the manifest!

We’ll encounter many other sections of the manifest besides capabilities in this book. For example, you can provide a URI through which Windows can request tile updates so that your app has a live tile experience even before it is run the first time. The removable storage capability requires you to declare the specific file types for your app (otherwise access will generally be denied). The manifest also contains content URIs: specific rules that govern which URIs are known and trusted by your app and can thus act to some degree on the app’s behalf.Furthermore, the manifest is where you declare things like your supported orientations, background tasks (like playing audio, tracking geofences, or handling real-time communication), contract behaviors (such as which page in your app should be brought up in response to being invoked via a contract), custom protocols, and the appearance of tiles and notifications. You and your app will become bosom buddies with the manifest.

The last note to make about capabilities is that while programmatic access to the file system is controlled by certain capabilities, the user can always point your app to other noncritical areas of the file system—and any type of file—through the file picker UI. (See Figure 1-8.) This explicit user action is taken as consent for your app to access that particular file or folder (depending on what you’re asking for). Once you’re app is given this access, you can use certain APIs to record that permission so that you can get to those files and folders the next time your app is launched.

In summary, the design of the manifest and the brokering layer is to ensure that the user is always in control where anything sensitive is concerned, and as your declared capabilities are listed on your app’s description page in the Windows Store, the user should never be surprised by your app’s behavior.


FIGURE 1-8 Using the file picker UI to access other parts of the file system from within a Store app, such as folders on a drive root (but not protected system folders). This is done by tapping the down arrow next to “Files.” Typically, the file picker will look much more interesting when it’s pointing to a media library!

Taking a Break, Getting Some Rest: Process Lifecycle Management

Whew! We’ve covered a lot of ground already in this first chapter—our apps have been busy, busy, busy, and we haven’t even started writing any code yet! In fact, apps can become really busy when they implement certain sides of contracts. If an app declares itself as a Share target, a Contact or Appointments provider, or a File Picker provider in its manifest (among other things), Windows will activate the app in response to the appropriate user actions. For example, if the user invokes the Share charm and picks your app as a Share target, Windows will activate the app with an indication of that purpose. In response, the app displays its specific share UI—not the whole app—and when that task is complete, Windows will shut your app down again (or send it to the background if it was already running) without the need for additional user input.

This automatic shutdown or sending the app to the background are examples of built-in lifecycle management for Windows Store apps that helps conserve power and optimize battery life. One reality of traditional multitasking operating systems is that users typically leave a bunch of apps running, all of which consume power. This makes sense with desktop apps because many of them can be at least partially visible simultaneously. But for Store apps, the system is boldly taking on the job itself and using the full-screen nature of those apps (or the limited ability to share the screen) to its advantage.

Apps typically need to be busy and active only when the user can see them (in whatever view). When most apps are no longer visible, there is really little need to keep them idling. It’s better to just turn them off, give them some rest, and let the visible apps utilize the system’s resources.

So when an app goes to the background, Windows will automatically suspend it after about 5 seconds (according to the wall clock). The app is notified of this event so that it can save whatever state it needs to (which I’ll describe more in the next section). At this point the app is still in memory, with all its in-memory structures intact, but it will simply not be scheduled for any CPU time. (See Figure 1-9.) This is very helpful for battery life because most desktop apps idle like a gasoline-powered car, still consuming a little CPU in case there’s a need, for instance, to repaint a portion of a window. Because a Windows Store app in the background is completely obscured, it doesn’t need to do such small bits of work and can be effectively frozen. In this sense it is much more like a modern electric vehicle that can be turned on and off as often as necessary to minimize power consumption.

If the user then switches back to the app (in whatever view, through whatever gesture), it will be scheduled for CPU time again and resume where it left off (adjusting its layout for the view, of course). The app is also notified of this event in case it needs to re-sync with online services, update its layout, refresh a view of a file system library, or take a new sensor reading because any amount of time might have passed since it was suspended. Typically, though, an app will not need to reload any of its own state because it was in memory the whole time.


FIGURE 1-9 Process lifetime states for Windows Store apps.

There are a couple of exceptions to this. First, Windows provides a background transfer API—see Chapter 4, “Web Content and Services”—to offload downloads and uploads from app code, which means apps don’t have to be running for such purposes. Apps can also ask the system to periodically update live tiles on the Start screen with data obtained from a service, or they can employ push notifications (through the Windows Push Notification Service, WNS) that Windows can handle directly—see Chapter 16, “Alive with Activity.” Second, certain kinds of apps do useful things when they’re not visible, such as audio players, communications apps, or those that need to take action when specific system events occur (like a network change, user login, etc.). With audio, as we’ll see in Chapter 13, “Media,” an app specifies background audio in its manifest (where else!) and sets certain properties on the appropriate audio elements. This allows it to continue running in the background. With system events, as we’ll also see in Chapter 16, an app declares background tasks in its manifest that are tied to specific functions in their code. In this case, Windows will run that task (while the app is suspended) when an appropriate trigger occurs. This is shown at the bottom of Figure 1-9.

Over time, of course, the user might have many apps in memory, and most of them will be suspended and consume very little power. Eventually there will come a time when the foreground app—especially one that’s just been launched—needs more memory than is available. In this case, Windows will automatically terminate one or more apps, dumping them from memory. (See Figure 1-9 again.)

But here’s the rub: unless a user explicitly closes an app—by using Alt+F4 or a top-to-bottom swipe-and-hold, because Windows Store policy specifically disallows apps with their own close commands or gestures—she still rightly thinks that the app is running. If she activates it again (as from its tile), she will expect to return to the same place she left off. For example, a game should be in the same place it was before (though automatically paused), a reader should be on the same page, and a video should be paused at the same time. Otherwise, imagine the kinds of ratings and reviews your app will be getting in the Windows Store!

So you might say, “Well, I should just save my app’s state when I get terminated, right?” Actually, no: your app will not be notified when it’s terminated. Why? For one, it’s already suspended at that time, so no code will run. In addition, if apps need to be terminated in a low memory condition, the last thing you want is for apps to wake up and try to save state which might require even more memory! It’s imperative, as hinted before, that apps save their state when being suspended and ideally even at other checkpoints during normal execution. So let’s see how all that works.

Remembering Yourself: App State and Roaming

To step back for a moment, one of the key differences between traditional desktop applications and Windows Store apps is that the latter are inherently stateful. That is, once they’ve run the first time, they remember their state across invocations (unless explicitly closed by the user or unless they provide an affordance to reset the state explicitly). Some desktop applications work like this, but most suffer from a kind of identity crisis when they’re launched. Like Gilderoy Lockhart in Harry Potter and the Chamber of Secrets, they often start up asking themselves, “Who am I?”7with no sense of where they’ve been or what they were doing before.

Clearly this isn’t a good idea with Store apps whose lifetime is being managed automatically. From the user’s point of view, apps are always running (even if they’re not). It’s therefore critical that apps first manage settings that are always in effect and then also save their session state when being suspended. This way, if the app is terminated and restarted, it can reload that session state to return to the exact place it was before. (An app receives a flag on startup to indicate its previous execution state, which determines what it should do with saved session state. Details are in Chapter 3.)

There’s another dimension to statefulness:remember from earlier in this chapter that a user can install the same Windows Store app on up to eighty-one devices? Well, that means that an app, depending on its design, of course, can also be stateful between those devices. That is, if a user pauses a video or a game on one device or has made annotations to a book or magazine on one device, the user will naturally want to be able to go to another device and pick up at exactly the same place.

Fortunately, Windows makes this easy—really easy, in fact—by automatically roaming app settings and state, along with Windows settings, between trusted devices on which the user is logged in with the same Microsoft account, as shown in Figure 1-10. When roaming state exists, it’s automatically downloaded as part of app installation, so it’s there when the app is first launched on a new device.


FIGURE 1-10 Automatic roaming of app roaming data (folder contents and settings) between devices.

They key here is understanding how and where an app saves its state. (We already know when.) If you recall, there’s one place on the file system where an app has unrestricted access: its appdata folder. Within that folder, Windows automatically creates subfolders named LocalState, RoamingState, and TempState when the app is installed. (I typically refer to them without the “State” suffix.) The app can programmatically get to any of these folders at any time and can create in them all the files and subfolders that will fulfill its heart’s desire. There are also APIs for managing individual Local and Roaming settings (key-value pairs), along with groups of settings called composites that are always written to, read from, and roamed as a unit. (These are useful when implementing the app’s Settings features for the Settings charm, as covered in Chapter 10, “The Story of State, Part 1.”)

Now, although the app can write as much as it wants to the appdata areas (up to the capacity of the file system), Windows will automatically roam the data in your Roaming sections only if you stay below an allowed quota (~100K, but there’s an API for that). If you exceed the limit, the data will still be there locally but none of it will be roamed. Also be aware that cloud storage has different limits on the length of filenames and file paths as well as the complexity of the folder structure. So keep your roaming state small and simple. If the app needs to roam larger amounts of data, use a secondary web service like OneDrive or Windows Azure Mobile Services (which we’ll see more of in Chapter 16).

The app really needs to decide what kind of state is local to a device and what should be roamed. Generally speaking, any kind of settings, data, or cached resources that are device-specific should always be local (and Temp is also local), whereas settings and data that represent the user’s interaction with the app are potential roaming candidates. For example, an email app that maintains a local cache of messages would keep those local but would roam account settings (sans passwords; see Tip below) so that the user can configure the app on one device and have that configuration apply on every other device. The app would probably also maintain a per-device setting for how it downloads or updates emails so that the user can minimize network/radio traffic on a mobile device. A media player, similarly, would keep local caches that are dependent on the specific device’s display characteristics, and it would roam playlists, playback positions, favorites, and other such settings (should the user want that behavior, of course).

Tip For passwords in particular, always store them in the Credential Locker (see Chapter 4). If the user allows password roaming (PC Settings >OneDrive >Sync Settings >Other Settings >Passwords), the locker’s contents will be roamed automatically.

When state is roamed, know that there’s a simple “last writer wins” policy where collisions are concerned. If you run the same app on two devices at the same time, don’t expect there to be any fancy merging or swapping of state. After all kinds of tests and analysis, Microsoft’s engineers finally decided that simplicity was best!

Along these same lines, if a user installs an app, roams some settings, uninstalls the app, and then within "a reasonable time" reinstalls the app, she will find that those settings are still in place. This makes sense, because it would be too draconian to blow away roaming state in the cloud the moment she just happened to uninstall an app on all her devices. There's no guarantee of this behavior, mind you, but Windows will apparently retain roaming state for an app for some time.

Sidebar: Local vs. Temp Data

For local caching purposes, an app can use either local or temp storage. The difference is that local data is always under the app’s control. Temp data, on the other hand, can be deleted if the user runs the Disk Cleanup utility. Local data is thus best used to support an app’s functionality, and temp data is used to support run-time optimization at the expense of disk space.

For Windows Store apps written in HTML and JavaScript, you can also use existing caching mechanisms like HTML5 local storage, IndexedDB, and app cache, along with third-party database options like SQLite, which act like local storage.

Sidebar: The Opportunity of Per-User Licensing and Data Roaming

Details aside, I personally find the cross-device roaming aspect of the platform very exciting, because it enables the developer to think about apps as something beyond a single-device or single-situation experience. As I mentioned earlier, a user’s collection of apps is highly personal and it personalizes the device; apps themselves are licensed to the user and not the device. In that way, we as developers can think about each app as something that projects itself appropriately onto whatever device and into whatever context it finds itself. On some devices it can be oriented for intensive data entry or production work, while on others it can be oriented for consumption or sharing. The end result is an overall app experience that is simply more present in the user’s life and appropriate to each context.

An example scenario is illustrated below, where an app can have different personalities or flavors depending on user context and how different devices might be used in that context. It might seem rather pedestrian to think about an app for meal planning, recipe management, and shopping lists, but that’s something that happens in a large number of households worldwide. Plus it’s something that my wife would like to see me implement if I ever get around to writing more code than text!

This, to me, is the real manifestation of the next era of personal computing, an era in which personal computing expands well beyond, yet still includes, a single device experience and includes embracing the power of cloud-based resources for your personal needs. Devices, then, are merely viewports for your apps and data, each viewport having a distinct role in the larger story of how your move through and interact with the world at large.


Sidebar: Writing Windows Phone Apps with HTML, CSS, and JavaScript

The diagram in the previous sidebar shows that a Windows Phone can be part of an overall app presence across multiple devices. At present, apps for Windows 8.1 and Windows Phone 8.1 are still separate entities, each with their own identity, app package, and storefront. As such, they do not as yet share common roaming data. They can, however, use common backend services such as Windows Azure Mobile Services for data sharing and managing push notifications. You can also use a common live tile service as the tile update XML format is the same on both.

Indeed, much is the same on the platform level, including the fact that Windows Phone 8.1 supports apps written in HTML, CSS, and JavaScript, exactly like those we’re talking about in this book. With the appropriate update to Visual Studio 2013, you can create solutions in which you can easily share code between Windows and Windows Phone projects.

On the API level, you’ll find that most of WinRT is identical between both platforms, excepting those areas where the underlying hardware can’t support a particular feature or the form factor isn’t suitable. For example, inking, printing, USB/HID device access, the built-in camera capture UI, and various aspects of a full file system are not available on Windows Phone. Similarly, phone-specific features like the Wallet API are not available on Windows.

WinJS is available on both platforms as well but differs somewhat in the available controls, which I’ll detail in Chapter 5. That said, the app model that WinJS presents is identical across both, as are the mechanisms for dealing with async operations and data binding.

Suffice it to say that much of what you’ll learn in this Second Edition will be completely applicable to Windows Phone projects, which is great news because it means you can use all the skills you develop to write apps for a much larger combined market! And as the platforms become increasingly converged in the future, your investments of today will continue to bear fruit.

As I mentioned at the beginning of this chapter, the ability to write Windows Phone apps with HTML, CSS, and JavaScript came quite late in the production cycle of this book, so our focus here will still be Windows Store apps. That said, the Windows Developer Center will have more information for Windows Phone Apps written in JavaScript, such as clear documentation on the variations in WinJS and WinRT. I’ll also be working on content for both the Windows/Windows Phone developer blog (where you’ll also find announcements about the platforms) andmy personal blog. Hope to see you there!

Coming Back Home: Updates and New Opportunities

If you’re one of those developers that can write a perfect app the first time, I have to ask why you’re actually reading this book! Fact of the matter is that no matter how hard we try to test our apps before they go out into the world, our efforts pale in comparison to the kinds of abuse that customers will heap on them. To be more succinct: expect problems. An app might crash under circumstances we never predicted, or there just might be usability problems because people are finding creative ways to use the app outside of its intended purpose.

Fortunately, the Windows Store dashboard—go to and click the Dashboard tab at the top—makes it easy for you get the kind of feedback that has traditionally been very difficult to obtain. For one, the Store maintains ratings and reviews for every app, which will be a source of valuable insight into how well your app fulfills its purpose in life and a source of ideas for your next release. And you might as well accept it now: you’re going to get praise (if you’ve done a decent job), and you’re going to get criticism, even a good dose of nastiness (even if you’ve done a decent job!). Don’t take it personally—see every critique as an opportunity to improve, and be grateful that people took the time to give feedback. As a wise man once said upon hearing of the death of his most vocal critic, “I’ve just lost my best friend!”

The Store will also provide you with crashanalytics so that you can specifically identify problem areas in your app that evaded your own testing. This is incredibly valuable—maybe you’re already clapping your hands in delight!—because if you’ve ever wanted this kind of data before, you’ve had to implement the entire mechanism yourself. No longer. This is one of the valuable services you get in exchange for your annual registration with the Store. Of course, crash analytics are only the beginning—you’ll typically want to instrument your app for much more detailed telemetry so that you can understand exactly how your customers are using your app and where you want to invest more effort. For this there are a number of third-party solutions found on the Windows Partner Directory, and we’ll talk about this a little more in Chapter 20.

With this data in hand and all the other ideas you either had to postpone from your first release or dreamt up in the meantime, you’re all set to have your app come home for some new love before its next incarnation.

Updates are onboarded to the Windows Store just like the app’s first version. You create and upload an app package (with the same package name as before but a new version number), and then you update your description, graphics, pricing, and other information. After that your updated package goes through the same certification and signing process as before, and when all that’s complete your new app will be available in the Store and automatically installed for your existing customers (unless they opt out). And remember that with the blockmap business described earlier, only those parts of the app that have actually changed will be downloaded for an update (to a 64K resolution). This means that issuing small fixes (especially if they’re placed at the end of files) won’t force users to repeat potentially large downloads each time, bringing the update model closer to that of web applications.

When an update gets installed that has the same package name as an existing app, all the settings and appdata for the prior version remain intact. Your updated app should be prepared, then, to migrate a previous version of its state if and when it encounters such.

This brings up an interesting question: what happens with roaming data when a user has different versions of the same app installed on multiple devices? The answer is twofold: first, app state (which includes roaming data) has its own version number independent of the app, and second, Windows will transparently maintain multiple versions of the roaming state so long as there are apps installed on the user’s devices that reference those state versions. Once all the devices have updated apps and have converted their state, Windows will delete old versions. We’ll talk more of this in Chapter 10.

Another interesting question with updates is whether you can get a list of the customers who have acquired your app from the Store. The answer is no, because of privacy considerations. However, there is nothing wrong with including a registration feature in your app through which users can optin to receive additional information from you, such as more detailed update notifications. Your Settings panel is a great place to include this.

The last thing to say about the Store is that in addition to basic analytics about your own app—which also includes data like sales figures, of course—it also provides you with marketwide analytics. These help you explore new opportunities to pursue—maybe taking an idea you had for a feature in one app and breaking that out into a new app in a different category. Here you can see what’s selling well (and what’s not) or where a particular category of app is underpopulated or generally has less than average reviews. For more details, again see the Dashboard at

And, Oh Yes, Then There’s Design

In this first chapter we’ve covered the nature of the world in which Windows Store apps live and operate. In this book, too, we’ll be focusing on the details of how to build such apps with HTML, CSS, and JavaScript. But what we haven’t talked about, and what we’ll only be treating minimally, is how you decide what your app does—its purpose in the world!—and how it clothes itself for that purpose.

This is really the question of good design for Windows Store apps—all the work that goes into apps before we even start writing code.

I said that we’ll be treating this minimally because I simply do not consider myself a designer. I encourage you to be honest about this yourself: if you don’t have a good designer working with you, get one. Sure, you can probably work out an OK design on your own, but the demands of a consumer-oriented market combined with a newer design language like that employed in Windows—where the emphasis is on simplicity and tailored experiences—underscores the need for professional help. It’ll make the difference between a functional app and a great app, between a tool and a piece of art, between apps that consumers accept and those they love.

With design, I do encourage developers to peruse the material on theWindows Design Center for a better understanding of design principles. And if you’re going to be playing the role of designer, a great place to start is the Category ideas area where you’ll find case studies for converting websites, iOS apps, and enterprise LOB apps to a Windows Store app and many idea books that serve as starting points for different kinds of experiences.

But let’s be honest: as a developer, do you really want to ponder every design principle and design not just static wireframes but also the dynamic aspects of an app like animations, page transitions, and progress indicators? Do you want to spend your time in graphic design and artwork (which is essential for a great app)? Do you want to haggle over the exact pixel alignment of your layout in all variable views? If not, find someone who does, because the combination of their design sensibilities and your highly productive hacking will produce much better results than either of you working alone. As one of my co-workers puts it, a marriage of “freaks” and “geeks” often produces the most creative, attractive, and inspiring results.

Let me add that design is neither a one-time nor a static process. Developers and designers will need to work together throughout the development experience, as design needs will arise in response to how well the implementation really works. For example, the real-world performance of an app might require the use of progress indicators when loading certain pages or might be better solved with a redesign of page navigation. It may also turn out, as we found with one of our early app partners, that the kinds of graphics called for in the design simply weren’t available from the app’s backend service. The design was lovely, in other words, but couldn’t actually be implemented, so a design change was necessary. So make sure that your ongoing relationship with your designers is a healthy and happy one.

And on that note, let’s get into your part of the story: the coding!

Feature Roadmap and Cross-Reference

As a means of indexing the content in this book, the tables below identifies the primary platform features of Windows 8.1, the chapter and section(s) where they’re covered, and the purpose that those features serve in apps. Note that this is only a cross-reference for platform features: it does not represent nonfeature topics such as tooling, best practices, custom extensions, and design.




















1 All of the automated tests except the malware scans are incorporated into the Windows App Certification Kit, affectionately known as the WACK. This is part of the Windows SDK that is itself included with the Visual Studio Express/Expression Blend download. If you can successfully run the WACK during your development process, you shouldn’t have any problem passing the first stage of onboarding. We’ll learn about the WACK in Chapter 20.

2 The user always has the ability to disallow access to sensitive resources and devices at run time for those apps that have declared the intent. They can do this for a specific app through the system-provided Settings > Permissions command or generally through the various section under PC Settings > Privacy.

3 “wwa” is an old acronym for Windows Store apps written in JavaScript; some things just stick….

4 For developers familiar with Windows 8, the distinct view states of filled, snapped, fullscreen-portrait, and fullscreen-landscape are replaced in Windows 8.1 with variable sizing.

5 Note that network capabilities are not necessary to receive push notifications because those are received by the system and not the app.

6 The Documents Library capability that was present in Windows 8 no longer exists in Windows 8.1 because the scenarios that actually needed it can be handled through file pickers.

7 For those readers who have not watched this movie all the way through the credits, there’s a short vignette at the very end. During the movie, Lockhart—a prolific, narcissistic, and generally untruthful autobiographer—loses his memory from a backfiring spell. In the vignette he’s shown in a straitjacket on the cover of his newest book, Who am I?