Windows 8 App开发：WinRT平台特性与HTML, CSS, JavaScript编程

3星 · 超过75%的资源需积分: 9 109 浏览量更新于2024-07-27 1 收藏 11.48MB PDF 举报

"Windows 8编程" 本书是针对Windows 8应用开发的指南，主要讨论了使用HTML、CSS和JavaScript进行编程的相关知识。作者Kraig Brockschmidt深入浅出地介绍了开发Windows 8应用程序的各种关键概念和技术。在第一章中，作者首先概述了WinRT（Windows运行时）应用的生命周期和平台特性。这一章涵盖了Windows 8商店的集成，包括应用的发现、获取和安装过程，以及应用容器的概念，这是Windows 8应用安全运行的基础。此外，还讨论了视图状态和分辨率缩放，这对于创建适应不同屏幕尺寸和方向的应用至关重要。接着，书中提到了应用访问数据和设备的能力，如利用Windows 8的权限系统来访问本地存储和外部设备。处理应用的生命周期管理，包括进程管理，确保了应用在各种情况下能够正确响应。关于应用状态和漫游功能，书中解释了如何保存和恢复用户的状态，以便跨设备同步。更新管理和新机会的讨论则涵盖了如何为应用提供持续的改进和支持。最后，设计部分强调了在Windows 8应用设计中的原则和最佳实践。第二章作为快速入门，引导读者通过空白应用模板快速上手。这里详细介绍了项目结构，并演示了如何使用Blend for Visual Studio工具来创建标记和样式，帮助开发者理解如何构建UI并美化应用。设计草图和创建标记的部分提供了实际操作的步骤，而样式编辑则展示了如何利用CSS增强应用的视觉效果。这本书的目标读者是对Windows 8应用开发感兴趣的开发者，无论他们是否有HTML、CSS或JavaScript的基础。书中提供的内容全面且实用，旨在帮助读者迅速掌握开发Windows 8应用所需的技能。标签“Windows8”表明本书专注于Windows 8操作系统及其开发环境。部分内容提及的软件版本可能为预览版，意味着在最终商业发布之前可能会有重大变化。读者应理解，此书中的信息可能随着软件的更新而更新，微软对此文档内容不做任何明示或默示的保证。书中使用的公司、组织、产品等例子均为虚构，不与任何真实实体关联，其目的在于教学而非实际引用。

Chapter 1

The Life Story of a WinRT App:

Platform Characteristics

of Windows 8

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 now

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 provides 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 WinRT for short.

WinRT APIs are implemented according to a certain low-level structure and then “projected” into

different languages 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 names on methods, properties, and events.

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 8 apps using the WinRT API.

Those apps will, of course, be specific to the Windows 8 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!

Throughout this book we’ll explore how to leverage what you know of standards-based web

technologies to build great Windows 8 apps. 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,

controls, collections, layout, commanding, state management, and input, followed by chapters on

media, animations, contracts through which apps work together, networking, devices, WinRT

components, and the Windows Store (a topic that includes localization and accessibility). There is much

to learn.

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 rest, renewal, and rebirth. 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 WinRT apps are those that are acquired from the Windows

Store and for which all the platform characteristics in this chapter (and book) apply. In consumer

contexts these are also known as Windows Store apps, but since we’re primarily interesting in how

they’re written—using the WinRT API—we’ll refer to them as WinRT apps. These are distinctly different

from traditional desktop applications that are acquired through regular retain channels and installed

through their own installer programs. Unless noted, then, an “app” in this book refers to a WinRT app.

Leaving Home: Onboarding to the Store

For WinRT 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.

The package itself is an

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. Visual Studio Express and Expression Blend, which we’ll be using as well, are free tools that you can obtain

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!

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 a sort 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. The blockmap, for its part,

describes how the app’s files are broken up into 64K blocks. In addition to providing certain security functions (like

detecting whether a package has been tampered with) and performance optimization, the blockmap is used to

determine exactly what parts of an app have been updated between versions so the Windows Store only needs to

download those specific blocks rather than the whole app anew.

The upload process will walk you through setting your app’s name, 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 essentially 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.

from http://dev.windows.com. This also works in Visual Studio Ultimate, the fuller, paid version of this flagship development

environment.

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

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. As 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.

As a developer, 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 if you 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 read the first parts of Chapter 17,

"Apps for Everyone," before you start writing your app in earnest.)

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 Certification requirements for Windows apps (part of the

Windows Store agreements section). Otherwise, congratulations—your app is ready for customers!

Sidebar: The Store API and Product Simulator

The Windows.ApplicationModel.Store.CurrentProduct class in WinRT provides the ability for

apps to retrieve their product information from the store (including in-app purchases), check

license status, and prompt the user to make purchases (such as upgrading a trial or making an

in-app purchase).

Of course, 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

Windows.ApplicationModel.Store.CurrentProductSimulator class instead. This is entirely

identical to CurrentProduct 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

download. If you can successfully run the WACK during your development process, you shouldn’t have any problem passing the

first stage of onboarding.

剩余536页未读，继续阅读

helloworldNEU

粉丝: 1
资源: 13

Windows 8 App开发：WinRT平台特性与HTML, CSS, JavaScript编程

Windows 8编程实战：C#与XAML开发指南（第六版）

Windows 8编程实战：C#与XAML技术指南

Windows 8编程指南：C#与XAML实战

Windows 8编程入门：C#与XAML实战

Windows核心编程源码_belong4pp_windows核心编程源码_windows核心编程_核心编程_

windows编程

Windows 编程

Windows API 编程_pdf_windowsAPI编程_

Windows API编程

Windows程序编程

最新资源