[This documentation is preliminary and is subject to change.]
The Windows Runtime is designed to enable you to create Metro style apps in a language-independent way. A Metro style app maintains the benefits of the web, but extends the browser experience to the richer experience of Windows.
Windows provides a broad range of technologies for developers. By design, the Windows Runtime provides a subset of the full range of Windows technologies. To start with, we looked at the characteristics and scenarios that we believe are important for Metro style apps. We also looked at the capabilities provided by standards such as HTML, CSS, DOM, and JavaScript. In general, we added APIs to the Windows Runtime if they supported the key scenarios for Metro style apps, but were not already sufficiently covered by the existing libraries. You can continue to use the web technologies you know today in your Metro style apps.
Over time, the Windows Runtime will evolve, providing a fuller subset of Windows technologies to support engaging apps and experiences.
The Structure of the Windows Runtime
The Windows Runtime is exposed using API metadata (.winmd files). This is the same format used by the .NET framework (Ecma-335). The underlying binary contract makes it easy for you to access the Windows Runtime APIs directly in the development language of your choice. The shape and structure of the Windows Runtime APIs can be understood by both static languages such as C# and dynamic languages such as JavaScript. IntelliSense is available in JavaScript, C#, Visual Basic, and C++.
Each .winmd file exposes one or more namespaces. These namespaces are grouped by the functionality that they provide. A namespace contains types such as classes, structures, and enumerations. A type contains members such as methods, properties, and fields. The following table describes the groups of Windows Runtime namespaces.
| Namespace group | Description |
|---|---|
| Windows.ApplicationModel | Manages app launch, activation, suspend, and resume. |
| Windows.Data | Manages JSON and XML data. |
| Windows.Devices | Provides support for devices such as sensors and cameras. |
| Windows.Foundation | Provides fundamental functionality, including reading and writing asynchronously, and managing property sets and collections. |
| Windows.Globalization | Enables you to create a world-ready app. |
| Windows.Graphics | Provides graphics support. |
| Windows.Management | Provides support for managing Appx packages. |
| Windows.Media | Provides audio and video functionality. |
| Windows.Networking | Provides networking functionality. |
| Windows.Security | Provides access to security features. |
| Windows.Storage | Manages files, folders, and app data. |
| Windows.System | Provides access to system features. |
| Windows.UI | Provides a framework and API to define the user interface. |
| Windows.UI.Xaml | Provides a framework and API for using Extensible Application Markup Language (XAML) to define the user interface. |
| Windows.Web | Enables you to manage syndication feeds and access resources using the AtomPub protocol. |
Windows Runtime programming concepts
Activatable classes
Creating an instance of a Windows Runtime class is known as activation. The way you activate a class depends on the programming language you're using. For example, in JavaScript, you'd use the new operator to activate a class.
When you activate a class, Windows checks whether you can access the requested user data or system resources. If additional access is needed, you must specify the required capabilities in the package manifest for the app.
There's no need to manage the lifetime of underlying object. Windows releases the object when you're finished with the last of its class instances that you've activated.
Events and delegates
An event is a programming pattern where one object signals another object that an interesting action has occurred. The action could be a result of the user interacting with your app, or of some other code completing. The object that raises the event is the event sender. The object that captures and handles the event in one of its methods is called the event receiver.
A delegate is a class that contains a reference to a method that matches a particular signature. It is similar to a type-safe function pointer or a callback function. When an object receives the event, the associated delegate dispatches the event to the event-handling method.
The syntax of a delegate is similar to that of a method. A delegate has two parameters, one that specifies the event sender, and the other that contains event-specific data.
When you subscribe to an event, you use the mechanism supported by the programming language you're using. For example, in JavaScript, you'd use the addEventListener method.
Asynchronous operation
A Metro style app should respond to touch and other direct manipulation immediately. Because of their interactive nature, it is very important for the UI thread of a Metro style apps to be responsive. The UI thread must not block on API calls that can take a long time to return, or it could miss event notifications sent to you by the operating system. Therefore, the Windows Runtime uses the asynchronous model to drive the workload of the UI thread and help you deliver a responsive app. We recognize that this model will require you to write more code in some places, but the tradeoff will be worth it to your customers.
The general pattern supported by the Windows Runtime is to get the result of the asynchronous call using the Completed and GetResults methods. In C#, you can use the async and await keywords. In JavaScript use the then syntax.
See Asynchronous patterns in the Windows Runtime.
Capabilities
By default, Metro style apps cannot access user data or system resources in a way that may compromise a user's privacy or the reliability of the system.
Apps are granted access to the CPU to run their code and user-interaction devices such as the keyboard and touch.
To deliver apps that are compelling and help your customers stay connected, you'll generally need to request access to libraries, networks, and additional devices. Whenever you use an API that requires access to the protected resources, you must declare the related capabilities in the package manifest for your app. If an app attempts to access resources that require capabilities that are not declared in the manifest, access is denied. The system verifies that the user has granted access to the resources your app requires. While most capabilities are verified when the customer acquires your app, some capabilities require verification at runtime.
See Access to user resources using the Windows Runtime.
Contracts
Contracts enable your Metro style app to share information with other apps and with the operating system.
- Search. Provide results from your app to the Windows Search experience. See Adding search .
- Share. Share content produced by your app with other apps. Shared content can be photos, links, or text stored locally or with a share provider, such as a social networking site. See Sharing content between apps.
- PlayTo. Play audio, video, or images on a connected device the user selects after clicking the Connect Edge’s PlayTo button. See Streaming media to devices using PlayTo.
- Settings. Indicate your app's user preferences, consistent with the Windows settings model. See Adding app settings.
- App to app picking. Enables your app opt-in to access information in files that are stored by another app.
For more information, see Windows application contracts.
Custom components
You can build reusable libraries for use with your apps as custom components. Build your custom components with C#, Visual Basic, or Microsoft Visual C++ and use them from JavaScript or any other supported language in your apps—just as you would call a Windows Runtime API. Your custom components are included in the package for your app.
Related topics
Build date: 9/7/2011
