Windows 8 Tips and Tricks » Style

Building your own Windows Runtime components to deliver great Metro style apps

admin — Tue, 07 Aug 2012 01:24:03 +0000

For Windows 8, we completely reimagined the platform, allowing you to choose the programming language and technologies you already know to build apps tailored to the device and form factor. With the Windows Runtime, you can even easily use multiple languages within a single app. You can build a great Metro style app with HTML and JavaScript that can interact with the Xbox 360 controller through building your own Windows Runtime component in C++. You can build reusable XAML controls exposed via Windows Runtime components that are instantly consumable by Metro style apps written in both C++ and C#. Essentially, we have let you build apps on the Windows 8 platform using the languages of your choice with no comprises.

In this blog post, we talk about what you need to know to build your own Windows Runtime components.

The basics

The Windows Runtime is at the heart of empowering language choice. It exposes so that you can call them from JavaScript, C++, C# and Visual Basic in a way that’s natural and familiar. This same foundation is available to you when building your own APIs too.

A Windows Runtime component that you build and package in your app is typically referred to as a 3^rd party Windows Runtime component. This differs from 1^st party components that are already part of the Windows 8 platform. You can write these 3^rd party Windows Runtime components in C++, C# or Visual Basic. You can call into the APIs they expose from anywhere, including other Windows Runtime components packaged into your app. You can also call into the APIs exposed via Windows Runtime components from any language.

The Windows Runtime components that you write for your app can use Windows Runtime APIs, Win32, COM, .NET APIs or 3^rd party libraries as long as they are supported for Metro style app development. Note that the Windows Runtime components that you build are different from what you traditionally know as C++ DLLs or .NET assemblies that expose APIs. Creating a class library in .Net or a standalone DLL in C++ is not the same as building a Windows Runtime component. Windows Runtime components are declared in .wnmd files that expose Windows Runtime metadata and enable languages such as JavaScript to naturally consume Windows Runtime APIs (for example, pascalCasedNames support for APIs exposed to JavaScript). The Windows Runtime metadata also enables Visual Studio to provide great tooling capabilities such as IntelliSense support.

Why build your own Windows Runtime components

Creating Windows Runtime components can help you architect for reusability and language interoperability. Let’s take a look at some app scenarios that showcase how you can use 3^rd party Windows Runtime components to build better experiences.

Figure1: Xbox 360 Controller

Using Win32 and COM APIs in your Metro style app

The platform provided by Internet Explorer 10 enables you to create great Metro style app experiences using HTML, CSS and JavaScript. But what if you have built a game using HTML5 canvas and want to integrate with the Xbox 360 controller for Windows? The XInput API, which allows apps to receive input from the controller, exposes Win32 APIs that are not available directly to JavaScript.

This is a great example of where creating a Windows Runtime component can solve this problem and give you the ability to use the XInput APIs in your HTML based Metro style app. The XInput and JavaScript controller sketch sample showcases exactly that. The sample app contains a game controller Windows Runtime component written in C++ which wraps the functionality exposed by the XInput APIs. The controller sketch HTML-based app uses the game controller C++ Windows Runtime component to enable the interaction with the Xbox 360 controller.

This scenario, impossible to accomplish using HTML and JavaScript alone, is a perfect example of where creating a 3^rd party Windows Runtime component allows you to complete a complex scenario that you otherwise wouldn’t be able to.

Computationally Intensive Operations

Apps created for fields like science, engineering, and maps/geography often have computationally intensive operations. These intensive operations typically require powerful parallel processing and are well suited for C++ to achieve optimal performance. In Developing Bing Maps Trip Optimizer, a Metro style app in JavaScript and C++ , we see another scenario where creating a Windows Runtime component in C++ allows us to create the best experience in our app.

You wonder why anyone would want to calculate a trip route on local data at all when we could run this computationally intensive task in the cloud on Bing servers. Bing Maps exposes JavaScript APIs to do this, but sometimes an app must run offline. And we also want the user to drag and change the route in real time with touch. If we can run these intense operations locally, we create an even better experience.

By writing our compute-intensive operation in C++ using the parallel task library, we can harness the power of the client to create a great experience for users. Windows Runtime is a great fit for this scenario, allowing us to create our rich client User Interface (UI) in HTML and JavaScript with the Bing Maps AJAX control while running all of our intensive route operations using C++ code that calculates quickly using parallelization.

Libraries

The community is filled with great libraries that developers put together and shared for everyone to use. In the past, you may have found it challenging to reuse some of these libraries if they didn’t match the programming language your app was implemented in. For example, you built a great .NET app, but couldn’t use a library written in C++ without going through painful interop hoops like PInvoke.

Windows Runtime bridges the language gap in Windows 8, making it possible for a single Windows Runtime component library with a single code base to reach a broader set of developers irrespective of the component’s language or your app’s primary programming language.

You can now create a single Windows Runtime-exposed XAML library of custom controls that both C++ and C# app developers can consume. And you can use various data storage Windows Runtime libraries shared out by developers in your XAML or HTML based Metro style apps. All of these scenarios are possible without the burden of writing any interop code.

We think Windows Runtime will be a boon to the libraries that developers create and share broadly for the community of Metro style app developers. Let’s now take a look at two concrete examples showing the basics of building a 3^rd party Windows Runtime component in C++/CX and C#.

Scenario 1: Enhancing your app with native audio

Say we are building a software synthesizer app using XAML backed by app logic written in C#. To add filter support to our music app, we would like to use XAudio to have direct control of audio buffers.

Adding the Windows Runtime component to our solution

Using Visual Studio, we add a new C++ Windows Runtime component project to our existing solution. This Windows Runtime component wraps the music processing functionality:

Figure 2: Adding a new C++ Windows Runtime Component

Visual Studio created a C++ project for us to expose APIs for which the implementation will be packaged in a DLL and the Windows Runtime metadata in a winmd file. Both are made available to our C# project.

Defining the class exposed to our XAML C# project

We use C++/CX to build the APIs that will be exposed to our C# project, but you also can use the Windows Runtime C++ Template Library (WRL). We start by defining a fairly basic class to encapsulate the XAudio functionality:

XAudioWrapper.h

#pragma once

#include "mmreg.h"
#include 
#include 

namespace XAudioWrapper
{
    public ref class XAudio2SoundPlayer sealed
    {
    public:
        XAudio2SoundPlayer(uint32 sampleRate);
        virtual ~XAudio2SoundPlayer();

        void Initialize();

        bool   PlaySound(size_t index);
        bool   StopSound(size_t index);
        bool   IsSoundPlaying(size_t index);
        size_t GetSoundCount();

        void Suspend();
        void Resume();

    private:
        interface IXAudio2*                     m_audioEngine;
        interface IXAudio2MasteringVoice*       m_masteringVoice;
        std::vector>  m_soundList;
    };
}

You will first notice the usage of the public, ref and sealed keywords in the class declaration. For a class to be instantiated from another language such as JavaScript or C# in a Metro style app, the class must be declared as public ref class sealed.

The public functionality (methods, properties …) of the class are limited to C++ built-in types or Windows Runtime types. Those are the only types allowed for crossing the language boundary in Windows Runtime components. That being said, you can use the regular C++ library (i.e.: Standard Template Library collections) for the private data members of your class as shown in this code snippet. Those private data members don’t have to follow the rules associated with crossing the language boundary. The Visual Studio compiler emits error messages and provides guidance if you use unsupported constructs.

Implementing the class exposed in our Windows Runtime component

Now that we have defined the basic interface for our class, let’s take a look at some of the implemented methods:

XAudioWrapper.cpp

XAudio2SoundPlayer::XAudio2SoundPlayer(uint32 sampleRate) :
    m_soundList()
{
    // Create the XAudio2 engine
    UINT32 flags = 0;

    XAudio2Create(&m_audioEngine, flags);

    // Create the mastering voice
    m_audioEngine->CreateMasteringVoice(
        &m_masteringVoice,
        XAUDIO2_DEFAULT_CHANNELS,
        sampleRate
        );
}

void XAudio2SoundPlayer::Resume()
{
    m_audioEngine->StartEngine();
}

bool XAudio2SoundPlayer::PlaySound(size_t index)
{
    //
    // Setup buffer
    //
    XAUDIO2_BUFFER playBuffer = { 0 };
    std::shared_ptr soundData = m_soundList[index];
    playBuffer.AudioBytes = soundData->playData->Length;
    playBuffer.pAudioData = soundData->playData->Data;
    playBuffer.Flags = XAUDIO2_END_OF_STREAM;

    HRESULT hr = soundData->sourceVoice->Stop();
    if (SUCCEEDED(hr))
    {
        hr = soundData->sourceVoice->FlushSourceBuffers();
    }

    //
    // Submit the sound buffer and (re)start (ignore any 'stop' failures)
    //
    hr = soundData->sourceVoice->SubmitSourceBuffer(&playBuffer);
    if (SUCCEEDED(hr))
    {
        hr = soundData->sourceVoice->Start(0, XAUDIO2_COMMIT_NOW);
    }

    return SUCCEEDED(hr);
}

In this code snippet, we are just using the XAudio2 COM APIs available for Metro style app development to wire up our audio engine, play sound and resume the engine. Additionally, we can use C++ constructs and types beyond just the Windows Runtime types to implement the necessary functionality.

Adding and consuming the Windows Runtime component

After we define and implement our basic class, we use Visual Studio to add the XAudioWrapper Windows Runtime component to our C++ project from our C# project:

Figure 3: Adding the XAudioWrapper Windows Runtime Component to our music app

As a result, the class that we expose from our C++ project becomes available to our C# project:

MainPage.cs

using XAudioWrapper;

namespace BasicSoundApp
{    
    public sealed partial class MainPage : Page
    {
        XAudio2SoundPlayer _audioPlayer = new XAudio2SoundPlayer(48000);
        public MainPage()
        {
            this.InitializeComponent();
        }

        protected override void OnNavigatedTo(NavigationEventArgs e)
        {
            _audioPlayer.Initialize();
        }

        private void Button_Click_1(object sender, RoutedEventArgs e)
        {
            _audioPlayer.PlaySound(0);
        }
    }
}

As shown in the code snippet, we can interact with our XAudio wrapper from C# just as if it were a regular .NET component. We reference its namespace, instantiate the component and start invoking the various methods it exposes. All of this without requiring any DllImports to call into the native code!

Scenario 2: Using built-in APIs to open a zip file from your app

Say we are also building a file viewer app using HTML and want to add functionality to allow users of this app to pick zip files. We want to use the APIs already built-into Windows and exposed in the .NET platform for handling zip files.

Adding the Windows Runtime component to our solution

This is the same step as we have described for our music app, but we now pick the C# Windows Runtime component to wrap the zip processing functionality:

Figure 4: Adding a new C# Windows Runtime Component

Visual Studio has created a C# project for us to expose the APIs for which both the implementation and Windows Runtime metadata are packaged in a .winmd file and made available to our web project.

Implementing the class exposed in our Windows Runtime component

We use C# to build the APIs that will be exposed to our web project, but you can also use Visual Basic. We start by defining a simple C# class to encapsulate the zip functionality:

ZipWrapper.cs

using System;
using System.Collections.Generic;
using System.IO;
using System.IO.Compression;
using System.Runtime.InteropServices.WindowsRuntime;
using System.Threading.Tasks;
using Windows.Foundation;
using Windows.Storage;

public sealed class ZipWrapper
{
public static IAsyncOperationWithProgress, double> EnumerateZipFileAsync(StorageFile file)
        {
            return AsyncInfo.Run(async delegate(
                System.Threading.CancellationToken cancellationToken, IProgress<double> progress)
            {
                IList fileList = new List();
                progress.Report(0);

                using (var stream = await file.OpenStreamForReadAsync())
                {
                    using (var archive = new ZipArchive(stream))
                    {
                        for (int i = 0; i < archive.Entries.Count; i++)
                        {
                            // add code for processing/analysis on the file 
 // content here

                            // add to our list and report progress
                            fileList.Add(archive.Entries[i].FullName);
                            double progressUpdate = ((i + 1) / ((double)archive.Entries.Count)) * 100; // percentage
                            progress.Report(progressUpdate);
                        }
                    }
                }

                progress.Report(100.0);
                return fileList;
            });
        }
}

This class is public and sealed. Similarly to building C++ Windows Runtime components, this is necessary for other languages to instantiate the class. The static method exposed in the class uses a mixture of Windows Runtime types (such as StorageFile) and as .NET types (such as IList) in the method signature. The rule of thumb is to use Windows Runtime types for defining the public fields, parameters and return types that will be exposed to the other languages. That being said, you can use certain .NET fundamental types (i.e.: DateTimeOffset and Uri) and primitives (i.e.: IList) as is.

You will also notice that the method above leverages the Windows Runtime infrastructure for async and progress support that you can (and should) use when defining your Windows Runtime components. As far as the implementation for the Windows Runtime component or any private functionality in the class, you are not limited to only using Windows Runtime types and APIs; you are free to use any of the .NET API surface exposed for Metro app development as shown in the code snippet ZipArchive APIs.

Adding and consuming the Windows Runtime component

Now that we have implemented our zip tool wrapper, we use Visual Studio to add a reference to our C# project from our JavaScript project:

Figure 5: Adding the ZipUtil Windows Runtime component to our file viewer app

As a result, the class that we have exposed from our C# project becomes available to our web project:

program.js

function pickSinglePhoto() {

    // Create the picker object for picking zip files
    var openPicker = new Windows.Storage.Pickers.FileOpenPicker();
    openPicker.viewMode = Windows.Storage.Pickers.PickerViewMode.thumbnail;
    openPicker.suggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.picturesLibrary;
    openPicker.fileTypeFilter.replaceAll([".zip"]);

    // Open the picker for the user to pick a file 
    openPicker.pickSingleFileAsync().then(function (file) {
        if (file) {
            ZipUtil.ZipWrapper.enumerateZipFileAsync(file).then(
        function (fileList) {
            for (var i = 0; i < fileList.length; i++)
                document.getElementById('output').innerHTML += " " + fileList[i];
        },
        function (prog) {
            document.getElementById('zipProgress').value = prog;
        }
    );
        } else {
            document.getElementById('output').innerHTML = "an error occurred";
        }
    });
};

