25-08-2017, 09:32 PM
Programming Windows® 8 Apps with HTML, CSS, and JavaScript
Programming Windows.pdf (Size: 4.4 MB / Downloads: 32)
Introduction
Welcome, my friends, to Windows 8! On behalf of the thousands of designers, program managers,
developers, test engineers, and writers who have brought the product to life, I'm delighted to welcome
you into a world of Windows Reimagined.
This theme is no mere sentimental marketing ploy, intended to bestow an aura of newness to
something that is essentially unchanged, like those household products that make a big splash on the
idea of "New and Improved Packaging!" No, Microsoft Windows truly has been reborn—after more
than a quarter-century, something genuinely new has emerged.
I suspect—indeed expect—that you're already somewhat familiar with the reimagined user
experience of Windows 8. You're probably reading this book, in fact, because you know that the ability
of Windows 8 to reach across desktop, laptop, and tablet devices, along with the global reach of the
Windows Store, will provide you with tremendous business opportunities, whether you're in business,
as I like to say, for fame, fortune, fun, or philanthropy.
We'll certainly see many facets of this new user experience—the Metro style UI—throughout the
course of this book. Our primary focus, however, will be on the reimagined developer experience.
I don't say this lightly. When I first began giving presentations within Microsoft about building
Metro style apps, as they are called, I liked to show a slide of what the world was like in the year 1985.
It was the time of Ronald Reagan, Margaret Thatcher, and Cold War tensions. It was the time of VCRs
and the discovery of AIDS. It was when Back to the Future was first released, Michael Jackson topped
the charts with Thriller, and Steve Jobs was kicked out of Apple. And it was when software developers
got their first taste of the Windows API and the programming model for desktop apps.
Leaving Home: Onboarding to the Store
For Metro style 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 the Store alone.
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 Package command in Visual Studio.1 The package itself is an
appx file (.appx)—see Figure 1-1—that contains your app’s code, resources, libraries, and a manifest.
The manifest describes the app (names, logos, etc.), the capabilities it wants to access (such as areas of
the file system 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!
Discovery, Acquisition, and Installation
Now that your app is out in the world, its next job is to make itself known and attractive to your
customers. Simply said, while consumers can find your app in the Windows Store through browsing or
search, you’ll still need to market your product as always. That’s one reality of the platform that
certainly hasn’t changed. That aside, even when your app is found in the Store, it still needs to present
itself well to its suitors.
Each app in the Store has a product description page where people see your app description, screen
shots, 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 explains itself. 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.