As you can see, we can interact with our zip tool wrapper from JavaScript just as if it were a regular JavaScript object. We can call into the static method exposed in our Windows Runtime component, and we can do so using JavaScript’s async language constructs such as .then().

General guidance

Not every API you write for your Metro style app should be exposed as a 3^rd party Windows Runtime component. In general, use Windows Runtime types when you are communicating between programming languages and use types and constructs that are built into the language that you are using for functionality that is not publicly exposed via a Windows Runtime component. Additionally, there are various language-specific features and rules around crossing the language boundary that you need to take into consideration when building your Windows Runtime component. This includes delegates and events, asynchronous operations, method overloading, handling specific data types such as collections, exception handling and debugging tips. You can dive into those topics further by visiting the section on building Windows Runtime components for your development language.

In closing

With Windows Runtime components, you can now mix programming languages and API technologies to build the apps you envision. Windows 8 is about no compromises. There are even no compromises during development, allowing you to mix and match the programming languages that best fit your scenario. We hope this allows you to spend more time thinking about innovation and less time being forced to learn a completely new programming language.

Happy app building!

– Ines Khelifi, Program Manager, Windows

References

In this post, we have merely scratched the surface of what’s possible with building Windows Runtime components. Here are additional resources to help you dive into this further for your app development:

Link	Types
Creating Windows Runtime Components	Doc
Creating Windows Runtime Components in C++	Doc
Creating Windows Runtime Components in C# and Visual Basic	Doc
XAudio2 audio file playback sample	Sample
XInput and JavaScript controller sketch sample	Sample
Developing Bing Maps Trip Optimizer, a Metro style app in JavaScript and C++	Conceptual documentation

Windows 8 app developer blog

Using HTML controls to create great Metro style apps

admin — Fri, 27 Jul 2012 22:23:56 +0000

With Windows 8, you can use HTML to build Metro style apps. What you might not realize is that by using HTML controls directly, you automatically get the new Windows 8 experience. We have done work in HTML so that you can build industrial strength apps that have touch capability while still maintaining the great flexibility of using HTML. We want you to quickly and efficiently build apps that shine.

In particular, we want you to continue to take advantage of common HTML controls like

Testing Metro style apps in Windows 8

admin — Fri, 13 Jul 2012 07:24:58 +0000

In the world of Metro style apps, your apps are the focus of the whole experience. For this experience to be delightful to your users, you want to ensure that your apps are well tested and represent a high level of quality. Producing a Metro style app involves four main stages: design, development, testing and finally distribution.

A number of previous blog posts focus on the design and development aspects of Metro style apps. In this post, we cover a few high level verification areas related to testing your apps.

The term testing is overloaded, meaning different things to different people, especially in the context of the software development lifecycle. It also involves a diverse set of activities that can be executed at different stages of software development. These activities include unit testing, functional testing, usability testing, scenario testing, and a few others. Any one of these activities represents only one piece of the testing puzzle and doesn’t cover all the necessary verification that you need to put an app through to make sure it is of high quality. In this post, we don’t distinguish between the specific types of verification. Instead, we provide a broad set of high-level verification areas and exercises that will help you ensure that your app represents a high level of quality. In addition to these verification areas, you can also verify the functionality of your app during development using Visual Studio for debugging and testing, and the Visual Studio Unit Test Tools. In the coming weeks, we plan to do more blog posts that will dive deeper into specifics of testing Metro style apps.

As we saw in the “managing app lifecycle” blog post, a Metro style app can transition between various runtime states. Based on this app lifecycle, we like to think of these key areas of verification:

Activated: verify the app through several activation paths
Running: verify the app at runtime
Suspended: verify the app suspends correctly
Resumed: verify the app resumes correctly
Terminated: verify the app terminates
Not running: verify behavior when your app is not running

Let’s dive deeper into the key verification areas during each of these areas.

Verify activation behavior of the app

To test activation we need to go through the various contexts in which users can launch your app. It is important to verify each activation scenario your app supports. Here are the common contexts in which users can activate your app:

Tile: The launch of your app through the tile is very likely the first interaction that users have with your app. Verify that your app follows the appropriate app launch design pattern.
Toast notifications: If your app supports toast notifications, verify that your app activates functions as expected when you click an incoming notification that your app is meant to handle.
Search: If your app supports Search, verify that your app activates and that you can complete a search in your app. If your app supports displaying search suggestions, verify that it functions as expected.
Share target: If your app supports being a Share target, verify that your app activates and posts the content shared from another app for the supported types of content.
Protocol: If your app registers for a protocol, verify that you can activate your app by launching various types of URLs corresponding to this protocol.
File association: If your app registers to handle a file type, verify that you can activate your app by launching files of the corresponding file type.
File pickers/contact picker: If your app is registered as a file open/save picker or as a contact picker, verify that you can activate your app in those contexts.

Verify runtime behavior of the app

Verifying the functionality of a Metro style app is a combination of verifying the common characteristics that apply to all apps, and verifying the app specific functionality. In addition to the key verification scenarios we talk about in a moment, you must also verify the app-specific functionality. This involves understanding the key scenarios targeted by your app and verifying that these scenarios work as expected.

Tiles

The app tile is a core part of your app, and possibly the most frequently seen part of your app. The following aspects of your tile behavior are important to verify:

If your app supports live tiles, verify its behavior while your app is running. Verify that the tile updates are consistent with the state displayed within your app. For example, a photo app’s tile could show photos from the most recently added album.
If your app supports secondary tiles, verify that they display the expected info. For example, a weather app can support pinning specific cities as secondary tiles. You need to also verify that clicking the secondary tile results in the app launching and taking you to the expected context within the app.
If your app supports notification badges in the tiles, verify that any badge update shows as expected, and that it is consistent with the corresponding state displayed within your app. For example, a badge related to the count of unread mail in a mail app must get cleared when the app runs to let the user know that they no longer have any unread mail.

Toast notifications

If your app supports toast notifications, verify that the toasts trigger and display correctly. Also verify that clicking the toast notification results in the app launching and taking you to the expected context within the app.

Contracts and extensions

We looked at a few contracts earlier as part of verifying the activation behavior of your app. Let’s look at a few additional areas related to verifying contracts at runtime:

Share source: If your app supports being a sharing source, verify that you can use the Share charm to share content from your app (for the supported types of content) to other target apps on the machine.
Play to: If your app supports the Play To contract, verify that you can use the Devices charm to play media from your app on a remote device.
Settings: If your app supports the Settings contract, verify that you can view and modify your app specific settings. Also, verify that the app persists the modified settings across termination/re-launch.

Windows App Certification Kit

The Windows App Certification Kit allows you to verify that your app meets the Windows Store submission criteria. This kit includes automated tests to verify the usage of supported APIs, testing for crashes/hangs, verification of the application manifest, and launch/suspension time performance. We recommend that you run this kit early and often. We’ve experienced a number of situations where the app didn’t make it to the Store by the deadline because the app owner waited till the last minute to run the certification kit against the app. If you run the kit early and often you can discover and fix any app issues quickly and submit your app to the Store. The Windows App Certification Kit documentation has details on the types of tests the kit does and additional tips on the configurations under which to run the kit.

Snapped and fill views

Users can run your Metro style app under various view states. In addition to the full screen view, users can use your app in the snapped and fill views. It is important to verify that your app handles these view state transitions correctly.

Verify that your app supports the snapped and fill views. Verify that your app maintains the context when it gets snapped or unsnapped.
Verify that snapping and unsnapping doesn’t destroy the user’s work or state.
Verify that the user can interact with your app while it is snapped.

Rotation

Users can rotate and flip their tablets and monitors. If your app supports the portrait orientation in addition to the landscape orientation, verify that your app can handle the orientation changes. You can use the Visual Studio simulator for Metro style apps to test your app in both modes. So, you don’t necessarily need a tablet device to test this scenario.

Touch

Windows 8 enables apps to have a number of new touch experiences. You can use the Visual Studio simulator for Metro style apps to test the touch interactions that your app supports. So, you don’t necessarily need dedicated touch hardware to verify these interactions.

Verify that all the controls used in the app are standard basic controls that are touch-friendly. Depending on your programming language, use either the XAML controls or the JavaScript controls.
Verify that your Metro style app follows the standard Touch interaction design.
Verify that your app provides visual feedback for the user actions.
Verify that your app avoids dragging actions from the edges of the screen to avoid conflicting with the Windows OS gestures.
If the app supports any text input controls, verify that the soft keyboard works as expected. Verify that the area with the keyboard focus shifts up into view when the soft keyboard is displayed.

Playing audio

Windows 8 supports a model for Metro style apps to play audio, including playing in the background. Here’s what we recommend for testing audio:

If your app plays audio, verify that it handles the sound level notifications appropriately when a user switches between your app and other types of audio apps. For example, if your app is a game, you might want to pause the game when it receives a “Muted” notification. For details, see Audio playback in a Metro style app.
If your app supports playing audio in the background, verify that your app continues playing audio in the background without getting suspended. Verify that your app continues to play audio when the user locks the machine.
If your app registers for the transport controls to control playback of music, verify that it works as expected.

Different screen sizes

Windows 8 runs on a variety of screen sizes, from a small screen on a tablet, to a medium laptop screen all the way up to a large desktop screen. Therefore it is important to test your app on different screen sizes. You can use the Visual Studio simulator for Metro style apps to test your app on a variety of screen sizes and pixel densities.

On resolutions between 1024×768 and 2560×1440, verify that your app’s layouts are not truncated and that content appears where expected.
Verify that images are crisp when scaled to pixel density.

Data roaming

Windows 8 enables roaming settings across multiple PCs, including the roaming state persisted by your Metro style apps. To test this:

Verify that the app context roams as expected across multiple PCs. For example, this could be the last completed level in a game, the most recently read page in a book, or the last watched position of a video in your app. Verify that the context the app set on one PC is reflected when you use the app on another PC.
Verify that the applicable user preferences for your app roam as expected across multiple PCs. For example, this could be the user’s unit preference for the temperature in a Weather app. In this example, verify that the user’s unit preference set on one PC is reflected when you use the app on another PC.

Devices and sensors

If your Metro style app supports devices or sensors, you need to verify these areas.

If your app supports tailoring the view based on the geolocation, verify that it works as expected. You can use the Visual Studio simulator for Metro style apps to test this as it supports an option to set the current location.
If your app supports responding to user-initiated device connections like a camera or USB drive, verify that your app correctly performs the action corresponding to that event. For example, this could be verifying that users can use your app to copy all the images from a camera. Also, verify that your app handles device disconnects gracefully. For example, this involves verifying how your app behaves if the user disconnects the camera while your app is copying images from the camera.
Users can dock certain types of machines or devices to a docking station. Verify that your app behaves as expected both when the machine is docked and undocked.

Performance

Users expect apps to respond immediately to inputs. So it is critical to verify the performance characteristics of your app. As Windows 8 can run on a variety of hardware, consider installing your app on a low end machine to measure its performance characteristics. The post How to improve performance in your Metro style app has details on how to prepare a machine for measurements.

Responsiveness

For the key scenarios supported by your app, understand the expected interaction classes and verify that the app meets the goals for that particular interaction class.
Verify that your app remains responsive to the user.
Verify that your app provides feedback to the user during any long-running activities, such as an asynchronous network call.

Being a good citizen in the app ecosystem

As the post How to improve performance in your Metro style app explains, it is important to verify that your app is a good citizen in the app ecosystem. This involves contributing positively to the user’s overall experience (whether your app is in the foreground or not). In addition to verifying the areas that post lists, here are a few additional areas to verify:

When in idle state, if you expect your app to not be using CPU, verify that the app doesn’t consume any CPU.
Users could be on various types of networks including metered networks. If your app connects to the Internet, verify that it adapts its behavior for metered networks when sending and receiving data.

Error handling

As the saying goes, anything that can go wrong, will . Seriously, when a condition your app depends on changes, it can impact your app’s behavior. For example, your app needs to handle network connectivity not being available and decide on how to behave in this situation.

Verify that your app handles error conditions appropriately. As in our example, network and/or device connectivity is a great way to trigger error paths in your app. Verify that your app follows the guidelines for managing connection state changes.
Verify that the error handling is not intrusive and that your app displays only the critical errors to the user.
Verify that your app provides actionable error messages to the user. See the guidelines for actionable error messages.

Reliability

Users expect apps to work reliably and consistently. It is important to verify that your app is highly reliable.

Verify that your app runs reliably across varied conditions and that it doesn’t crash because of unhandled exceptions.
Verify that your app doesn’t leak memory or any other resources. To detect memory leaks in a Metro style app, you can use the same methods that you normally use with other Windows applications.

After you publish your app to the Windows Store, you can use the Windows Store developer portal to review your app’s usage and quality data. For example, you can view the data about exceptions, crashes, and unresponsiveness issues that your users encountered. Consider using this data to fix the top crashes and hangs in your app.

Accessibility

Windows 8 is designed for a broad spectrum of people and is accessible to everyone regardless of their abilities. If your Metro style app meets a baseline of accessibility, it can contribute tremendously to improving the accessibility ecosystem. If your app supports accessibility, verify that it meets the criteria described in Testing your app for accessibility.

Globalization and localization

If your Metro style app is designed to be global, it can be localized for a variety of regions and markets. Metro style apps can use the configured language and display formats (date, time, currency, and numbers) to tailor their content. For example, if a user configures Japanese as the primary language on an English installation of Windows, and then launches a Metro style Stocks app, the app can display all the related news articles in Japanese and additionally show info about the stocks trading in the selected region (e.g. Tokyo Stock Exchange).

If your app is localized, verify that it works for different locales and display languages.

For the languages your app supports, use the Language settings in the Control Panel to add each of the specific languages as a primary language, and verify that your app tailors the content appropriate for that language.
Verify that changing the language when your app is running or suspended works as expected.
For the languages your app supports, verify that the user interface strings appear as expected and don’t get truncated.
Verify that any text shown in the app’s images is in the selected display language.

Processor architectures

A Metro style app can be architecture-neutral or it could target a specific architecture.

If your app is architecture neutral, it can be tested on any chosen architecture.

If it is architecture specific, it needs to be tested on all the supported architectures.

If your app is targeted specifically for Windows RT (ARM), verify its functionality on a Windows RT PC. You can find additional info on developing and testing on ARM in the blog post What you need to know about developing for Windows on ARM (WOA).
If your app targets x86 and doesn’t separately provide a x64 package, verify that your app functions correctly on both x86 and x64 systems. This is because x86 apps can run on x86 (32-bit Windows) or x64 (64-bit Windows) systems. Windows allows apps targeted for x86 to run on x64 systems.

Verify suspension behavior of the app

Windows suspends your app when it is not in the foreground. In this way, Windows gives the foreground app better use of system resources and ensures that apps in the background can’t drain the user’s battery. For example, during suspension, a Stocks app can persist info about the last stock that the user was viewing and the time range for a stock chart.

Verify that your app reduces memory usage while it is in a suspended state. To view the suspension status in Task Manager, click More details in Task Manager to see all available options, and then click View > Status values > Show suspended status.
If your app supports uploading or downloading of data in the background, verify that data continues to be transferred even when the app is suspended.

You can use Visual Studio to simulate the suspension/resumption of an app. To do this, select View > Toolbars > Debug Location.

Verify resumption behavior of the app

When your app comes back to the foreground, Windows resumes your app, and it continues from the state that it was in when Windows suspended it. It is important to verify that your app resumes gracefully.

Your app could be resuming after being suspended for a long time. During this time, the displayed content and any network connections could have become stale. Verify that your app resumes and that it provides a visual indication about the state of its content.
After your app resumes, verify that it can refresh its content and can reconnect to any network resources, as required. For example, after a Stocks app resumes, it can provide a visual indication of the time the data was last updated, and then go on to update the cached stock data so that the user sees the latest stock prices.

Verify termination behavior of the app

Windows can terminate a suspended app when the system is running low on resources. Additionally, your app can also get terminated when the user manually closes it, or signs out of Windows. Depending on how the app gets terminated, it is important to verify that your app restores the right app data when it is launched after a termination.

When launching an app after Windows terminated it, verify that your app restores the context and state as it was before getting suspended and/or terminated. For example, this could be the last viewed stock info and the selected duration of the chart that was saved when the app was suspended.
When launching an app after manually closing it (by swiping from the top to the bottom of the screen), verify that your app starts with the default data.
When launching an app after an unexpected termination such as a crash, verify that your app is still able to launch and that it loads the default data. To cause an unexpected termination for your app, in the Task Manager right click your app > Go to details > right click > end task.

For more details, see Managing app lifecycle so your apps feel "always alive".

Verify app behavior when not running

A Metro style app can surface info to the user even when it is not running. So, it is important to verify that the below scenarios work as expected.

Tiles

Here are the main areas to verify when your app is not running:

Verify that the default tile displays as expected. Verify that the tile size, usage, and notifications follow the guidelines in Guidelines and checklist for tiles.
If your app supports scheduled notifications or periodic/push notifications from the cloud, verify that its tile gets updated even when your app is not running. Examples of this are a weather app that periodically updates its tile with the current temperature, and a sports app that updates its tile with the latest scores pushed from the cloud.
A live tile is one of the best ways to entice users back to your app. Validate that the info in your live tile shows the best of what’s going on inside of your app.

Toast notifications

If your app supports toast notifications even when it’s not running (using scheduled notifications or push notifications), verify that the toast notifications trigger and display as expected even when the app is not running. Examples of this are a calendar app that schedules meeting reminders as toast notifications and a news app that displays breaking news as toast notifications.

Background tasks

If your app supports background tasks, verify the corresponding behavior.

If your app is capable of showing lock screen notifications (e.g. a mail app or a VoIP app that always has to stay up to date), verify that the info surfaced by your app stays up to date even when the PC is not used.
If your app can perform background tasks on certain triggers (e.g. a Photos app that processes pictures from the Photos library when on AC power), verify that your app performs that task correctly when the appropriate conditions are met.

For details, see the Background tasks blog post.

Conclusion

Testing your Metro style app and verifying its quality is a critical step to ensure that your users have a great experience with your app. In this blog post, we covered a few key areas related to verifying your Metro style apps including verifying the behavior of your app when it is launched in different contexts, verifying the functionality of your app, and verifying the behavior of your app as it transitions through various states of the Metro style app lifecycle.

In the real world, a user could combine many interactions that impact your app. For example, a user could, in quick succession, snap your app to the Fill view, rotate the device, and adjust the screen resolution. So, in addition to testing the app behavior for a specific scenario in isolation, bring out your creative juices and exercise your app to account for such complex interactions.

We hope you find this to be a good starting point to think about how to verify the functionality of your apps and have them represent a high level of quality. In the coming weeks, we plan to do more blog posts that will dive deeper into specific topics pertaining to testing Metro style apps.

Thanks!

– J. Kalyana Sundaram, Senior SDET, Windows

– Ashwin Needamangala, Principal Test Lead, Windows

– Mete Goktepe, Principal Test Manager, Windows

Special thanks to Tom White, Patrik Lundberg, Tom Baxter, Vik Kumar, Rui Sun and Yves Neyrand for their help and contributions to this post.

Windows 8 app developer blog

Creating Metro style apps that stand out from the crowd

admin — Thu, 12 Jul 2012 04:24:44 +0000

When you submit your app into the Store, there will no doubt be other apps in your category that will compete for people’s attention. Being able to crisply showcase the differentiation points in your offerings and staying focused on delivering the core scenarios that you are best at are crucial to a successful Metro style app that will stand out from the crowd.

Windows 8 provides a set of design patterns, common controls, and built-in platform functionalities such as contracts that can help you focus on what you are best at. For example, just to name a few: the app bar is a common control that helps people focus on your content and minimize distractions; the touch pattern prescribes a set of gestures that are used consistently in platform controls, such as swiping from the edge to bring up the app bar, so that people can focus on confidently use your app without having to learn new interfaces; the Share contract is the glue that lets two apps work together so that users can accomplish more with your content.

This post is a little different from some of the other posts – rather than talking about coding patterns, we talk about design patterns that you can use in your planning process. I introduce an example app, Food with friends, and start by answering the question that is key to standing out from the crowd: “What is my app best at in its category?”. Then I illustrate some practical steps to designing the app’s structure and layout to highlight the core scenarios and differentiation points that it is best at. This is the first in a series of occasional posts that will come over the next few months. The later posts will continue to use this app as an example and walk through ways that you can take advantage of these various aspects of the Windows 8 platform to create experiences that feel immersive, crafted, fast, and fluid.

Let’s get started!

Example: Food with friends

Say we are building an app that helps people find restaurants. Let’s look at the design process for this app.

1. Identifying the differentiation points

We will start by identifying a focus that will allow to differentiate ourselves from other competitors in the restaurant and dining category:

My app is the best in its category at helping users and their friends find a restaurant to eat at tonight.

The unique point of view of this app is on helping users and their friends and dining tonight. This app will revolve around getting friends to agree on a place to eat, and will focus on bubbling up friends’ preferences so a user can take them into account when making decisions. This emphasis makes our app stand out from other generic apps in the same category that may simply be providing local restaurant listings.

This “best-at” statement describes the reasons why user will want to buy this app and not a competitor’s in the same category. We will be referring back to it many times as we make design trade-offs and decide on which feature set and platform functionalities to use.

Given this, let’s call this app Food with friends.

2. Picking the right scenarios

Next, let’s identify the core scenarios our app will focus on based on our best-at statement. In the process of brainstorming and selecting scenarios, there may be a great number of interesting ones that we could support (such as seeing nutritional value of dishes). But to actually deliver the unique, differentiated, best-in-class experience that our best-at statement promises, we must say no to them if they don’t tie back to our vision. Based on that, here are the core scenarios that this app will be great at:

Find restaurants that I want to eat at
Find restaurants that my friends want to eat at
Make dinner plans for tonight with friends

We want to start by thinking about scenarios that describe why people want to use the app, before we start thinking about features, which are how they will achieve those goals. Each of our scenarios will encompass a number of features. When we know what the core scenarios are, we can then think about features that will enable those scenarios. We will get to more details on feature selection and design in the next post, but here are some examples of possible features:

Find restaurants that I want to eat at:

Browse restaurants on a map or in a list
Search by name or keyword
Filter/Sort by category, price and rating
Add/remove restaurants to/from wishlist

3. Creating the landing experience

The landing page is the key to any Metro style app. It is your chance to tell your user what your app is best at. When users open your app you want them to immediately understand what your app’s core scenarios are and how they deliver unique values. A good landing page motivates users to open the app by always providing new and up to date content, and convinces them to stick around and spend more time in the app. It is like a hub, the center of interest and shows the best of the app.

Designing a great hub is about creating a layout that optimizes for bringing content and functionality to people in an easy to explore way. Typical navigation in apps or on the web involves showing a default section of an app, and then relies on users choosing to go to a new section from a navigation bar or table of contents. The trouble with this pattern is that it doesn’t encourage exploration. In order for people to decide to click a tab and navigate to a new section, they need to believe that there is something in there that would be interesting or useful to them. If there are no interesting sections, they’ll switch to another app. For example, this newsreader app uses a tab-based design where people land in a single section, but then have to consciously make a decision to navigate to other sections of the app just based on the name. You cannot tell if any of those 4 other sections are interesting until you switch to it:

Instead, convert this to a hub and simply add panning, which requires no hard decision from users at all, and they will see why the content or functionality of the app is interesting to them.

By laying out the app so it’s easy to explore, we show users why they should stick around. We show them the full breadth of what our app is best at.

So with that in mind, let’s start with a basic hub layout using the Visual Studio Grid project template (XAML, HTML). Its landing page (the groupedItemsPage) has a number of sections and selected items from each one:

We want this page to really represent the best-at statement of: My app is the best in its category at helping users and their friends find a restaurant to eat at tonight. The first step is to make each section of our hub represent one of our three core scenarios. Each core scenario must be represented (though there could be multiple sections that tie back to a scenario):

1. Tonight	Focuses on making dinner plans for tonight with friends
2. Friends’ wishlists	Focuses on finding restaurants that my friends want to eat at
3. My wishlist	Focuses on finding restaurants that I want to eat at
4. All Restaurants	Also focuses on finding restaurants that I want to eat at

The order of the sections is strategic. The reason tonight is first is because it is the most relevant section to what is going on right now and so it is likely to change every time you open the app. Info about tonight is also a great candidate for live tile content because it’s fresh, personal and relevant. This lineup means that if people see what is happening tonight on the app’s live tile on the Start screen, they can open the app and see the content they just saw on the live tile right on the hub page. Your app should reward users for opening the app with info that’s new and most important to them. For more on live tiles take a look at Kevin Michael Woley’s Creating a great tile experience post.

Next we put Friends’ wishlists, and then My wishlist – these are in that order for two reasons:

The focus of Food with friends is on my friends – that’s the differentiator, and is what Food with friends does that nobody else does in quite the same way.
Like the Tonight section, others will update their wishlists while a user is away from the app and so it can change often. It contains info user doesn’t know, while they are more familiar with their own wishlists and so it is less critical to explore it.

We put All restaurants at the end. We expect users to go to this section only when they want to manage their wishlist, but according to our best at statement, most of the time users will be making decisions about where to go tonight which means most of the time they will be looking at the wishlists that are already there and at the suggestions for tonight. Having it at the end also provides a nice benefit that the section can expand as long as you like, without pushing off other content. You may be concerned that All restaurants is so far over, but don’t be. Quickly jumping through a list is what Semantic Zoom is for.

4. Designing the sections

A key to designing a section to optimize it for its corresponding scenario. It doesn’t need to be a uniform grid of tiles across the whole hub! This is where we can get creative, demonstrate how our app is different from others and bring forward what our app is best at. We also don’t have to show all items in a given section on the landing page because that may be overwhelming. Instead we may want to only bubble up a curated set of items that are the most relevant and up-to-date. For example, we show only the top friends under Friends’ wishlist, and the most recently added restaurants under My Wishlist.

For this app, the first section, Tonight, is all about deciding with your friends where to eat tonight. Because this requires collaboration between your friends and you, this is best as a discussion:

My friend’s wishlist is all about my friends and what they want, so in that section, let’s really make it about the people!

For my wishlist, it’s about the restaurants that I’m most interested in going to, so we bring the restaurant forward:

And lastly, All restaurants is about navigating the giant collection of restaurants that is out there, so let’s present some of the most popular ones that users might be interested in, and then present categories for easy browsing. With all these parts in place, you can now see how the app’s hub landing page now looks:

A crucial part to delivering a differentiated experience is expressing your product’s brand. This is a topic that deserves its own post, so stay tuned for a deeper dive into layout and visual design tips and techniques that will help your brand’s personality shine through while still maintaining a look and feel consistent with the platform it is created for. For now, let’s take a look at a simple example:

5. Laying out the rest of your app

Now that we have our landing page, it is really easy to lay out the rest of the app.

We know that not all of the sections in the hub were exhaustive, so we need pages entirely dedicated to showing the full set of content for each section. The groupDetailPage in the Visual Studio Grid template is designed for this purpose. We tailor the layout of the ListView on that page to best suit the content type.

My friend’s wishlist:

My wishlist:

All restaurants:

We also know that there are two core entities reflected on the hub: restaurants and people. That means we need two variants of the item detail page (itemDetailPage in the Grid project template) where users can see info on an item when they tap/click it:

When designing each page, it is just as critical to continue to think about what each page is trying to be best at, and how it contributes to helping your app deliver on its “best at” statement.

6. Navigating the UI

Now that we have the various pages, all we need to do is provide the user a way to move between them. Navigating the UI is quite unlikely the thing that any app is designed to be best at. We can apply existing navigation patterns that users already know so they can quickly get to our app’s content and functionality. In this example, we use the Grid project template, which follows the hierarchical system pattern. For example, tapping a tile takes you to the item’s detail page. Tapping a section header in the hub takes you to that section. Tapping back takes you to where you just came from (not up). Much of this is built into the Grid project template. In a future post, we will go into more depth on the implementation and tips for building more advanced in-app navigation.

Summary

Figuring out what you are best in its category at is the first and most important step to creating great Metro style app that will stand out from the crowd. As we have seen, identifying and focusing on the differentiation points influences many foundational decisions that you will make around your content structure, landing experience, page layout, and navigation. In future posts, we will continue to build on this and show how you can use the Windows 8 platform to make your app the best in its category. To review some of the resources that are mentioned in this post, take a look at the content on http://design.windows.com.

– Bonny Lau, Senior Program Manager, Windows

Windows 8 app developer blog

Readying Metro style apps for launch

admin — Wed, 04 Jul 2012 11:19:41 +0000

We know many folks are looking forward to RTM. Developers currently working on apps in the Store are especially excited. We have hundreds of apps in the Windows Store now and many more on the way. There’s a broad set of developers around the world that we have been working closely with since the first Developer Preview. The WinRT platform is evolving rapidly during development based on feedback, and we have the dual task of keeping the Store up and running so we can supply apps to the millions of Preview users, while also getting ready for the next build. It means that if we change or add APIs or improve the tools, the apps will change and require an updated OS to test and verify the app. That’s why we have been providing updated builds to developers who have or are committed to having apps in the Store through strong partnerships.

This post explains the work we’ve been doing since September to keep developers updated with APIs and tools so that apps can stay up to date. We’re doing this even after the Release Preview, just to make sure new apps are ready to go once we get to broad availability. This post was authored by Dennis Flanagan, who leads our ecosystem outreach team. –Steven

As we approach the release of Windows 8, the catalog of Metro style apps continues to grow. To date, people have experienced apps that Microsoft has included with the downloaded build, and those that are offered in the Store in both the Consumer Preview and Release Preview timeframe. Many of those apps are great examples of immersive, touch-first Metro style experiences. However, like the Windows releases they run on, these apps are preview versions of the apps to come. The final versions of all Metro style apps will be available when Windows 8 becomes generally available.

Last year, we began working closely with the developer community by releasing early versions of the Windows 8 platform and tools. We decided to engage developers earlier in the engineering process so we could help them build skills in Metro style app development and give them the opportunity to influence the platform through feedback. Since September of 2011 we have released 8 developer preview versions. Some of these versions have been available to a limited developer audience. Some have been distributed broadly. All of these releases had similar goals:

Deliver new capabilities and APIs
Update tools to simplify Metro style app development
Enhance performance and reliability
Respond to developer feedback

We released our first Developer Preview version at the //build conference in Anaheim. This version introduced developers to the Windows 8 platform, tools and programming models. The WinRT platform included new APIs, and we used the conference to present literally hundreds of technical sessions and samples to give developers a basic understanding of the platform. . Many developers got right to work building Metro style apps, produced some impressive early results, and provided us with useful feedback and recommendations about how to improve the platform and tools.

We made it clear that the first Developer Preview (“DP1″) was an early version of the code, and we had a lot of work to complete Windows 8. DP4 and DP5, released in January and February of this year, were targeted at developers who wanted to be the first to publish applications in the Windows Store. By the time we released the Consumer Preview in February of 2012, we had added almost a thousand new WinRT APIs, and had modified hundreds of other APIs based on developer feedback.

For a detailed description of the changes that happened between //build and Consumer Preview, check out these posts on our App Developer blog:

In April and May of this year, we released DP6 and DP7, which allowed developers to prepare their apps for the Release Preview. However, in close collaboration with the development community, we’ve continued to evolve the platform in response to their feedback. By the time we delivered the Release Preview, we had added 334 more APIs and continued to change existing APIs to address feedback.

One example of a change we made in Release Preview (RP) based on developer feedback is the HTML ListView control (in WinJS). This was an area where lots of developers had difficulties, so we overhauled it to make it easier to work with and to allow a much more extensive degree of performance tuning.

We also made lots of improvements to developer resources, such as templates in Visual Studio. We even added a new template that makes it easier for developers to start a new project and get a great app up and running in very little time.

Design tools were another focus area for improvements. Metro is a design-forward experience, which means the app’s user interface is one of the key ways developers get their apps noticed and differentiate them. We did a lot of work to make it as easy as possible for developers to integrate all the new Metro style design concepts into their apps.

For a complete overview of the changes between CP and RP, see What’s changed for app developers since the Consumer Preview.

Our next major milestone is the release to manufacturing (RTM). When the code reaches this milestone, the platform is complete for general availability (GA), and so we won’t have interim updates for developers.

When Developers get the RTM version, they will continue enhancing the features, capabilities and performance of their apps. Some of the apps you’ve already seen will look and perform differently when you download the final released version. There are also many more apps in development that haven’t been released to the Store yet. Many of those developers are waiting for RTM to put the finishing touches on their apps.

The release of Windows 8 will be a great milestone for app developers, but it is really just the beginning. A great benefit of the built-in Windows Store and update mechanism is that they provide developers with the opportunity to gain wide distribution for new apps and continuously improve apps that they’ve already released. As the app developer community evolves, we expect app developers to take advantage of this and provide regular updates to apps.

–Dennis

Building Windows 8

The Windows 8 Dev Center: Everything you need to design, build, and sell a Metro style app

admin — Sat, 09 Jun 2012 13:27:01 +0000

For Windows 8, we completely reimagined not just the platform, but also how we share app development info with you. Launched 9 months ago, the Windows Dev Center is the one place where you can find all the info and resources you need to get going. Whether you’re new to development, seeking inspiration for the next great app, or you’re simply stuck and need help, you can find it here.

We talked to many developers, and heard a lot about how difficult it could be to find the right info in the MSDN Library. The goal we set for Windows 8 developer content was to try to provide exactly the right content when you needed it, and not have too much info get in your way. To that end we focused on how to do things, instead of on why we built a given feature the way we did. You told us that when you start learning about a new scenario or feature, you want to try it out quickly and learn the details later. We also heard loud and clear that you want to get going quickly and not read a lot of docs. With the new Windows 8 Dev Center, you don’t have to track down docs, tools, samples, and other assets in various locations; it’s all in one place. We also improved search, so you can find what you need easier.

And, you don’t have to be a dev to find a lot of interesting info in the Dev Center. If you’re a creative professional or a design expert and don’t want to see anything other than design, we have “a center within a center” for you that contains just the design content. Just go directly to design.windows.com. We could have called it the Windows Design and Dev Center, but that’s just too long!

The structure and navigation

The Windows Dev Center is broken into 4 sections: Metro style apps, Internet Explorer, Desktop, and Hardware. You can access them all from dev.windows.com.

All these sections are structured similarly, with a nod toward the important Metro style design principle of content over chrome. In this post, we focus on the Metro style apps section only, because that’s what most readers of this blog are interested in. Here’s what it looks like:

You can easily navigate the center by using the links at the top of the page.

Home orients you to the site, and gives you a general idea of what content we have for you.
When the Store becomes available (soon!), you’ll use the Dashboard to sign up and become a Windows Store developer. After you sign up, you’ll also use this tab to upload your apps, access telemetry, and see how your apps are doing in different markets around the world.
Docs is your gateway to platform documentation, including general info, Quickstarts (hands-on content that gets you familiar with basics of a feature quickly), tutorials, and reference. Using the navigation pane on the left, you can jump to the appropriate topic immediately. If you want more info before you jump, the main pane contains more detail. We improved navigation both within an article, and from one topic to another. We added the “In this article” sidebar where you can see all the sections of the article and can jump directly to the section that interests you. In some articles we also list relevant APIs if appropriate.
Use Samples to find Metro style samples to play with. There are already over 550 samples (and growing!) available in multiple programming languages, and we invite you to upload your own samples to share with the community.
Downloads is where you find the tools like Visual Studio 2012 Express RC for Windows 8 and the SDK. Visual Studio 2012 Express now also includes Blend for Visual Studio to help you quickly create visually attractive, fun apps.
You can use Support to get technical help with your account, or request 1:1 help with your dashboard. We provide this dashboard help for free to anyone with a Microsoft developer account. For really complex problems that go beyond the free help, you can also buy help with your apps from our experts.
Finally, Community resources can link you with other developers. You can ask questions, help others with their technical issues, or read the latest news about Windows 8 Metro style app development.

Get started

If you want a quick orientation, the best place to go is Getting started with Metro style apps. Here you can learn what makes a Metro style app great, and follow introductory tutorials that give you a taste of Windows 8 development. The tutorials feature many code examples in all 4 supported programming models: HTML5 with JavaScript, XAML with C# or VB, XAML with native C++, plus DirectX with native C++. Reusing your existing skills and code assets is a core premise of Windows 8 development, and we go out of our way to fulfill that promise on the Dev Center.

Get the resources

Your fingers might be itching to start developing your app, but first you need the right tools. Go to the Dev Center to download the tools. Make sure you download Microsoft Visual Studio 11 Express for Windows 8, which includes Windows 8 SDK, Blend for Visual Studio, and project templates.

If you need help designing appealing Metro style apps, download our design assets. These are .psd files for controls, layouts, components, and project templates to help you lay out your UI.

You will find lots of other resources too, including the Multilingual App Toolkit for Visual Studio 11 Beta, which can help you create apps for the world markets. The best part is, all these downloads are free.

Samples

We are always asked for samples, and with a good reason. A sample can show you how someone else already solved the problem you are trying to solve, or you can start with a sample as a foundation for your own app. We now have over 550 official Microsoft samples, plus additional community samples, and the number is growing. Each tells you how to compile and run it, plus we give you any special instructions you need. Check them out in the samples gallery or download the sample app pack if you want all of them at once. Over a quarter million devs already have!

You can search for the samples you want by programming language (JavaScript, C++, C#, Visual Basic), by source (Microsoft or community), by technology (Metro style app, JavaScript, Windows Runtime, XAML, and so on), or by topic (User interface, Audio and video, Devices and sensors, and so on).

If you want to showcase your great ideas, post your own samples! You can also rate or comment on samples, give feedback, or ask questions.

Can’t find a sample you need? You can request one, or vote for samples that others requested so that we create the ones that people really want. Then check out the “Completed” tab to see the samples we created as a result of community demand.

From app conception to the Store

Now that you have all the tools, and have seen some samples, it’s time to start thinking about your apps. But what makes a Metro style app great? Info on the Dev Center can help you decide what kind of app to build, what kind of info it should include to appeal to the broadest possible audience, and how to present your app’s content in a compelling way. This info is laid out in the order we think you’ll need it.

Start with an idea

Not sure how to turn your idea into an app? Start with Planning Metro style apps and follow our step-by-step planning process. There’s a lot to think about, including not just what the app will do, but how to present it to the best advantage, how to make it appeal to a global audience, and how you can make money from your app.

Designing UX for apps

A hallmark of great apps is an outstanding user experience (UX). But making your app compelling and interesting can be intimidating. In Designing UX for apps, we provide design patterns for navigation, commanding, and touch interaction. We provide specific help for popular Windows Store categories, including games, entertainment, news, and productivity. You can also download design assets for Metro style apps so you don’t have to start from scratch. We also help you assess usability of your app, so you can be sure your customers find it intuitive and easy to use.

If you already have an app on a different platform and are wondering how to redesign it to follow Metro style app design, we provide case studies that show you how to convert a Website to a Metro style app, and how to convert an iPad app to a Metro style one. And to improve the visual appeal of your app, take a look at our animations design videos.

Developing apps

Now that you have your app concept firmly in mind, it’s time to start developing. You already know what language you will use to develop Metro style apps. We provide a language selector control at the top of many pages, so you can see JavaScript and HTML content only, or Visual Basic/C#/C++ and XAML content only. We’re continually adding to the content for each language, so check back soon if the content you’re looking for doesn’t appear yet.

When you want info about a specific feature, you can start with a Quickstart that introduces the feature by walking you through common use cases. These articles include a lot of code to help you get started quickly, thus the name Quickstart. We also provide roadmaps for each of the major development models to help you decide where might want to go next. In many cases we also include guidelines and checklists for using a feature, to help ensure your apps pass certification and you can submit it to the Windows Store. Finally, we have in-depth documentation for key features if you need more detail.

Many articles contain code snippets. We use them as illustrations to jumpstart your own development. But you can also easily run them in Visual Studio. Simply click Copy in the upper right corner of the snippet, and the code will be pasted onto your Clipboard. You can then paste it into your own code. (You can get the sample code this way too.) Always be careful to include appropriate error handling and data validation when copying/pasting code from an article in the Dev Center.

While building your app, you might also need access to complete reference material for the platform. For detailed API info, see API reference for Metro style apps.

Before you can submit your app to Windows Store, you must package it. The easiest way to do so is to use Visual Studio. See Packaging your app using Visual Studio for more detail.

To make sure your app runs great and is ready for the Store, you must debug and test it. We give you all the info about Debugging and testing Windows Metro style apps to get this done quickly.

Selling and managing your apps

After you develop your app, it’s time to share it with the world. We provide you with a great platform for sharing apps – the Windows Store. In the Dev Center, we guide you through the process of submitting your app for certification, and listing it in the Windows Store. If you aren’t sure how to advertise your app in the catalog, we provide you with tips on how to write descriptions that will tempt users to try your app. When you’re ready to submit your app to the Store, Selling apps takes you through the process. It also explains the different licensing models available and provides suggestions for when to use each. Finally, you’ll want to know how to price your app so that it’s competitive, and how to add in-app offers to sell additional features. Making money with your app explains all of this in detail.

You can sell your apps in multiple languages in markets around the world. Windows Store markets explains the details.

If you want to get deeper technical info

The content we looked at so far will help you get started developing a great app. But sometimes you need more detail. In Concepts and architecture, we explain technical details behind the Metro style app development platform and share advanced techniques for building apps. For a complete survey of how to build apps from end-to-end, you can find guidance in the End-to-end apps and games section.

Another good source of deep technical info is White papers for Metro style apps.

What to do when you’re stuck

If you get stuck and can’t find a solution to your problem, there are other devs in the community who may be able to help. Community resources includes forums and blogs. The forums are a great place to ask questions, bounce ideas off other developers, or provide support for others who need help. Many of the forum participants are members of our tech support team, so you can get accurate answers to your questions quickly.

The blogs, such as this one, are a great place to learn the latest news about Windows 8 development and to give us feedback. In addition to the Windows 8 app developer blog (this blog), we have the Windows Store developer blog where members of the Windows Web Services team talk about the business of the Store, and the Building Windows 8 blog, where you can find the inside scoop from Windows President Steven Sinofsky and the Windows engineering team.

You can also sign up here for a Windows Dev Camp, and attend at any of the locations around the world.

We speak your language

We realize that many people around the world are interested in Windows, and many of them don’t read English. We now support the content and the Store in 12 languages, and we plan to add the most important content in additional 12. We support the tools and the forums in 10 languages, and the blogs in 8.

Closing

As you can see, for Windows 8 we completely revamped the way we share info with you. We focused more on how you actually use the content, and reorganized the Dev Center to reflect this.

The Dev Center isn’t static, it’s a constantly evolving site. Our dedicated team of programmer writers and editors, have worked hard to craft reference docs and feature overviews you expect, but there’s far more to the site. The team is now focused on creating scenario oriented guidance that helps you better understand how various features work together to complete more complex tasks. We’re still working on this guidance, and we update the Dev Center frequently, so stay tuned for more.

We hope you find our content easier to use. We look forward to your feedback.

– Marzena Makuta, Senior Editor, Windows

Thanks to Keith Boyd for his contribution.

Windows 8 app developer blog

Delivering reliable and trustworthy Metro style apps

admin — Sun, 20 May 2012 05:25:14 +0000

As we developed the app model for Windows 8 and the new Metro style apps, a key architectural requirement has been to deliver apps to customers that can be used with confidence–confidence that apps will be well-behaved with respect to resources, that apps will not interfere with other apps, that apps use system resources with your permission, that apps can be installed and uninstalled with ease, and so on. These attributes require a robust platform and strong set of tools for developers. This is an effort that requires a fresh start and cannot be retrofitted on an existing system. Windows 8 is a fresh start in this regard. This post details some of the work we have done at the platform level to deliver reliable and trustworthy Metro style apps. This post is authored by John Hazen, a program manager on our Developer Experience team. –Steven

One of our core principles in the development of the Windows 8 Metro style app platform was to ensure that users would have confidence in their apps. This is a mission we’re in together; in this post, I explain our vision for app confidence and reliability and help you build confidence by design into your apps.

Let me start by explaining what we mean by confidence. Picture a customer browsing the Windows Store looking at a Metro style app; we want them to be thinking only about the app and whether or not it is right for them. We want them to assume—in fact be confident—that the app will behave the way they expect and thus will perform well on their system, will use only the data and information they authorize, and will harmoniously co-exist with their other applications.

Our goal with the platform is to help us all build great apps that embody this vision of confidence so that we get confidence by default. To that end we made investments throughout the system. Here’s how we picture it:

App Confidence: Windows 8 SDK for Metro style apps, Windows App Certification Kit, App Signatures,
App Container, Ratings and Reviews, Store Onboarding, Frictionless Install, Telemetry Feedback

This post covers these areas and towards the end goes into depth on our app capabilities. First, a quick overview:

Windows Store – For customers, it starts with the Store, their one-stop-shop for Metro style apps. To get into the Store your app is reviewed for both technical and policy compliance, including security checks. After it’s published to the Store, your app will be rated and reviewed by the community. Together, the onboarding process and community reviews help create an environment in which customers can try apps with confidence.
App install – Windows 8 handles all the details of deploying apps on your behalf so your customers don’t have to worry that installing, updating, or removing one app will adversely affect other apps.
SDK – The Windows 8 SDK for Metro style apps provides a well-defined set of APIs that help you build reliable apps that conform to the Store onboarding requirements and provide the best experiences for your customers.
App container and capabilities – Windows 8 provides a greater degree of separation between apps than was possible with traditional desktop apps, so you can build apps that interact with each other in more predictable ways, giving customers a more consistent experience.

We of course recognize that any onboarding process can be gamed, API sets can be abused, SDK limits cleverly avoided, and that app containers are not impenetrable. But we are confident that the investments we made in this new ecosystem will help you build apps that delight customers. This multi-dimensional approach is the most effective way to build customer confidence and we will improve each dimension over time as we learn from experience. Now let’s talk about confidence.

The Windows Store

Several folks on the team have shared quite a bit on the Windows Store Blog about the overall design and plan for the Store. If you have not had a chance yet, read about the Store, because it plays a central role in helping you connect with your customers. Let’s look at a few ways in which the Store helps build confidence in the app ecosystem.

First, the Store onboarding process establishes a consistent baseline for app quality and reliability. The technical conformance tests, contained in the Windows App Certification Kit, help you know that you meet the expected standards before you submit your app. As you and other devs continue to deliver apps that meet these standards, customers will be excited to discover and try out new apps, creating a stronger app ecosystem for all of us.

The Store also makes it easy for customers to provide ratings and reviews that will help the best apps stand out, enticing even more customers to try out the top rated apps with confidence. In the sample app listing page below, note the highlights not just for ratings and reviews, but also two other important elements of the app listing page. Prior to installing a new app, customers can see what permissions the app has once it is installed (more detail on this later in the blog). After installing an app if the customer has concerns about app content or behavior, they can easily report their concern and we can follow up with you to address any problems identified. Helping customers decide which apps best meet their needs and allowing customers to provide input and feedback is an important way to improve overall confidence in the Windows 8 app ecosystem.

App listing page from the Windows Store

Finally, the Store collects telemetry data that can help you investigate problems your customers see, including the number and types of crashes they suffered. We review this automated telemetry for indications that an app’s behavior is unreliable or inconsistent with the expectations of our customers. Our goal is to make effective use not only of the individual feedback that customers provide on apps through ratings and reviews, but also provide insight into how your app is actually behaving on customers’ machines and give you the opportunity to improve your app based on this data.

In all these ways, the Windows Store is your partner in connecting you with people who want your apps, and helping them have a great experience with your apps.

Apps are just a click away

When you have your customer’s attention on the app listing page, you don’t want anything to get in the way of your customer getting your app. On Windows 8, getting an app is a matter of clicking a single button. Customers no longer have to wade through a series of questions or click button after button. After logging into the Store, when they find something they like, they just click the button, confirm the purchase, and go!

The great news for you is that you don’t have to write a single line of installation code to make this magic happen; it is all provided for you as part of Windows 8. Not only is installation handled, but Windows uses digital signatures to ensure the integrity of your app all the way from the Store to installation and even when the app is loaded and running on your customer’s computer. If Windows detects that the app no longer matches its digital signature, it guides the customer to download a corrected version from the Store.

Because Windows installs each app in a discrete location with separate and private locations for each app’s data and settings, customers don’t have to worry that installing, or removing, one app will interfere with the behavior of other apps or their computer. Customers will be more willing to try more apps than ever before, knowing that installing and removing apps won’t degrade their experience over time (in fact, with Windows 8 contracts, each app you install makes the experience better). You benefit by knowing that there is little another app might do that will damage your customer’s experience of your app.

Having a single, verifiable, and consistent mechanism to install apps not only simplifies your work, it provides an easy and positive experience for your customers, giving them confidence to get even more of your great apps. You can learn more about app deployment in App packages and deployment.

Windows 8 SDK for Metro style apps

The better experience customers have with your apps, the more readily they will try new apps and updates as you release them. The Windows 8 SDK for Metro style apps is a great foundation for you to build apps that customers won’t hesitate to install.

We put a lot of thought into the API set we offer for Metro style apps, not only to simplify the Windows programming environment, but also to provide a well-tested platform on which you could confidently build your apps, knowing they will work well with the Windows 8 Metro style app model.

Resist the temptation to find ways to invoke APIs that are not included in the SDK. This ultimately undermines the expectations that customers have for your app. APIs that are outside the SDK are not guaranteed to work with Metro style apps either in this release or in future releases, so you may find that your app doesn’t function properly for all customers. These APIs may also not function properly in the async environment that is foundational to Metro style app design. Finally these APIs may undermine customer confidence by accessing resources or data that Metro style apps would not normally interact with. For all these reasons, we have provided checks in the Windows App Certification Kit to help you catch places where you might have inadvertently called interfaces not exposed by the SDK.

While it is possible to hide or obfuscate calls to APIs that are not included in the SDK, this is still a violation of customer expectations and Store policy. In the end, we have created this platform to help developers like you to build amazing apps that work well with the system and with other apps and devices to delight customers. Working with the Metro style SDK is fundamental to your realizing that goal.

Working well together and apart

A clean installation process is important to your customers, and the SDK helps you build apps that integrate well with the system. Beyond this, customers expect a high degree of reliability from your app and our platform. We help you achieve your reliability goals by providing a greater degree of separation between Metro style apps than is possible for traditional Windows desktop applications. On Windows 8, each Metro style app runs in the context of a unique app container that helps insulate it and its data from other Metro style apps.

App containers provide a few characteristics that are shared by all Metro style apps. They:

Provide a dedicated environment for your app, including your own store for data and settings. You have little worry that some other Metro style app will change your app’s data, settings, or behavior.
Help ensure that your app doesn’t accidently interfere with the reliability of the Windows platform itself, or accidently use your customers’ data or devices in ways they don’t expect.
Provide a well-defined way to extend the capabilities of your app through declarations you make in the manifest and disclose to your customer in the app listing page.

Having this degree of separation makes it far easier to write apps that are reliable and respectful of the user. At the same time, we all want apps that interact well with one another. Windows 8 provides several mechanisms for Metro style apps to work with each other and with the platform to provide these satisfying experiences, including:

App contracts, which are the glue that binds Metro style apps together and to the system UI.
The FilePicker, which allows your app to interact with data the user selects.
App capability declarations, which allow your app to programmatically interact with devices and data, when appropriate for your functionality.

These are all well-defined ways for your app to engage more deeply with other apps and the system. The app container exists to help you deliver on your customer’s expectations of reliability and respectful use of their system and data. The constraints of the app container are designed to help realize customers’ expectations for consistent and intuitive app behaviors, and using techniques that allow your app to run code outside of an app container is a violation of user trust and Store policy.

In our discussions with developers during this preview period, we have seen apps that have misunderstood or accidently misused some of these mechanisms, so let’s go into more detail about the app capabilities in particular.

App capability declarations

The app container can be extended in a variety of ways using capability declarations, each of which is designed to enable certain scenarios. Therefore, we recommend that you use them only under certain conditions. These capabilities fall into 4 primary buckets:

Data libraries: By default, apps have no access to the customer’s data libraries, like the Music library, or the Documents library. We recommend that you use the FilePicker to interact with these libraries, but in some rare cases it is necessary for your app to be able to directly read and manage data in these locations.
Device access: By default, apps can’t use devices that most users consider sensitive for their privacy, including the webcam, microphone, and location. When apps need these devices, they must both declare their intent, and get consent from the user.
Network access: By default, apps have no access to the customer’s networks. Because most apps interact with the Internet, we enabled this particular capability in all the Visual Studio templates for Metro style apps. If your app needs more than just simple Internet access, you can read about your options below.
User identity: These capabilities provide direct access to a particular customer’s corporate logon info, or to certificates associated with their identity. These capabilities, although rarely needed, are necessary for certain enterprise apps, and you might need to use them in scenarios like banking transactions in which a smartcard might be required for authorization.

Declaring a capability in any of these categories is as simple as checking it off in the Visual Studio manifest designer. But add capabilities only if they are critical to realizing a scenario for an app. During the Consumer Preview, we saw several apps submitted to the Store that declared every capability or a capability that was not essential for the app. So, while the list of possible capabilities is relatively short, it is worth reviewing in more detail each of these capabilities and how to use them.

Visual Studio’s manifest designer

Data libraries

These capabilities grant your app access to user data that wasn’t necessarily created in your app. Users expect apps to be respectful of access to their private data. One way to honor the trust users place in your app is by declaring only the minimum access necessary for your app. In most cases you can avoid using these capabilities entirely by using the FilePicker, through which the user can browse files anywhere on their hard drive or network. For example, use the FilePicker to provide a File open experience, or to add Save as to your app in order to give your user the opportunity to save content from your app into their library locations or to removable storage.

Manifest declaration	What it provides
musicLibrary	Provides the capability to add, change, or delete files in the Music Library for the local PC and HomeGroup PCs.
videoLibrary	Provides the capability to add, change, or delete files in the Videos Library for the local PC and HomeGroup PCs.
pictureLibrary	Provides the capability to add, change, or delete files in the Pictures Library for the local PC and HomeGroup PCs.
documentsLibrary	Provides the capability to add, change, or delete files in the Documents Library for the local PC. The app can only access file types in the Documents Library that are defined using the File Type Associations declaration. The app can’t access Document Libraries on HomeGroup PCs.
removableStorage	Provides the capability to add, change, or delete files on removable storage devices. The app can only access file types on removable storage that are defined in the manifest using the File Type Associations declaration. The app can’t access removable storage on HomeGroup PCs.

During the Consumer Preview, we saw app submissions that declared these capabilities when they really didn’t need to. For example, apps declared documentsLibrary for a variety of reasons including:

Storing app-specific settings in the documents library. The private store is designed to provide this function. You can learn more about app settings and storage here.
Store a user-generated file. This is more properly accomplished using the FilePicker to allow the user to save the file to any location, including the documents library.
Sharing a document with another app. The Sharing contract is designed for this purpose.

If your app is designed to be the primary handler on the system for a given file type, for example a Fax Viewer that needs to handle all .TIFF files in the user’s documents library, then declare this capability.

Device access

Many devices, like orientation sensors and accelerometers, are available to any app. But most customers consider certain devices more sensitive than others, given that they are strongly associated with user privacy. There are a lot of great apps you can build on these devices. For example, if you have a casual game that allows shared gameplay, using proximity is a great way to establish a connection between devices.

Because these devices are closely coupled to user privacy, Windows 8 ensures that if you declare the capability, the customer will be prompted to approve this access the first time your app tries to access the particular device. For example, if your app offers mapping, you likely want to access the customer’s geolocation data. The first time your app tries to get this info, the customer sees a prompt to approve your app’s access. This approval sticks until the customer decides to explicitly remove the access through Settings at a later time. Because the customer can decline your app’s access to these devices, even if you have added the capability to the manifest, design your app to handle the lack of access gracefully. For example, if the customer has denied your app access to the built in GPS, you could simply prompt the user to select their location from a map.

Manifest declaration	What it provides
location	Provides access to the current location, which is obtained from dedicated hardware like a GPS sensor in the PC or derived from available network information.
webcam	Provides access to the webcam’s video feed, which allows the app to capture snapshots and movies from connected webcams.
microphone	Provides access to the microphone’s audio feed, which allows the app to record audio from connected microphones.
proximity	Provides the capability to connect to devices in close proximity to the PC via near field proximity radio. Near field proximity may be used to send files or communicate with an app on a nearby device.

Network access

Most apps need an Internet connection, so the Visual Studio templates for Metro style apps include the internetClient capability by default. If your app doesn’t need to communicate over the Internet, you should remove this capability. The internetClientServer capability is generally used in peer-to-peer (P2P) scenarios like gaming or VOIP, but unless your app must open a port in the firewall, don’t use this capability. Use the privateNetworkClientServer capability when your app needs to communicate over private networks, for example between devices within a home, or over a corporate network connection.

Manifest declaration	What it provides
internetClient	Provides outbound access to the Internet and networks in public places like airports and coffee shops. Most apps that require Internet should use this capability.
internetClientServer	Provides inbound and outbound access to the Internet and the networks in Public places like airports and coffee shops. This capability is a superset of internetClient. The internetClient capability doesn’t need to be enabled if this capability is also enabled.
privateNetworkClientServer	Provides inbound and outbound access to Intranet networks that have an authenticated domain controller, or that the user has designated as either home or work networks.

User identity

Most developers don’t need these capabilities. Use of these capabilities will be highly restricted and subject to additional onboarding policy and review. But there are cases where such capabilities are necessary and appropriate, for example some banks require two-factor authentication and need to allow customers to provide a smartcard that carries a digital certificate that confirms their identity. Other apps that are designed primarily for enterprise customers rather than consumers might need access to corporate resources that cannot be accesses without domain credentials.

Manifest declaration	What it provides
enterpriseAuthentication	Provides the capability to connect to enterprise intranet resources that require domain credentials.
sharedUserCertificates	Provides the capability to access software and hardware certificates, such as smart card certificates, for validating a user’s identity. When related APIs are invoked at runtime, the user must take action (insert card, select certificate, etc.). This capability is not necessary if your app includes a private certificate via a Certificates declaration.

Building confidence

Customers want to safely enjoy Windows 8 and the apps you build. The Metro style app experience is designed to make it easy for you to build apps that everyone can try and buy with confidence. This sets up a constructive cycle where people love and buy lots of apps that then generates opportunities for developers to create and deliver even more great Metro style apps.

As I noted at the beginning, we’re in this together; we are confident that the collective investments we made in this new ecosystem will help you build apps that people will be delighted with, and we look forward to partnering with you in delivering amazing new experiences to our joint customers.

–John Hazen

Building Windows 8

How to improve performance in your Metro style app

admin — Thu, 10 May 2012 04:23:44 +0000

Nobody likes slow or unresponsive apps. Users expect that apps respond immediately to touch, taps, clicks, gestures and key-presses. Users expect that animations are smooth, that they can play, pause and restart their music and videos quickly, and that they never have to wait for the app to catch up with them. This is the first in a series of posts on how to make your apps “fast and fluid.”

We invested a lot of time in the engineering teams thinking about how we can ensure the performance of Metro style apps. We have learned what we can do in the platform to deliver on fast and fluid performance and have also learned what works and what does not work in building apps that deliver great experiences. In this blog I share with you some of the hard lessons from our own experiences so that you can build the best possible experiences for your customers.

The psychology of performance

Performance is more than just a stopwatch and efficient algorithms. When I think of performance, I like to take a holistic view and consider how users experience their time using apps. What does it mean for an app to be fast and fluid? One way to think about it is to separate a user’s experiences into three categories: perception, tolerance, and responsiveness.

Perception: This is taking forever!

Perception contributes to the “fast” in fast and fluid. We define a user’s perception of performance as how favorably they recall the time it took to perform their tasks within your app. In a perfect world a user’s perceptions would match reality. But often this is not the case, and their perception of time matters more than the reality. Have you ever left an installation to finish on its own, and come back to realize it’s paused part way through, waiting for you to answer one more question?

The more steps you can remember about a process, the slower it seems.

Do:

Reduce the amount of time between activities that the user needs to perform to accomplish their task
Make sure that anytime you need to ask the user questions or have them provide info that you are asking all of the questions up front.

Don’t:

Separate out user activities into multiple periods with some time in between.

Tolerance: Time flies when you’re having fun

Tolerance contributes to both the fast and fluid of fast and fluid. If perception is a measure of a user’s recollection of how much time passed, then tolerance is a measure of how favorable the passing of that time is.

When a user doesn’t know how long an action will take, the wait is painful. Imagine you’re using an app to do some photo editing work. When you click to apply a filter, the app becomes unresponsive. The time it spends frozen quickly becomes intolerable, even if it is just for a few seconds.

Photo apps have solved this problem by adding a progress bar or small animation to indicate that it is working on applying the filter. The amount of time users are willing to wait for the work to complete is far higher because there is no uncertainty. The app is both fast and fluid, and the difference is profound.

Do:

Take a moment to identify the areas of your app that may require a substantial (>= 1s) loading time.
Take steps to limit or eliminate user uncertainty during these scenarios.
Give users a visual indication of where they are in the process and how long it will take.
Use async APIs to avoid blocking the UI thread and making the app appear frozen.

Don’t:

Undergo long running actions without providing user feedback.

Responsiveness: Reflexes < reactions < acknowledgements

Responsiveness contributes to the “fluid” in fast and fluid. If tolerance is a measure of the expectations and favorability of time, then responsiveness is the concept that the expectations of time are relative to the activity being performed. To measure and rate the performance of an activity, there must be a time interval to compare it against. I’ll refer to these time intervals as interaction classes. Internally we use these interaction classes to define responsiveness goals for core scenarios throughout Windows and track failures to meet these goals as bugs in the product.

Interaction class	Target	Upper bound	Human perception	Typical scenario
Instant	<= 50 ms	100 ms	No noticeable delay.	Input response – mouse click, button tap, etc.
Fast	50 – 100 ms	200 ms	Minimally noticeable delay. No feedback necessary.	Pan/Scroll
Typical	100 – 300 ms	500 ms	Quick, but too slow to be described as fast. No feedback necessary.	Open an in-page dialog (i.e. an info tip, pop up, fly out, toast, etc.)
Responsive	300 – 500 ms	1 sec	Not fast, but still feels responsive. No feedback necessary.	Navigate to a new page, zooming, display processed or ready data
Continuous	>500 ms	10 sec	Medium wait, no longer feels responsive. Not long enough to do something else. May need feedback.	Launch the app, Snap the app, error messages, time-outs, update progress indication
Extended	>5 sec	>1 minute	Long enough to do something else while waiting. May need feedback.	Sync or index a device/library

Do:

Assign the important scenarios of your app to an interaction class representing the desired experience.
Identify if your scenarios are not meeting these goals and optimize them.
Identify if a scenario may require user feedback and provide it.

Key experiences to optimize

Performance problems show up in various ways. They can reduce battery life, cause panning and scrolling to lag behind the user’s finger, or even make the app appear frozen for an extended period of time. I know that you don’t have infinite time to work on improving performance, so this section will go over some tips on how to identify areas where optimization will have the most impact, and some guidelines that can help you make those optimizations.

One way you can think about making optimizations, is that a process needs to be 20% faster or 20% slower before a user perceives a difference.

You may find “low-hanging fruit” in your app that can greatly increase performance for your key scenarios. But when you fix these issues, it becomes increasingly unlikely to stumble across a single performance issue which will immediately reduce the duration of the process by 20%. More often it is an accumulation of smaller problems along the same path which all contribute to the same user experience issue, and in the next section I discuss a great tool for discovering these paths.

App profiling

One of the simplest and most readily available techniques for determining where optimizations have the greatest effect is to perform app profiling. Profiling provides data on how much time your app is spending in its various functions, so you can see the hot spots where the app is doing most of its work. Thankfully there is a great profiling tool available in Visual Studio 11 that you can access on the Windows 8 Consumer Preview.

But before you begin, remember that Windows 8 will be run on a wide variety of devices and taking performance measurements on powerful hardware may not truly show performance characteristics on other form factors. For many of my own features, when performing measurements I use a lower-end laptop. For more info see the blog on Running the Consumer Preview: system recommendations.

Here’s how to prep a machine for measurements:

Make sure the machine is plugged in and not running on battery – many systems operate differently on battery to conserve power.
Don’t use remote desktop to perform measurements because it can disable hardware acceleration and skew results.
Ensure that the total memory utilization on the system is less than 50%. If it’s higher, close apps until you reach 50% to make sure you are measuring the true impact of your app and not other processes.

To begin profiling your app:

Launch your app in Visual Studio.
On the Debug menu pick one of the two Performance Analysis options:

Start Performance Analysis: Immediately start recording usage info and launch the app.
Start Performance Analysis Paused: Launch the app and later you can resume recording of info. This is used to get the app into a particular state before recording info (such as to test a specific user scenario).

After performing the actions you want to measure, go back to Visual Studio and click Stop profiling. This causes VS to generate a report and display key information about the app’s activities.

Two of the most useful views in the performance report are the Call Tree view and the Function Details view. In the Call Tree view, you can see all the functions your app called during execution, how many times they were invoked, and how much time they took to execute. There is also an Expand Hot Path button, which shows you which functions took the longest time to execute. These are the first areas for you to concentrate your optimizations, because they will likely have the largest effect.

The report shows both the inclusive and exclusive times for each function. Exclusive time measures the percentage of time spent executing code in that function. Inclusive time is the percentage of time between when the function was called and when it returned. In other words, it is not only the time spent executing code in the function, but also the time spent executing code in any functions that it calls.

For any of the functions in your app, you can open the Function Details view to get detailed info about what the function did, including the specific code that it executed and what functions it called and how long these functions took. In the example shown in the figure, Array.concat function is the major contributor to the hot path, taking up 29.7% of app execution time. The Function Details view shows us that Array.concat function is actually only taking up about 12.6% of the time itself (shown in orange), and that the majority of the time is actually taken up in get_MainResourceMap function, which the concatenation function calls as part of its execution (shown in purple). You can then click on any of these functions to get more details.

A few weeks before the release of the Windows 8 Consumer Preview, I was using one of the apps and noticed that my laptop was getting hot and the fans started to turn on. Working with the owner of the app, we used profiling to identify some code paths that were causing large amounts of unnecessary CPU usage, which were then fixed. The difference was immediately noticeable, and other app scenarios (such as snapping) were also improved by the changes.

Suspend is your friend

App launch occurs only when your app is not suspended – otherwise your app pops back into view nearly instantly as it is resumed. Keeping your app suspended is a technique for managing perception, tolerance, and responsiveness. Users enjoy your app more quickly, and never experience the uncertainty of waiting for your app to load each time they use it. In short, keeping your app from being terminated is a performance grand slam. The easiest way to do that is to keep your app’s memory usage low when suspended.

Before your app gets suspended, it has a few seconds to do some work. During this time, free any large objects that can be easily re-acquired on resume. This keeps your app’s memory footprint low, and greatly reduces the likelihood that the system terminates your app to make room for something else. Here’s how you can see if your app correctly suspends:

Launch the app and then go back to the desktop.
Launch the Task Manager by pressing Ctrl+Shift+Esc, and click “More details” to see all available options.
Click View > Status values > Show suspended status.

After a few seconds, the word “Suspended” appears next to your app’s name. While suspended, make sure your app’s private working set memory usage is significantly lower than when it is running. I recommend that you target these memory metrics for your app while it is suspended, based on its complexity and general size:

App complexity (approx.)	Private set while suspended (max)
Minimal app (ex. Hello World)	40-60 MB
Medium app (ex. Weather)	60-80 MB
Large app (ex. Windows Live Photos)	120-150 MB

Here’s how you can see how much memory your app is using while suspended:

Make sure the app is suspended using the steps we saw earlier.
Right-click on the app’s name in Task Manager and click “Go to details.” This will take you to more details about your app’s process (WWAHost.exe is the process for all Metro style apps using JavaScript; otherwise your app’s name appears as the process).
Make sure that the “Memory (private working set)” column is present. If not, right-click any column, go to Select columns, and select Memory (private working set).

The value listed under this column is the private working set of your app.

Being a good citizen in the app ecosystem

As disappointing as it may sound, your app is not the only one that will be used . Therefore, be a good citizen when running on the user’s system so that they don’t begin to attribute any perceived latencies in the system to your app and start to mentally relate it to bad performance or battery life on their system. Here are a couple tips to help your app play well with others.

Don’t spike memory usage

The system’s job is to accommodate the resource needs of all Metro style apps by automatically terminating suspended apps to make room for new ones, freeing the user from having to manage resources. A side effect of this is that if an app requests a large amount of memory, then other apps might be terminated– even if the app frees that memory soon after requesting it. To avoid this issue when tackling heavyweight operations, it is best to approach them in small chunks.

If you are coding in a memory managed language (such as JavaScript or C#), it is extremely difficult to control when memory allocations occur. However, an easy trap to fall into is loading resources which are too large for the resolution of the current system and scaling them down. You can use the new Thumbnail APIs to acquire resources appropriate for the target resolution and avoid having an unnecessarily high overhead. We used this approach to greatly reduce the memory usage of a picture based puzzle game that we use for testing.

Regardless of language, I recommend that you target these runtime memory metrics for your app, based on its complexity and general size:

App complexity (approx.)	Total working set (max)
Minimal app (ex. Hello World)	50-70 MB
Medium app (ex. Weather)	80-100 MB
Large app (ex. Photos)	120-150 MB

Here’s how you can see how much memory your app is using while running:

Launch the Task Manager by pressing Ctrl+Shift+Esc, and click More details to see all available options.
Click the Options menu item, and make sure that Always on top is checked.
Launch your app. When the app appears in Task Manager, right-click it and click Go to details.
Make sure that the Working set (memory) column is present. If not, right-click any column, and go to Select columns. Check the Working set (memory)column.
The value listed under this column is the total working set of your app.

Minimize use of system resources while idle or snapped

One of the biggest concerns for users is the battery life of their devices. Therefore, I recommend that your Metro style apps help conserve energy by freeing their use of system resources when the user is not actively interacting with them. Here are just a few tips to reduce resource usage:

Don’t run animations, audio, or background videos while snapped.

Your app is no longer the center of attention. Make your app feel colorful and usable, but don’t take away from the resources available to the primary app or use the battery.
This assumes your app isn’t a dedicated music/video playback client.

Don’t run animations, audio or background videos in an infinite loop.

If the user hasn’t interacted with the app over some small duration, pause these activities. You can safely resume them when the user next interacts with your app.
I’ve seen apps go from 40% CPU usage while idle down to 0% simply because they paused their background activities.

Don’t perform file caching, device syncing, or any other disk-intensive operation while snapped or idle.

Using the disk unnecessarily increases seek times for other operations and uses a lot of power.

Going forward

In this post I described how you can think about performance, methods for setting goals for the key experiences in your app, and talked about some tools to help identify areas that you might need to optimize. My next post will cover how to go about making these optimizations for the biggest problem areas, and how to avoid some common pitfalls. I hope these tips will prove useful to you!

Until next time,

– David Tepper, Program Manager, Windows

Windows 8 app developer blog

Tackling performance killers: Common performance problems with Metro style apps

admin — Wed, 09 May 2012 01:22:17 +0000

Now that you had time to read my previous post, How to improve performance in your Metro style app , on the methodology and tools available to help you create fast and fluid apps, I want to dig into the common performance killers I have seen in apps. In this post, I go over the top guidance points which I have observed to result in measureable and noticeable improvements for Metro style apps, both written in JavaScript and in XAML. Plus, I tell you about 5 specific practices that I know will make a big difference, regardless of what language you are using. The good news is that they don’t depend on clever tricks or complex operations. I am confident that following these guidelines will hugely improve your app’s performance. Let me know in the comments how these help you, and share your own tips.

General guidance

Rely on packaged content, not network content.

Local images and files are always faster to retrieve than those over the network.
If your app needs to load a “live” image, it is best to use a local image as a placeholder while it is being retrieved.

Scale local images to the right size.

If an image is always going to be displayed at the same resolution, then package it at that resolution pre-scaled. This prevents the image from being scaled at runtime each time it is shown, incurring a performance penalty many times throughout the app’s lifecycle.
If the image may be shown at multiple resolutions, package multiple versions of the image unless you have a strong reason not to.

Keep the launch times of your modern app fast.

Perform network operations only after the splash screen disappears.
Defer loading databases and other large in-memory objects while the app is activating.
If you have large tasks to complete, provide a custom splash screen or pared down landing page so that your app can accomplish these tasks in the background.

Windows 8 runs on a wide range of devices, use media content appropriate for the user’s resolution.

Loading content that is too small for a user’s resolution has reduced fidelity.
Loading content that is too large for a user’s resolution puts an unnecessary strain on the resources of the system.

Emphasize responsiveness in your apps.

Don’t block the UI thread with synchronous APIs. Use asynchronous APIs or call synchronous APIs in a non-blocking context (such as from another thread).
Move time-intensive calculations to a thread that is not the UI thread. This is important because users will likely notice delays longer than 100ms.
Break apart time-consuming work into smaller chunks, allowing the UI thread to listen for user input in between.
Use web workers/threads to offload expensive work.
Don’t draw to the screen faster than it can refresh. Input events fire much faster than the screen refresh rate. So using these events to update the screen causes a large amount of unnecessary work. Synchronize your draws to the screen refresh rate instead.

Tweaking performance of Metro style apps using JavaScript

When coding Metro style apps in JavaScript, all the tips and tricks you already know for coding JavaScript in web sites still apply. But for Metro style apps written in JavaScript, here are the top 3 techniques that yield the most impactful performance gains, based on our research and observations. For more info, see Performance best practices for Metro style apps using JavaScript, in the Dev Center.

Use thumbnails for quick rendering

The file system and media files are an important part of most apps, and also one of the most common sources of performance issues. Accessing media files can be slow, because it takes memory and CPU cycles to store and decode or display the media.

Instead of scaling down a large version of an image to display as a thumbnail, use the Windows Runtime thumbnail APIs. Scaling down a full-size image is inefficient because the app must read and decode the full-size image and then spend additional time scaling it. The Windows Runtime provides a set of APIs backed by an efficient cache to allow the app to quickly get a smaller version of an image to use for a thumbnail.

This example prompts the user for an image and then displays the image.

// Pick an image file
picker.pickSingleFileAsync()
.then(function (file) {
  var imgTag = document.getElementById("imageTag");
  imgTag.src = URL.createObjectURL(file, false);
});

This example works well when you want to render the image at, or near, its full size, but it’s inefficient for displaying a thumbnail view of the image. The thumbnail APIs return a thumbnail version of the image that the app can decode and display much faster than the full-sized image. The next example uses the getThumbnailAsync method to retrieve the image and create a thumbnail based on it.

// Pick an image file
picker.pickSingleFileAsync()
.then(function (file) {
  var properties = Windows.Storage.FileProperties.ThumbnailMode;
  return file.getThumbnailAsync(properties.singleItem, 1024);
})
.then(function (thumb) {
  var imgTag = document.getElementById("imageTag");
  imgTag.src = URL.createObjectURL(thumb, false);
});

Our measurements show that this pattern can improve image loading times by as much as 1000% (that is, the image loads up to 10 times faster when using the thumbnail APIs versus accessing it directly from disk and scaling it).

Keep DOM interactions to a minimum

In the platform for Metro style apps using JavaScript, the DOM and the JavaScript engine are separate components. Any JavaScript operation that involves communication between these components is relatively expensive when compared to operations that can be carried out purely within the JavaScript runtime. So it’s important to keep interactions between these components to a minimum. For example, getting or setting properties of DOM elements can be fairly expensive. This example accesses the body property and several other properties repeatedly.

// Don’t use: inefficient code. 
function calculateSum() {
    // Retrieve Values
    var lSide = document.body.all.lSide.value;
    var rSide = document.body.all.rSide.value;

    // Generate Result
    document.body.all.result.value = lSide + rSide;
}

function updateResultsStyle() {
    if (document.body.all.result.value > 10) {
        document.body.resultsDiv.class = "highlighted";
    } else {
        document.body.resultsDiv.class = "normal";
    }
}

The next example improves the code by caching the value of the DOM properties instead of repeatedly accessing them.

function calculateSum() {
    // Retrieve Values
    var all = document.body.all;
    var lSide = all.lSide.value;
    var rSide = all.rSide.value;

    // Generate Result
    all.result.value = lSide + rSide;
}

function updateResultsStyle() {
    var body = document.body;
    var all = body.all;
    if (all.result.value > 10) {
        body.resultsDiv.class = "highlighted";
    } else {
        body.resultsDiv.class = "normal";
    }
}

Use DOM objects only to store info that directly affects how the DOM lays out or draws elements. If the lSide and rSide properties from the previous example store only info about the internal state of the app, don’t attach them to a DOM object. The next example uses pure JavaScript objects to store the internal state of the app. The example updates DOM elements only when the display needs to be updated.

var state = {
    lValue: 0,
    rValue: 0,
    result: 0
};

function calculateSum() {
    state.result = lValue + rValue;
}

function updateResultsStyle() {
    var body = document.body;
    if (result > 10) {
        body.resultsDiv.class = "highlighted";
    } else {
        body.resultsDiv.class = "normal";
    }
}

Our measurements show that simply accessing data in the DOM can result in up to a 700% increase in access time when compared to accessing variables not tied to the DOM.

Manage layout efficiently

To render an app onscreen, the system must perform complex processing that applies the rules of HTML, CSS, and other specifications to the size and position of the elements in the DOM. This process is called a layout pass and can be very expensive.

APIs that trigger a layout pass include:

window.getComputedStyle
offsetHeight
offsetWidth
scrollLeft
scrollTop

A layout pass occurs as part of calling these APIs if anything that affects layout has changed since layout info was last gathered. One way to reduce the number of layout passes is to batch API calls that trigger a layout pass. To see how to do this, let’s take a look at the next code snippet. In both of the examples here, we are adjusting the offsetHeight and offsetWidth of an element by 5. First, take a look at a common but inefficient way to adjust the offsetHeight and offsetWidth:

// Don't use: inefficient code.
function updatePosition(){
    // Calculate the layout of this element and retrieve its offsetHeight
    var oH = e.offsetHeight; 

    // Set this element's offsetHeight to a new value
    e.offsetHeight = oH + 5; 

    // Calculate the layout of this element again because it was changed by the  
    // previous line, and then retrieve its offsetWidth
    var oW = e.offsetWidth; 

    // Set this element's offsetWidth to a new value
    e.offsetWidth = oW + 5; 
}

// At some later point the Web platform calculates layout again to take this change into account and render 
the element to the screen

The previous example triggers 3 layout passes. Now take a look at a better way to achieve the same result:

function updatePosition() {
    // Calculate the layout of this element and retrieve its offsetHeight
    var height  = e.offsetHeight + 5;  

    // Because the previous line already did the layout calculation and no fields were changed, this line retrieves 
the offsetWidth from the previous line
    var width = e.offsetWidth + 5; 

    //set this element's offsetWidth to a new value
    e.offsetWidth = height;

    //set this element's offsetHeight to a new value
    e.offsetHeight = width;
}

// At some later point the system calculates layout again to take this change into account and render element to the screen

Even though the second example is only slightly different than the first, it triggers only 2 layout passes instead of 3, a 33% improvement. The performance impact varies, depending on the size and complexity of the DOM and its associated styles. The richer your app’s UI, the more important following this guideline becomes.

Tweaking performance of Metro style apps written in XAML

Well-structured XAML pays dividends in many key scenarios including activation time, page navigation, and memory usage. Here are a few tips to help tune the XAML of your app.

Avoid duplication

Parsing XAML and creating corresponding objects in memory can be time-consuming for complex UI with deep element trees. This is why we recommend that you load only the XAML needed to get past the startup process. The easiest thing to do is load only pages needed to display the first visual. Carefully examine the XAML of your first page to make sure it contains everything it needs. If you reference a control or style that is defined somewhere else, the framework parses that file too.


<Page ...> 
    <Grid>
        <TextBox Foreground="{StaticResource TextColor}" />
    Grid>
Page>

Contents of AppStyles.xaml
<ResourceDictionary …>
    <SolidColorBrush x:Key="TextColor" Color="#FF3F42CC"/>

    
ResourceDictionary>

Trim resource dictionaries. Store app-wide resources in the Application object to avoid duplication, but move resources specific to single pages to the resource dictionary of that page. This reduces the amount of XAML parsed when the app starts and only incur the cost of parsing that XAML when a user navigates to the specific page.


<Application …>
    <Application.Resources>
        <SolidColorBrush x:Key="DefaultAppTextColor" Color="#FF3F42CC"/>
        <SolidColorBrush x:Key="HomePageTextColor" Color="#FF3F42CC"/>
        <SolidColorBrush x:Key="SecondPageTextColor" Color="#FF3F42CC"/>
        <SolidColorBrush x:Key="ThirdPageTextColor" Color="#FF3F42CC"/>
    Application.Resources>
Application>

XAML for the home page of the app
<Page ...>    
    <StackPanel>
        <TextBox Foreground="{StaticResource HomePageTextColor}" />
    StackPanel>
Page>

XAML for the second page of the app
<Page ...> 
    <StackPanel>
        <Button Content="Submit" Foreground="{StaticResource SecondPageColor}" />
    StackPanel>
Page>


<Application …>
    <Application.Resources>
        <SolidColorBrush x:Key="DefaultAppTextColor" Color="#FF3F42CC"/>
        <SolidColorBrush x:Key="HomePageTextColor" Color="#FF3F42CC"/>
    Application.Resources>
Application>

XAML for the home page of the app
<Page ...>    
    <StackPanel>
        <TextBox Foreground="{StaticResource HomePageTextColor}" />
    StackPanel>
Page>

XAML for the second page of the app
<Page ...>
    <Page.Resources>
        <SolidColorBrush x:Key="SecondPageTextColor" Color="#FF3F42CC"/>
    Page.Resources>
    
    <StackPanel>
        <Button Content="Submit" Foreground="{StaticResource SecondPageTextColor}" />
    StackPanel>
Page>

Optimize element count

The XAML framework is designed to display thousands of objects but reducing the number of elements on a page will make your app layout and render scenes even faster. There are a few tricks that you can use to reduce a scene’s element count while maintaining the same level of visual complexity.

Avoid unnecessary elements. For example, set the Background property on panels to provide a background color instead of placing colored Rects behind the elements in that panel.

                                                                
<Grid>
        <Rectangle Fill="Black"/>
   Grid>


<Grid Background="Black" />

Collapse elements that are not visible because they are blocked or transparent.
If the same vector-based element is re-used multiple times, consider making it an image. Memory for an image is allocated only once per image Uri. In contrast, vector-based elements are instantiated for every instance.

Use independent animations

Animations can be calculated from beginning to end when they are created. Sometimes the changes to the property being animated don’t affect rest of the objects in a scene. These are called independent animations and they are run on the composition thread instead of the UI thread. This guarantees that they remain smooth because the composition thread is updated at a consistent cadence. All these are guaranteed to be independent:

Object animations using key frames
Zero-duration animations
Canvas.Left/Top
UIElement.Opacity
SolidColorBrush.Color when applied to many properties
Subproperties of

UIElement.RenderTransform
UIElement.Projection
RectangleGeometry of UIElement.Clip

Dependent animations affect layout and can’t be calculated without extra input from the UI thread. These animations include modifications to properties like width and height. By default dependent animations are not run and require an opt-in from the app developer. When enabled, they will run smoothly if the UI thread remains unblocked; but they begin to stutter if the framework or app is doing a lot of other work.

The XAML framework has worked hard to make almost all animations independent by default; but there are some actions you can take to disable this optimization. Be very cautious when doing the following:

Setting the EnableDependentAnimation property allows a dependent animation to run on the UI thread. Convert these animations into an independent version. For example animate ScaleTransform.XScale and ScaleTransform.YScale instead of the Width and Height of an object.
Making per frame updates which are effectively dependent animations. An example of this is applying transformations in the handler for CompositonTarget.Rendering.
Running any animation considered independent in an element with CacheMode=BitmapCache. This is considered dependent because the cache must be re-rasterized each frame.

Creating fast and fluid apps that are rich and complex is an art. I shared some specific things for you to consider, but it is rare that any one tool or technique is the key to good performance. More often it is a collection of good practices starting with considering performance early in your design. I hope that this blog will set you on the right path for delivering on your customers’ high expectations.

Happy (and efficient) coding!

-Dave Tepper, Program Manager, Windows

Windows 8 app developer blog

Fast and fluid animations in your Metro style app

admin — Thu, 03 May 2012 10:18:52 +0000

Fast and fluid animations bring apps to life. In Windows 8 Consumer Preview, you will notice that animations are an integral part of the user experience. When you log in to your PC, the items in the Start menu animate in. When you launch an immersive app or zoom into the Start menu, the experience is enriched with a smooth animation. Animations can tell the user what happened as a result of a specific action. This visual feedback instills user confidence in the app’s responsiveness. Even a simple addition or deletion of an item in a list can be made fluid, modern, and informative using a subtle animation (as seen in Jensen Harris’s //build/ session, around minute 25:00).

This short video demonstrates UI enriched with smooth animations.

Your browser doesn’t support HTML5 video.
Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

In Windows 8, animations are a key component of the Metro style personality and you can bring this personality to your own apps!

Here is what’s in this blog post:

A brief overview of the animation engine
How to get started using the Animation Library
Custom animations and how to take advantage of the animation engine improvements
Tips ‘n tricks for incorporating animations in your Metro style apps.

Independent animation

A big part of the Windows 8 experience is smooth and glitch-free animations, which are achieved through a capability called independent animation. An independent animation is an animation that runs independently from thread running the core UI logic. (A dependent animation runs on the UI thread.) In Windows 8 many of the animated elements are composed by a composition engine that runs on a separate thread. The engine’s work is offloaded from the CPU to the GPU. Moving composition to a non-UI thread means that the animation won’t jitter or be blocked by the app working on the UI thread (such as JavaScript code execution or sync operations). The GPU hardware is optimized for delivering visually rich graphics and makes use of video memory resources. Using the GPU greatly improves performance, allowing animations to run at a smooth and consistent frame rate.

You don’t need additional markup to make your animation take advantage of the independent animation capability. The system determines when it is possible to compose the animation independently. To make animations in your apps performant and smooth, you need to follow the independent animation guidelines in the Dev Center. These guidelines are most useful when creating custom animations, which we’ll dive into later in this post.

Now, let’s get started with learning how you can enhance your apps by first making use of the metro-style animations that are provided in the Animation Library.

Animation Library

The Animation Library is a suite of Metro style animations that has been built specifically to take advantage of the platform’s independent animation capability. These animations are used throughout Windows UI and are also available for your Metro app. Think of this library as providing a palette of animations that do the right thing for you and are already designed to be fast and fluid.

As app developers ourselves, we love this feature because we don’t have to spend time creating animations that have the Windows 8 look and feel. Simply use the Animation Library and your app now is part of the Windows experience.

This library animates the Windows UI itself. These animations are clean and purposeful. We put a lot of attention into getting the timing and animation curves exactly right so that the user gets fast and fluid feedback when they interact with the Windows UI. So when designing animations in your app, we recommend that you first look at the Animation Library to find the best animation that fits your need.

It doesn’t matter if you are using HTML or XAML, the Animation Library provides you with a way to use the right animations and ensures that your UI will be fast and fluid. Let’s look at some examples.

JavaScript example

The JavaScript/HTML Personality Library is built with CSS3 animations and transitions. These animations are used for app navigation, content transitions and Windows 8 controls.

A simple yet compelling animation is the EnterPage animation. Use it when displaying content for the first time or transitioning between pages in a running app.

This example demonstrates how you can use this simple API in your app.

HTML

<html>
   <body>
      <div id="input">
         Some content here
      div>
      <button onclick="runAnimation()", Run animation&lt;/button>
   body>
html>

CSS

<style>
   #input
   {
      background-color:blue;
   }
style>

JavaScript

XAML example

In XAML, the built-in Animation Library entails two concepts: Theme transitions and theme animations.

Theme transitions are typically used to animate visuals on the screen as they are loading, unloading or changing location on the screen. XAML layout system triggers these built-in animations in response to changes in the layout of the page.

These layout triggers include:

Adding a UIElement to the page or visual tree.
Removing a UIElement from the page or visual tree.
Updating the layout properties of an existing UIElement on the page or visual tree that causes its location or size to be updated.

A particular theme transition may respond to any or all of the layout triggers. The EntranceThemeTransition responds to trigger #1 and animates UIElements as they are added to the page or visual tree. In the next example, all of Grid’s children are animated using EntranceThemeTransition.

<Grid>
    <Grid.ChildrenTransitions>
        <TransitionCollection>
            <EntranceThemeTransition/>
        TransitionCollection>
    Grid.ChildrenTransitions>

    
Grid>

Theme animations are built-in animations that are typically run on user interaction and you must trigger them to run. The easiest way to run a theme animation is to call the Begin method on Storyboard class. If you are familiar with the VisualStateManager (VSM), a theme animation can be put inside a visual state of a control. This example shows how to trigger a theme animation using the Begin method:

XAML

<Grid Background="{StaticResource ApplicationPageBackgroundBrush}">
    <Grid.Resources>
        <Storyboard x:Name="downAnimation">
            <TapDownThemeAnimation TargetName="rectangle"/>
        Storyboard>
        <Storyboard x:Name="upAnimation">
            <TapUpThemeAnimation TargetName="rectangle"/>
        Storyboard>
    Grid.Resources>
        
    <Rectangle x:Name="rectangle" 
                PointerPressed="Rectangle_PointerPressed" 
                PointerReleased="rectangle_PointerReleased"/>
Grid>

Code


private void Rectangle_PointerPressed(object sender, PointerEventArgs e)
{
    downAnimation.Begin();
}

private void rectangle_PointerReleased(object sender, PointerEventArgs e)
{
    upAnimation.Begin();
}

Custom animations

As powerful as the Animation Library is, it can’t cover all your scenarios. For such cases, you can build your own custom animations that the system runs independently (see Animating for design guidance on building your own animations). This is where you need to be more careful about how to build an animation so that it doesn’t end up running on the UI thread.

You can still use dependent animations in your app. We encourage you to follow the independent animation guidance for custom animations but if your scenario requires animations that cannot be independently animated then the animation can still be run dependently.

The examples here demonstrate the use of a 3D non-affine independent animation that is not in the Animation Library.

JavaScript

For JavaScript apps, you can access the independent animation capability for custom animations via the CSS3 Animation and Transition syntax newly introduced to the Microsoft web platform in IE10. Independent animation supports only properties that don’t require re-layout or re-rendering. That means, independent animation for JavaScript apps is applicable to and supported only for CSS Animations/Transitions that target CSS3 2D and 3D Transforms or Opacity. Animations of other CSS properties run dependently on the UI thread.

Example of HTML custom animation

The example here demonstrates a simple CSS 3D flip.

HTML

<html>
   <head>
      <title>Html animations CSS3title>
   head>
   <body>
      <div id="parent">
         <div id="box" onclick="className='move'" >Click me for CSS Change!div>
      div>
   body>
html>

CSS

<style>
   body
   { 
      background-color:gray; 
   }
   #box
   {
      position: relative;        
      background-color:green;
      width:300px;
      height:300px
   }
   
   #box.move
   {
      -ms-transition-property: -ms-transform;
      -ms-transition-duration: 1s;
      -ms-transition-timing-function: ease-in;    
      -ms-transform: rotateY(-180deg);
      -ms-transform-origin: 50% 50%;    
   }

   #parent{-ms-perspective: 600px;}
style>

XAML

For XAML apps, a specific subset of properties are supported independently (you can find more info in the Windows 8 Developer Center). These properties include canvas positioning, opacity, render transforms, projections, clips and color.

Animating any property, besides the list we just looked at, results in a dependent animation. Meaning, the animation runs on the UI thread and thus will be at a risk of glitching. To encourage the development of fast and fluid UI XAML runs only independent animations unless you explicitly enable dependent animations. If you want to run a dependent animation, you can use the EnableDependentAnimation property on Timeline. There’s also a global static AllowDependentAnimations property that you can set to false to disable all dependent animations in your app.

Example of a XAML custom animation

The next example shows how to animate properties on PlaneProjection that the system runs independently. The animation concepts and syntax are exactly the same as in other XAML technologies but have been enhanced in Windows 8 to run independently, resulting in better performance characteristics for apps.

<Grid>
    <Grid.Resources>
        <Storyboard x:Name="customAnimation">
            <DoubleAnimation Storyboard.TargetProperty="RotationY" Storyboard.TargetName="projection" 
Duration="0:0:1" To="-180" />
        Storyboard>
    Grid.Resources>
        
    <Grid Background="Red" Height="400" Width="600" PointerPressed="Grid_PointerPressed">
        <Grid.Projection>
            <PlaneProjection x:Name="projection"/>
        Grid.Projection>

        

    Grid>
Grid>

private void Grid_PointerPressed(object sender, PointerEventArgs e)
{
    customAnimation.Begin();
}

Best practices for independent animations

As with all systems, there are some limitations for independent animation. These limitations are different for the HTML and XAML platforms. In general you get independent animations except for these cases:

Animating property that affects layout: These properties, such as CSS Width, trigger re-layout and are not supported independently.
State of the animating element doesn’t follow independent animation guidelines: Independent animations that don’t follow the guidelines (see Animating post) are not supported by the system.
Insufficient system resources: If the system doesn’t have sufficient resources (e.g. Video memory) then the animation falls back to dependent composition.

Here are a few guidelines for independent animations.

JavaScript

Avoid infinite animation: When using independent animations, the GPU is allocating video memory. In CSS it is possible to specify –ms-iteration-count: infinite. When you set this property value, the specified animation will continue to run forever. This means your app holds on to the animating element’s video memory until you stop the animation. To stop an infinite animation, you can remove the –ms-animation-name value or change the animating element’s display property to be display: none.
Don’t toggle the CSS Visibility property: When you set an independent animating element to visibility: hidden and then back to visibility: visible, this element is no longer independent. The animation continues but now it is composed on the UI thread.
Place independent animating elements on top: Because independent composition uses your GPU, there is a limit to how much your system can compose independently. If your independent animation is behind other UI elements, those UI elements on top will also be composed independently. By doing this you are unnecessarily consuming video memory. To avoid this problem, make sure to have all independent animations on top of all other UI elements. If your independent animation is very low in the stack, it is at risk of falling back to a dependent animation.

You can have your independent animations on top by:
- Giving your independent animating elements a high z-index.
- Using non-negative z-indexes for independently animating elements.
- Not overlapping your independent animation with other elements.
Don’t use large surfaces and too many independent animations: Similar to making placing your independent animation on top, be aware of how big your animating element is and how many you are animating at one time. Independent animations are limited by the system’s GPU. If you go beyond this limit, your animations fall back to the dependent UI thread. If you are noticing your animations not being smooth, you can use the IsIndependentlyComposed API to query your element.
Use IsIndependentlyComposed API: You can use this API to determine if an HTML element is being composed independently from the UI thread. This property will return true for independentl animating elements, subscrollers and elements that overlap and independently animating element.

XAML

Scale the elements for Height and Width animations: Animating Height and/or Width properties of UIElement results in a dependent animation because these properties require layout changes which can only be done on the UI thread. To have a similar effect of animating Height or Width, you can animate the Scale of the control. ScaleTransform are animated independently, this approach provides for a better frame rate.
Don’t animate cache content: If you set the CacheMode property (UIElement.CacheMode) of an element to BitmapCache, then all animations in the visual sub-tree are run dependently. This is because we have to recreate the entire cache in every frame. The solution is to simply not animate cached content.
Don’t use infinite animations of Progress controls: ProgressRing and ProgressBar have infinite animations that can continue on running even if the control is not visible in the page, which may prevent the CPU from going into low power or idle mode. We recommend that you set ProgressRing.IsActive and ProgressBar.IsIndeterminate properties to false when you’re not showing the respective controls.

In closing

We are excited about the fast and fluid user experiences that independent animation enables for Windows 8 apps. We hope that you find the Animation Library and the support for custom animations that run independently of the UI thread useful when you create compelling user experiences in your Metro style apps for Windows 8.

– Angelina Gambo and Hamid Mahmood

Program Managers, Windows

Windows 8 app developer blog

Windows 8 Tips and Tricks » Style

Building your own Windows Runtime components to deliver great Metro style apps

The basics

Why build your own Windows Runtime components

Using Win32 and COM APIs in your Metro style app

Computationally Intensive Operations

Libraries

Scenario 1: Enhancing your app with native audio

Adding the Windows Runtime component to our solution

Defining the class exposed to our XAML C# project

Implementing the class exposed in our Windows Runtime component

Adding and consuming the Windows Runtime component

Scenario 2: Using built-in APIs to open a zip file from your app

Adding the Windows Runtime component to our solution

Implementing the class exposed in our Windows Runtime component

Adding and consuming the Windows Runtime component

General guidance

In closing

References

Using HTML controls to create great Metro style apps

The Windows 8 button

Apply Metro style look and feel

New HTML controls infrastructure

Metro style look by default

Design for touch

Finger is not precise

No aim feedback

Pressed state

Cancelling

More than a click

Fundamentals: globalization and accessibility

Font support

Picking the right resources

Built-in accessibility

Make your app fast and fluid

Integrated tooling

Summary

Testing Metro style apps in Windows 8

Verify activation behavior of the app

Verify runtime behavior of the app

Tiles

Toast notifications

Contracts and extensions

Windows App Certification Kit

Snapped and fill views

Rotation

Touch

Playing audio

Different screen sizes

Data roaming

Devices and sensors

Performance

Responsiveness

Being a good citizen in the app ecosystem

Error handling

Reliability

Accessibility

Globalization and localization

Processor architectures

Verify suspension behavior of the app

Verify resumption behavior of the app

Verify termination behavior of the app

Verify app behavior when not running

Tiles

Toast notifications

Background tasks

Conclusion

Creating Metro style apps that stand out from the crowd

Example: Food with friends

1. Identifying the differentiation points

2. Picking the right scenarios

3. Creating the landing experience

4. Designing the sections

5. Laying out the rest of your app

6. Navigating the UI

Summary

Readying Metro style apps for launch

The Windows 8 Dev Center: Everything you need to design, build, and sell a Metro style app

The structure and navigation

Get started