Windows 8 Release Preview users find an option to turn fast startup on or off in the power options control panel applet. Fast startup, also known as hybrid boot, basically prepares the system for a faster startup the next time by moving important system files into the hiberfil.sys file so that they can be loaded faster during the next system boot.

This only works when you shut down the system, and is activated by default. It appears that Microsoft seems to have removed the option in the Windows 8 RTM, giving users no option in the control panel to control the fast startup feature.

It can happen that fast startup may cause the operating system to run check disk verifications during startup on dual boot systems, which is why it is usually suggested to turn fast boot off on multi-boot Windows installations.

You need to modify two entries in the Registry to turn off Fast Boot in the final version of Windows 8. Open the Windows Registry editor with Windows-r, enter regedit and hit enter, or enter regedit on the new start page of the operating system and select the Registry editor this way.

• Navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Power
• Locate the key HiberbootEnabled and double-click on it
• Set the value of the key to 0 to deactivate fast boot
• To restore the setting at a later time, change it back to 1.
• Navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
• Locate HiberbootEnabled there and double-click the entry
• Change the value of the key to 0 to deactivate Fast Boot.
• To restore the key to its original value at a later time, set it back to 1

Windows 8 from the next restart on will no longer use Fast Boot when the system is shut down. Again, I’d only recommend to turn fast boot off if you are noticing issues with check disk during startup. If you are dual booting Windows 7 and 8 for instance, and not noticing any issues, then it is not recommended to turn the feature off. (via Deskmodder)

How to disable Fast Start in Windows 8 was posted on Everything Microsoft – Latest Microsoft News, Guides, Reviews & Themes. If you are not reading this content in an email newsletter, it is being used without permission.

Everything Microsoft – Latest Microsoft News, Guides, Reviews & Themes

Posted on Everything Microsoft – Latest Microsoft News, Guides, Reviews & Themes

Microsoft has been working on improving the boot process of the Windows operating system ever since the company started working on Windows 7. Windows XP users who upgraded or purchased a PC with Windows Vista noticed longer boot times, which Microsoft managed to reduce again to XP levels in Windows 7. Improvements continued to flow into the boot process, and thanks to new hardware like Solid State Drives and UEFI, PCs with Windows 8 boot a lot faster than their older versions. It still depends a lot on the hardware, but Microsoft managed to boot into Windows 8 in seven seconds on PCs with UEFI and SSDs.

Everything is golden if you want to boot in the operating system, but what if you do not want to do that? What if you want to open recovery and repair options by pressing the F8 key? Microsoft notes in a new blog post that Windows users have 200ms for that, and that the fastest typers in the company managed to hit a key roughly every 250ms. That’s a problem for a number of reasons, from Microsoft employees frantically hammering away on the F8 key to get it right, and restarting if not, to less time for information to be displayed on the screen.

Microsoft is addressing the issue in three different ways:

• A single menu for every boot option
• Loading the boot menu automatically when problems are recognized by Windows 8
• Options to load the boot options menu from within the Windows 8 operating system.

A single boot menu

The core vision behind the boot options menu is to create a single place for every option that affects the startup behavior of the Windows 8 PC.

The main boot menu displays the following options:

• Continue – Exit and continue to Windows 8
• Use a device – Use a USB drive, network connection, or Windows recovery DVD
• Use another operating system – Continue with another installed version of Windows
• Troubleshoot – Refresh or reset your PC, or use advanced tools
• Turn off your PC

The advanced options display links to System Restore, the Command Prompt, System Image Recovery, Automatic Repair, UEFI Firmware Settings on UEFI systems, and Windows Startup Settings

Loading the boot menu automatically when problems are recognized by Windows 8

Windows 8 basically comes with diagnostic tools that analyze the operating system’s startup and operations. When diagnostics notices issues, for instance if the PC fails to boot into Windows 8, or of a faulty driver has been installed, it will automatically display the Windows 8 boot menu.

In Windows 8, this automatic failover behavior will take you directly to the boot options menu whenever there is a problem that would otherwise keep your PC from loading Windows. This even includes cases where it appears (to Windows) that boot has succeeded, but in actuality the PC is unusable. An example of how this could occur would be a faulty driver installation that is causing the main logon screen to appear completely blank. Windows may not be aware that the screen is blank, but anyone looking at the screen knows this immediately. We now algorithmically detect when this has occurred across multiple boots, and automatically boot directly into the boot options menu inside the Windows Recovery Environment (WinRE). Since the source image for WinRE contains drivers and files that are kept separate from the main Windows installation, it’s not affected by any software changes and is a reliable environment to begin troubleshooting from the boot options menu.

Options to load the boot options menu from within the Windows 8 operating system

Sometimes you may want to display the boot options even if the system does not detect issues. You may want to boot to another device, or make changes to the UEFI configuration. You can configure Windows 8 to display the boot menu on the next start of the operating system.

The primary method of reaching the boot options is from Advanced startup on the General tab of PC settings. You can get to PC settings from the Settings charm, or by searching from the Start screen using specific search terms, such as boot, startup, safe mode, firmware, BIOS, or several others. On the General tab, you’ll see a short description of the options that will be available in the boot options menu, as well as a Restart now button. The descriptions shown on this screen are fully dynamic, and will change based on the hardware, firmware, and software available on your specific Windows 8 PC.

Other options to get Windows 8 to display the boot menu are:

• Shift-clicking on the Restart link under Power
• Running the command shutdown /r /o from the command line

Can a operating system boot to fast? Not really if you ask me. It is great that Microsoft continues to work on improvements in this area. We will hopefully see more of the new boot menu in the Windows 8 Release Preview, which is rumored to come out on June 1.

You can read the full announcement over at the Building Windows 8 blog

Windows 8 Boots too fast was posted on Everything Microsoft – Latest Microsoft News, Guides, Reviews & Themes. If you are not reading this content in an email newsletter, it is being used without permission.

Everything Microsoft – Latest Microsoft News, Guides, Reviews & Themes

App launch overview

If you’ve already read the Managing app lifecycle so your apps feel “always alive” post, you should be familiar with app lifecycle states. This post targets app launch, or the transition between the “not running” and “running” state.

  Lifecycle states: app launch is the transition from the “not running” to “running” state.

Because app launch is highly visible, it’s important to plan this transition well. Not only is the transition front-and-center, but users will experience it repeatedly. The more contracts (see past post: Activating Windows 8 contracts in your app) you implement, the more reasons users will have to launch your app. Whether you make a positive or negative first impression will depend on how you’ve designed this transition; it may also, ultimately, determine whether users routinely return to your app.

Before I recommend a few ways to handle app launch, it might be useful to review the sequence of operations during this transition.

  The sequence of operations during app launch.

When users launch an app, they are immediately greeted by the splash screen. Every Metro style app has a splash screen, which consists of a 620×300 image and solid background color. (See Quickstart: Adding a splash screen to learn how to customize your splash screen.) Windows presents the splash screen on your behalf in order to welcome users while your app is activated. The activated event is received by all apps on launch, and gives your app the ability to perform any initialization work needed to present its initial UI. This might include reading basic settings, determining what page to navigate to, and/or identifying whether the app was activated for one of the various contracts. After initialization is complete and your app is ready to dismiss the splash screen, it must present its first window. No work is required for JavaScript apps, as this is done automatically when the activation callback returns. C# apps, however, must do this explicitly through a call to Window.Current.Activate. Be careful not to delay this operation, as your app will be terminated if a window is not displayed within a reasonable amount of time (~15 seconds). In addition, you’ll want to present a window as fast as possible because unnecessarily keeping the splash screen up can quickly deteriorate the user experience. We recommend that you present a window within 2-3 seconds to ensure that your app will always launch as expected, even on low-end hardware.

After the app’s window is presented and the splash screen is dismissed, apps take control of the experience; it is up to you to determine how users will be introduced to your app’s content. Depending on the app, different transitions might be appropriate. In the next few sections, I’ll recommend four app launch design patterns that can be applied based on your app’s needs:

• Default app launch

For apps that don’t require additional loading and are immediately ready to use.

Ex: A dictionary app that enables users to look up or translate various terms. The landing page consists only of a textbox for user input.

• Skeleton app launch

Great for apps that fill the landing page incrementally on launch.

Ex: A reading app that tracks the user’s books, magazines, and newspapers. When launched, the app incrementally populates the user’s library.

• Extended app launch

For apps that perform lengthy loading operations before presenting UI. This might include network calls or substantial file I/O.

Ex: A sports app that shows the latest scores and highlights. The app uses REST APIs to retrieve this information over the network and displays live data on the landing page.

• Deferred app launch

Useful for apps that need to complete basic asynchronous tasks on launch, like querying app settings to check for first-run.

Ex: A game that needs to determine whether the user has already created an account. This information is needed to determine which page to present to the user.

Default app launch

For many apps, the default app launch flow will be optimal. In this flow, Windows handles the display and removal of each app’s splash screen. The splash screen is displayed until activation completes and a window is presented, triggering an animated crossfade to the app’s landing page. Use default launch if your landing page is static and doesn’t depend on additional loading operations. If your content is ready immediately, there’s no need to artificially delay the user. In fact, you shouldn’t!

Below is an example of the default launch flow using Internet Explorer 10 from Consumer Preview. When the app is launched, the splash screen is immediately displayed to the user. The splash screen stays visible on the screen until the app is activated, at which point the splash screen fades out into the landing page. In this case, the landing page shows the last page visited by the user, which is readily available because it was saved during the previous session.

Here’s the process displayed in the following image:

1. App tile clicked.
2. Splash screen displayed.
3. App landing page displayed.

 
The default app launch flow.

To implement the default launch flow, no additional work is required. Simply specify your 620×300 splash screen image in your app’s manifest and then design the landing page using static content. After activation completes, the splash screen will fade out into your landing page and your app will be ready to use.

Skeleton app launch

For a majority of apps, default launch will work great. After the splash screen is dismissed, the app will be running and ready for interaction. Some apps, however, might not be entirely ready at this point; these apps will need to load content dynamically after they launch. For this class of app, the skeleton app launch pattern is a great way to provide meaningful loading information to users, while bringing them into the app as quickly as possible. In this pattern, the splash screen dismisses to a skeleton landing page (the landing page, as it would look, without any content), while content is retrieved. By adding a progress bar to the page, you can indicate that the app is still loading. This next image shows an example of the skeleton launch flow using the Music app from Consumer Preview. Here, the skeleton landing page is displayed while the latest music content is retrieved.

Here’s the process displayed in the following image:

1. App tile clicked.
2. Splash screen displayed.
3. Skeleton landing page displayed. Note the progress bar displayed at the top of the view.
4. App landing page displayed.

  The skeleton app launch flow.

To implement the skeleton launch flow, create a static, skeleton view of your app’s landing page and display it as your start page. Then, during activation, begin executing the loading tasks needed to fill the page with content. Because most operations are asynchronous, the splash screen might be torn down while these tasks are still executing. As a result, your users will see the landing page fill incrementally.

If you are interested in learning when the splash screen has been dismissed, you can use the splash screen API. The API includes the SplashScreen.Dismissed event, which indicates when the transition from splash screen to app start page has occurred. This may be useful if you want to know when your skeleton landing page is in view.

JavaScript

As you will see in the following example, your app can begin executing operations to fill the landing page inside of the activated callback. To optionally learn when the splash screen is dismissed, use the activated event args to obtain the splash screen object. Using this object, register for the dismissed event to be notified of splash screen dismissal.

app.onactivated = function (eventArgs) {
    if (eventArgs.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {
        // Begin executing setup operations.
        performSetupTasks();

        // Retrieve splash screen object.
        var splash = eventArgs.detail.splashScreen;

        // Register an event handler to be executed when the splash screen has been dismissed.
        splash.addEventListener("dismissed", onSplashScreenDismissed, false);
        ...
    }
};

function performSetupTasks() {
    // Begin additional loading tasks here…
    ...
}

function onSplashScreenDismissed() {
    // The splash screen has dismissed and the skeleton landing page is now in view.
    ...
}

C#

Implementation is no different in C#. Begin operations that are necessary to fill the landing page during activation. Then, optionally obtain the splash screen object from the activated event args and register to be notified of splash screen dismissal.

async protected override void OnLaunched(LaunchActivatedEventArgs args)
{
    // Begin executing setup operations.
    PerformSetupTasks();

    // Retrieve splash screen object.
    SplashScreen splashScreen = args.SplashScreen;

    // Register an event handler to be executed when the splash screen has been dismissed.
    splashScreen.Dismissed += new TypedEventHandler<SplashScreen, object>(eSplash.onSplashScreenDismissed);
    ...
}

internal void PerformSetupTasks()
{
    // Begin additional loading tasks here…
    ...
}

internal void onSplashScreenDismissed(Windows.ApplicationModel.Activation.SplashScreen sender, object e)
{
    // The splash screen has dismissed and the skeleton landing page is now in view.
    ...
}

Extended app launch

For apps that perform additional loading tasks post-launch, skeleton app launch is a great option. That said, it does have one downside: because users are brought to the “skeleton” page immediately, the collective loading flow might feel disjointed. The transition from splash screen to skeleton landing page may give users the impression that there are two, independent loading operations. When this is undesirable, the extended app launch pattern is a great alternative.

This flow uses the concept of an extended splash screen to produce one, seamless loading experience. When the regular splash screen is dismissed, the app displays an extended splash screen instead of the landing page. The extended splash screen is owned entirely by the app and is formatted using the splash screen API. The API provides positioning information that ensures the look and feel of the extended splash screen is visually identical to the splash screen (with the exception of a progress ring or loading details), which unifies the seemingly independent loading operations. While the extended splash screen is up, the app can continue executing tasks needed to paint the landing page. Then, after loading is complete, you can transition from the extended splash screen to the landing page.

The extended launch flow works especially well if initialization could be lengthy (network connectivity, for example, is unpredictable). If you need to do any sort of “heavy lifting” during launch, the extended splash screen is the ideal choice. It’s also a great choice if you want to ensure that your landing page has been fully updated before transitioning to it (if you choose not to show cached data).

This next example shows the extended launch flow using the Weather app from Windows 8 Consumer Preview. A Weather app is a great example of an app that might implement the extended launch pattern, because the extended splash screen can be shown while the latest weather data is requested from the network (there’s not much value in showing the user cached weather data).

Here’s the process displayed in the following image:

1. App tile clicked.
2. Splash screen displayed.
3. Extended splash screen displayed (with progress ring).
4. App landing page displayed.

 
The extended app launch flow.

To implement the extended launch flow, the splash screen API must be used. Using SplashScreen.ImageLocation, apps can obtain the image coordinates for the splash screen image. This is important, as the image must be positioned in the exact same location in the extended splash screen for the user to perceive a smooth transition. As mentioned in the previous section, the API also exposes a SplashScreen.Dismissed event, which will notify you of the transition from regular splash screen to your extended splash screen.

Like before, you can trigger additional tasks during activation. Below, we’ll walk through the implementation of an extended splash screen (with an optional progress ring) in both JavaScript and C#.

Note: When implementing an extended splash screen, it’s also important to handle snapping, unsnapping, rotation, and so on. These details are omitted in this post for the sake of brevity. To learn more, see the splash screen sample.

JavaScript

First, add HTML markup for the extended splash screen (with progress ring) to your start page.

<div id="extendedSplashScreen" class="extendedSplashScreen hidden">
    <img id="extendedSplashImage" src="/images/splash.png"  style="position: absolute;" />
    <progress id="extendedSplashProgress" style="color: white;" class="win-medium win-ring"></progress>
</div>

 

Next, add CSS styles for the extended splash screen.

.extendedSplashScreen {
    position: absolute;
    text-align: center;
    background-color: #000000;
    height: 100%;
    width: 100%;
    top: 0px;
    left: 0px;
}
.extendedSplashScreen.hidden {
    display: none;
}

Again, start additional tasks during activation and use the activated event args to obtain the splash screen object. This time, the splash screen object will be used to both register for the dismissed event and to set up the extended splash screen. Query the splash screen object for the position of the splash screen image and arrange the layout accordingly.

app.onactivated = function (eventArgs) {
    if (eventArgs.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {
        // Begin executing setup operations.
        performSetupTasks();

        // Retrieve splash screen object.
        var splash = eventArgs.detail.splashScreen;

        // Register an event handler to be executed when the regular splash screen has been dismissed.
        splash.addEventListener("dismissed", onSplashScreenDismissed, false);

        // Display the extended splash screen.
        displayExtendedSplash(splash);

        WinJS.UI.processAll();
    }
};

function displayExtendedSplash(splash) {
    // Position the extended splash screen image in the same location as the system splash screen image.
    var extendedSplashImage = document.getElementById("extendedSplashImage");    
    extendedSplashImage.style.top = splash.imageLocation.y + "px";
    extendedSplashImage.style.left = splash.imageLocation.x + "px";
    extendedSplashImage.style.height = splash.imageLocation.height + "px";
    extendedSplashImage.style.width = splash.imageLocation.width + "px";

    // Position the extended splash screen's progress ring.
    var extendedSplashProgress = document.getElementById("extendedSplashProgress");
    extendedSplashProgress.style.marginTop = splash.imageLocation.y + splash.imageLocation.height + 32 + "px";
        
    // After the extended splash screen is set up, 
    // apply the CSS style that will make the extended splash screen visible.
    var extendedSplashScreen = document.getElementById("extendedSplashScreen");
    WinJS.Utilities.removeClass(extendedSplashScreen, "hidden");
}

Specify the loading tasks to be completed while the extended splash screen is up. When loading is complete, tear down the extended splash screen. Make sure to handle error cases gracefully; if loading tasks timeout or fail, transition the user to a page that explains what’s happened.

function performSetupTasks() {
    // Begin additional loading tasks here…
    ...

    // Tear down the extended splash screen after all operations are complete.
    removeExtendedSplash();
}

function onSplashScreenDismissed() {
    // The splash screen has been dismissed and the extended splash screen is now in view.
    ...
}

function removeExtendedSplash() {
    var extendedSplashScreen = document.getElementById("extendedSplashScreen");
    WinJS.Utilities.addClass(extendedSplashScreen, "hidden");
}

C#

Like JavaScript, we need to add markup for the extended splash screen with progress ring. This time, we’ll use XAML.

<!-- This snippet represents the ExtendedSplash class -->
<Canvas Grid.Row="0">
    <Image x:Name="extendedSplashImage" Source="images/splash.png" />
    <ProgressRing x:Name="ProgressRing" Foreground="White" 
HorizontalAlignment="Center" IsActive="True" 
        MaxHeight="30" MinHeight="30" MaxWidth="30" 
MinWidth="30"></ProgressRing>
</Canvas>

Again, we’ll start by kicking off loading tasks in activation. We’ll then obtain the splash screen object from the activated event args and display the extended splash screen.

async protected override void OnLaunched(LaunchActivatedEventArgs args)
{
    // Begin executing setup operations.
    PerformSetupTasks();

    // Retrieve splash screen object.
    SplashScreen splashScreen = args.SplashScreen;

    ExtendedSplash eSplash = new ExtendedSplash(splashScreen);

    // Register an event handler to be executed when the splash screen has been dismissed.
    splashScreen.Dismissed += new TypedEventHandler<SplashScreen, object>(eSplash.onSplashScreenDismissed);
    ...

    Window.Current.Content = eSplash;
    Window.Current.Activate();
}

public ExtendedSplash(SplashScreen splash)
{
    InitializeComponent();

    // Position the extended splash screen image in the same location as the splash screen image.
    this.extendedSplashImage.SetValue(Canvas.LeftProperty, splash.ImageLocation.X);
    this.extendedSplashImage.SetValue(Canvas.TopProperty, splash.ImageLocation.Y);
    this.extendedSplashImage.Height = splash.ImageLocation.Height;
    this.extendedSplashImage.Width = splash.ImageLocation.Width;

    // Position the extended splash screen's progress ring.
    this.ProgressRing.SetValue(Canvas.TopProperty, splash.ImageLocation.Y + splash.ImageLocation.Height + 32);
    this.ProgressRing.SetValue(Canvas.LeftProperty,
 splash.ImageLocation.X +
         (splash.ImageLocation.Width / 2) - 15);
}

Perform necessary loading tasks while the extended splash screen is on screen, and then navigate to the landing page.

internal void PerformSetupTasks()
{
    // Begin additional loading tasks here…
    ...

    // Tear down the extended splash screen after all operations are complete.
    RemoveExtendedSplash();
}

internal void onSplashScreenDismissed(Windows.ApplicationModel.Activation.SplashScreen sender, object e)
{
    // The splash screen has been dismissed and the extended splash screen is now in view.
    ...
}

void RemoveExtendedSplash()
{
    Window.Current.Content = new LandingPage();
}

Deferred app launch

The final launch pattern I’ll discuss is deferred app launch. Deferred launch is similar to extended launch in that it enables the preparation of the landing page before transitioning away from the splash screen experience. Instead of displaying an “extended” splash screen, however, the app defers dismissal of the regular splash screen until asynchronous tasks have been executed. Because apps have limited time to complete this deferral, the deferral pattern should be used sparingly, and mainly to complete simple asynchronous operations like reading app settings before the app is displayed. Furthermore, if you fail to appropriately handle errors/exceptions during this time, it’s possible that launch will be terminated. Accordingly, if your app needs to make network calls or process large amounts of data, the skeleton or extended app launch pattern should be used instead.

Below is an example of deferred launch, using the Photos app from Consumer Preview. When a .jpg file is opened from the desktop, the Photos app is launched as the default handler for this file type. The Photos app uses deferral to load the image thumbnail before the splash screen is dismissed. This is an acceptable use of deferral as the thumbnail retrieval operation can be completed relatively fast. Then, after the user is in the app, the higher-res image can be acquired asynchronously to replace the thumbnail. This flow ensures that when the user transitions to the app, the thumbnail is already on screen.

Here’s the process displayed in the following image:

1. The .jpg image is clicked (Photos is the default .jpg handler).
2. Splash screen displayed.
3. Activation deferred, while thumbnail is retrieved.
4. App displayed with thumbnail in view.

 
The deferred app launch flow.

To implement the deferred launch flow in JavaScript, activation deferral must be used. Deferral gives apps the ability to defer the completion of activation until asynchronous operations are completed. Otherwise, activation is completed when the callback returns. Because most Windows Runtime APIs are asynchronous, this is useful for apps that want to make sure things are done prior to the display of the app’s initial UI. In C#, apps can implement deferral by delaying the Window.Current.Activate call. Below, we’ll demonstrate both approaches.

JavaScript

There are two ways to implement activation deferral in JavaScript, depending on how your app handles activation.

If your app uses WinJS to handle activation (default for VS project templates), use the following code. Calling setPromise on the activation event args delays the completion of activation until both asynchronous calls (WinJS.UI.processAll and asyncOperation) have completed.

app.onactivated = function (eventArgs) {
    if (eventArgs.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {
        eventArgs.setPromise(WinJS.UI.processAll().then(function() {
            return asyncOperation().done(function () { });
        }));
    }
};

If you manually register to handle the activated event, the ActivatedOperation.getDeferral method can be used. Below, a deferral object is obtained during activation and complete is called after all async work is complete.

Note: Complete must be called regardless of whether the async call succeeds. If complete isn’t called, the app will never return from activation and app launch will timeout. This is a common pitfall when using this pattern; it’s crucial that your app handles all error cases.

Windows.UI.WebUI.WebUIApplication.addEventListener("activated", onActivated, false);
function onActivated(eventArgs) {
    if (eventArgs.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {
        var deferral = eventArgs.activatedOperation.getDeferral();
        asyncOperation().done(function () {
            deferral.complete();
        }, function (error) {
            deferral.complete();
        });
    }
}

C#

To implement deferral in C#, simply postpone the Window.Current.Activate call until your loading operations have completed. Remember – just like JavaScript – you must only delay this call briefly to complete simple operations. If your app doesn’t successfully activate its window within a reasonable amount of time, launch will timeout. Additionally, lengthy delays will negatively impact the perceived performance of your app, which will not endear you to users.

protected override async void OnLaunched(LaunchActivatedEventArgs args)
{
    // Create a frame to act navigation context and navigate to the first page.
    var rootFrame = new Frame();
    rootFrame.Navigate(typeof(BlankPage));

    // Place the frame in the current Window and ensure that it is active.
    Window.Current.Content = rootFrame;

    // Use “await” to execute an async operation prior to activating a window.
    // Remember, avoid lengthy operations here.
    await asyncOperation();

    Window.Current.Activate();
}

Conclusion

In this post, we discussed a few techniques for producing an elegant launch experience. To differentiate your app’s look and feel, we reviewed four specific design patterns that can be applied to any Metro style app. As you continue to build your apps, remember to prioritize app launch and use the patterns outlined in this post. After all, it’s your first chance to make a memorable impression on users.

For more info about activation, splash screens, or app lifecycle see the following resources:

–Justin Cooperman, Program Manager, Windows User Experience

Windows 8 app developer blog

Fast and fluid apps must be responsive

How many times have you been using a Windows app that stops responding, and you are presented with a greyed version of the app and the spinning donut? Without fail, it always seems to come at the worst possible time. Worse yet, you might end up losing a lot of hard work when this happens.

Users expect apps to be responsive to all interactions. When they use their favorite news reading app, they want to add news feeds, read news articles, save news articles, etc. They should be able to do all of these things even when the app is retrieving the latest articles from the Internet.

This becomes especially important when a user is interacting with your app using touch. Users notice when the app doesn’t “stick to your finger.” Even minor performance problems can degrade the user experience and break the fast and fluid feeling.

An app isn’t fast and fluid if it stops responding to user input. So why do apps stop responding? One major cause is that the app is synchronous; it is waiting for something else to finish (like getting data from the Internet) and can’t respond to your input.

Many modern apps connect to social websites, store data in the cloud, work with files on the hard disk, communicate with other gadgets and devices, etc. Some of these sources have unpredictable latencies, which makes creating fast and fluid apps challenging. Unless built correctly, apps spend more time waiting for the outside environment and less time responding to the user’s needs.

Addressing this connected world was a core principle when we started to design APIs for the Windows Runtime (WinRT). We felt it was important to provide an API surface that was powerful and led to fast and fluid apps by default.

To achieve those goals, we made many potentially I/O-bound APIs asynchronous in the Windows Runtime. These are the most likely candidates to visibly degrade performance if written synchronously (e.g. could likely take longer than 50 milliseconds to execute). This asynchronous approach to APIs sets you up to write code that is fast and fluid by default and promotes the importance of app responsiveness in Metro style app development.

For those of you unfamiliar with asynchronous patterns, think of asynchrony in WinRT as providing a callback number to somebody over the phone. You give the person the number to call you back, you hang up, and then you continue doing any other work you need to. When the person is ready to talk to you, they can call you back at the number you provided. This is the essence of how asynchrony works in WinRT.

To understand more about the asynchronous nature of WinRT, we will first look at how you can use these asynchronous APIs in a straightforward way. Then we will take an under the hood look at what async primitives WinRT has introduced (that the new language features build upon), and how they work.

How to use it: new developer enhancements for asynchrony

In the past, writing asynchronous code was difficult. Our teams building tools for Windows 8 Metro style apps made significant advancements in solving this problem in recent releases. In the .NET Framework 4.0, we introduced the Task Parallel Library. Then the await keyword was introduced into C# and Visual Basic. C++ invested in technologies like the Parallel Patterns Library (PPL). And JavaScript has great tools like Promises.

Each one of these technologies presents you with a straightforward way to write asynchronous code. By introducing a standard async pattern under the hood that all of these technologies use, we allow you to use these technologies when building Metro style apps regardless of which programming language you use.

In the case of your favorite news app, the code that remains responsive while retrieving news articles is quite simple using the Windows.Web.Syndication.SyndicationClient API. The call to RetrieveFeedAsync returns immediately. This is a great thing because the results might take a long time to come back from the Internet. In the meantime, the UI continues to interact with the user.

The code highlighted in yellow runs after the call to RetrieveFeedAsync is completed. You don’t need to think about all the “start again where you left off” plumbing. And the code is written in a straightforward way as if it was synchronous.

C# code to retrieve RSS feed asynchronously:

There is no mention of threads, context switching, dispatchers, etc. These new developer enhancements for writing asynchronous code will handle that for you. Code following the async API call is automatically called back in the same context that the original call was made. This means you can go ahead and update the UI with the results without worrying about getting back to the UI thread.

How to use it: error handling

Of course, API calls can fail (like losing network connectivity while retrieving RSS feeds). To be truly robust, we need to be resilient in the presence of errors. Using the async functionality in the languages makes handling errors more straightforward. The mechanism to do this varies based on the language.

For JavaScript, we recommend that you always end your Promise chains with done. This ensures that any exceptions captured in the promise chain are visible to the developer (i.e. reported in the error handler, or thrown). Done has the same signature as then. So to handle errors, you simply pass an error delegate into done():

To handle the exception in C# or Visual Basic, you use a try/catch block just as you do with synchronous code today:

The most common method to use in C++ to handle async errors is to use another task-based continuation that throws the exceptions (you can find other methods for error handling in C++ in the topic Asynchronous Programming in C++ on Dev Center):

For more details on how to use these asynchronous improvements (including more scenarios like support cancellation and progress) see:

• Asynchronous Programming in the Windows Runtime on the Windows Dev Center
• Asynchronous Programming in JavaScript on the Windows Dev Center
• Asynchronous Programming in C++ on the Windows Dev Center
• Asynchronous Programming in .NET on the Windows Dev Center
• How to Handle Errors when using Promises in JavaScript on the Windows Dev Center

How it works: WinRT async primitives

Async is very powerful, but it can appear that there is a lot of magic that happens here on your behalf. To demystify what is happening, let’s take a look at how asynchrony in WinRT works in a little more detail. Our first step is to investigate the primitives the model is built upon. Most of you won’t have to use these primitives at all (if you find a scenario where you have to do this, we would love to hear the feedback).

Starting with our C# code, let’s look at the actual return type of RetrieveFeedAsync (shown here in C# Intellisense):

 
 Figure 1. Intellisense displayed for RetrieveFeedAsync method

RetrieveFeedAsync returns an IAsyncOperationWithProgress interface. IAsyncOperationWithProgress is one of 5 interfaces that define the core asynchronous programming surface for WinRT: IAsyncInfo, IAsyncAction, IAsyncActionWithProgress, IAsyncOperation, and IAsyncOperationWithProgress.

The core interface that the WinRT async model is built on is IAsyncInfo. This core interface defines properties of an async operation like current status, the ability to cancel the operation, the error of a failed operation, etc.

As we mentioned earlier, async operations can return results. Async operations in WinRT can also report progress as they are running. The other 4 async interfaces above (IAsyncAction, IAsyncActionWithProgress, IAsyncOperation, and IAsyncOperationWithProgress) define different combinations of results and progress.

   
Figure 2. Different combinations of results and progress

Providing core async primitives in the Windows Runtime enables C#, Visual Basic, C++, and JavaScript to project WinRT async operations in a familiar way to you.

Note: The move from cold start to hot start

In the Windows 8 Developer Preview released at //build, all async operations in WinRT were started cold. They didn’t start running immediately. They had to be explicitly started by the developer or implicitly started using the async features in C#, Visual Basic, JavaScript, or C++. We received feedback from several sources that this wasn’t intuitive and could cause pain and confusion.

In the Windows 8 Consumer Preview release, you will notice that we removed the Start() method from the WinRT async primitives. Now, our async operations are all started hot. So, the async method launched the operation before returning it to the caller.

This is just one of many changes that you’ll find in the Consumer Preview where we’ve fine-tuned the developer platform based on all the great feedback you have given us.

How it works: results, cancellation, and errors with async primitives

An async operation starts in the Started state and can progress to one of three other states: Canceled, Completed, and Error. The current state of an async operation is reflected in the Status property of the async operation (represented by the AsyncStatus enum type).

The first thing we do with an async operation is wire up a completed handler. From within the completed handler, we can get the results and use them.

Sometimes you may want to cancel an operation. You can do this by calling the Cancel method on the async operation.

The Completed handler is always called for an async operation regardless of whether it was completed, canceled, or resulted in an error. Call GetResults only when the async operation was completed (e.g. not when the operation is canceled or ends in an error). You can determine this by inspecting the status parameter.

This code still isn’t robust if the operation failed. Just like cancellation, error reporting is supported through the same async operation. As well as using AsyncStatus to differentiate between Completed and Canceled, we also use it to determine failure of an async operation (i.e. AsyncStatus.Error). You can find the specific failure code in the ErrorCode property of the async operation.

How it works: reporting progress with async primitives

Some WinRT async operations provide progress notifications while they are running. You can use these notifications to report the current progress of the async operation to the user.

In WinRT, progress reporting is handled through the IAsyncActionWithProgress<TProgress> and IAsyncOperationWithProgress<TResult, TProgress> interfaces. Each interface contains a Progress event that you can use to get progress reports from the async operation.

The programming model to consume this is nearly identical to consuming the Completed event. In our example of retrieving syndication feeds, we can report how many bytes of the total amount have been retrieved:

In this case, the second parameter (progress) is of type RetrievalProgress. This type contains two parameters (bytesRetrieved and totalBytesToRetrieve) that are used to report our ongoing progress.

For deeper material (involving asynchronous programming in WinRT, or asynchrony in general), you can check out:

• “Async Everywhere” talk from the //Build conference
• Asynchronous Programming in JavaScript with “Promises”
• Task-Based Asynchronous Pattern
• Asynchrony in .NET

In closing

What’s interesting about asynchrony being so prevalent in WinRT is how it impacts the way you structure your code and architect your app. You start thinking about your app in a more loosely-connected way. If you have any feedback in this area, we would love to hear from you! Let us know by leaving a comment here or on the Dev Center forums.

We want your customers to love your Windows 8 apps. We want those apps to start alive with activity, and remain alive with activity. And we want you to more easily create those apps. We want you to be able to easily connect to social websites, store data in the cloud, work with files on the hard disk, communicate with other gadgets and devices, etc., while providing your customers with a great user experience.

–Jason Olson

Program Manager, Windows

Windows 8 app developer blog

Fast and fluid apps must be responsive

How many times have you been using a Windows app that stops responding, and you are presented with a greyed version of the app and the spinning donut? Without fail, it always seems to come at the worst possible time. Worse yet, you might end up losing a lot of hard work when this happens.

Users expect apps to be responsive to all interactions. When they use their favorite news reading app, they want to add news feeds, read news articles, save news articles, etc. They should be able to do all of these things even when the app is retrieving the latest articles from the Internet.

This becomes especially important when a user is interacting with your app using touch. Users notice when the app doesn’t “stick to your finger.” Even minor performance problems can degrade the user experience and break the fast and fluid feeling.

An app isn’t fast and fluid if it stops responding to user input. So why do apps stop responding? One major cause is that the app is synchronous; it is waiting for something else to finish (like getting data from the Internet) and can’t respond to your input.

Many modern apps connect to social websites, store data in the cloud, work with files on the hard disk, communicate with other gadgets and devices, etc. Some of these sources have unpredictable latencies, which makes creating fast and fluid apps challenging. Unless built correctly, apps spend more time waiting for the outside environment and less time responding to the user’s needs.

Addressing this connected world was a core principle when we started to design APIs for the Windows Runtime (WinRT). We felt it was important to provide an API surface that was powerful and led to fast and fluid apps by default.

To achieve those goals, we made many potentially I/O-bound APIs asynchronous in the Windows Runtime. These are the most likely candidates to visibly degrade performance if written synchronously (e.g. could likely take longer than 50 milliseconds to execute). This asynchronous approach to APIs sets you up to write code that is fast and fluid by default and promotes the importance of app responsiveness in Metro style app development.

For those of you unfamiliar with asynchronous patterns, think of asynchrony in WinRT as providing a callback number to somebody over the phone. You give the person the number to call you back, you hang up, and then you continue doing any other work you need to. When the person is ready to talk to you, they can call you back at the number you provided. This is the essence of how asynchrony works in WinRT.

To understand more about the asynchronous nature of WinRT, we will first look at how you can use these asynchronous APIs in a straightforward way. Then we will take an under the hood look at what async primitives WinRT has introduced (that the new language features build upon), and how they work.

How to use it: new developer enhancements for asynchrony

In the past, writing asynchronous code was difficult. Our teams building tools for Windows 8 Metro style apps made significant advancements in solving this problem in recent releases. In the .NET Framework 4.0, we introduced the Task Parallel Library. Then the await keyword was introduced into C# and Visual Basic. C++ invested in technologies like the Parallel Patterns Library (PPL). And JavaScript has great tools like Promises.

Each one of these technologies presents you with a straightforward way to write asynchronous code. By introducing a standard async pattern under the hood that all of these technologies use, we allow you to use these technologies when building Metro style apps regardless of which programming language you use.

In the case of your favorite news app, the code that remains responsive while retrieving news articles is quite simple using the Windows.Web.Syndication.SyndicationClient API. The call to RetrieveFeedAsync returns immediately. This is a great thing because the results might take a long time to come back from the Internet. In the meantime, the UI continues to interact with the user.

The code highlighted in yellow runs after the call to RetrieveFeedAsync is completed. You don’t need to think about all the “start again where you left off” plumbing. And the code is written in a straightforward way as if it was synchronous.

C# code to retrieve RSS feed asynchronously:

There is no mention of threads, context switching, dispatchers, etc. These new developer enhancements for writing asynchronous code will handle that for you. Code following the async API call is automatically called back in the same context that the original call was made. This means you can go ahead and update the UI with the results without worrying about getting back to the UI thread.

How to use it: error handling

Of course, API calls can fail (like losing network connectivity while retrieving RSS feeds). To be truly robust, we need to be resilient in the presence of errors. Using the async functionality in the languages makes handling errors more straightforward. The mechanism to do this varies based on the language.

For JavaScript, we recommend that you always end your Promise chains with done. This ensures that any exceptions captured in the promise chain are visible to the developer (i.e. reported in the error handler, or thrown). Done has the same signature as then. So to handle errors, you simply pass an error delegate into done():

To handle the exception in C# or Visual Basic, you use a try/catch block just as you do with synchronous code today:

The most common method to use in C++ to handle async errors is to use another task-based continuation that throws the exceptions (you can find other methods for error handling in C++ in the topic Asynchronous Programming in C++ on Dev Center):

For more details on how to use these asynchronous improvements (including more scenarios like support cancellation and progress) see:

• Asynchronous Programming in the Windows Runtime on the Windows Dev Center
• Asynchronous Programming in JavaScript on the Windows Dev Center
• Asynchronous Programming in C++ on the Windows Dev Center
• Asynchronous Programming in .NET on the Windows Dev Center
• How to Handle Errors when using Promises in JavaScript on the Windows Dev Center

How it works: WinRT async primitives

Async is very powerful, but it can appear that there is a lot of magic that happens here on your behalf. To demystify what is happening, let’s take a look at how asynchrony in WinRT works in a little more detail. Our first step is to investigate the primitives the model is built upon. Most of you won’t have to use these primitives at all (if you find a scenario where you have to do this, we would love to hear the feedback).

Starting with our C# code, let’s look at the actual return type of RetrieveFeedAsync (shown here in C# Intellisense):

 
 Figure 1. Intellisense displayed for RetrieveFeedAsync method

RetrieveFeedAsync returns an IAsyncOperationWithProgress interface. IAsyncOperationWithProgress is one of 5 interfaces that define the core asynchronous programming surface for WinRT: IAsyncInfo, IAsyncAction, IAsyncActionWithProgress, IAsyncOperation, and IAsyncOperationWithProgress.

The core interface that the WinRT async model is built on is IAsyncInfo. This core interface defines properties of an async operation like current status, the ability to cancel the operation, the error of a failed operation, etc.

As we mentioned earlier, async operations can return results. Async operations in WinRT can also report progress as they are running. The other 4 async interfaces above (IAsyncAction, IAsyncActionWithProgress, IAsyncOperation, and IAsyncOperationWithProgress) define different combinations of results and progress.

   
Figure 2. Different combinations of results and progress

Providing core async primitives in the Windows Runtime enables C#, Visual Basic, C++, and JavaScript to project WinRT async operations in a familiar way to you.

Note: The move from cold start to hot start

In the Windows 8 Developer Preview released at //build, all async operations in WinRT were started cold. They didn’t start running immediately. They had to be explicitly started by the developer or implicitly started using the async features in C#, Visual Basic, JavaScript, or C++. We received feedback from several sources that this wasn’t intuitive and could cause pain and confusion.

In the Windows 8 Consumer Preview release, you will notice that we removed the Start() method from the WinRT async primitives. Now, our async operations are all started hot. So, the async method launched the operation before returning it to the caller.

This is just one of many changes that you’ll find in the Consumer Preview where we’ve fine-tuned the developer platform based on all the great feedback you have given us.

How it works: results, cancellation, and errors with async primitives

An async operation starts in the Started state and can progress to one of three other states: Canceled, Completed, and Error. The current state of an async operation is reflected in the Status property of the async operation (represented by the AsyncStatus enum type).

The first thing we do with an async operation is wire up a completed handler. From within the completed handler, we can get the results and use them.

Sometimes you may want to cancel an operation. You can do this by calling the Cancel method on the async operation.

The Completed handler is always called for an async operation regardless of whether it was completed, canceled, or resulted in an error. Call GetResults only when the async operation was completed (e.g. not when the operation is canceled or ends in an error). You can determine this by inspecting the status parameter.

This code still isn’t robust if the operation failed. Just like cancellation, error reporting is supported through the same async operation. As well as using AsyncStatus to differentiate between Completed and Canceled, we also use it to determine failure of an async operation (i.e. AsyncStatus.Error). You can find the specific failure code in the ErrorCode property of the async operation.

How it works: reporting progress with async primitives

Some WinRT async operations provide progress notifications while they are running. You can use these notifications to report the current progress of the async operation to the user.

In WinRT, progress reporting is handled through the IAsyncActionWithProgress<TProgress> and IAsyncOperationWithProgress<TResult, TProgress> interfaces. Each interface contains a Progress event that you can use to get progress reports from the async operation.

The programming model to consume this is nearly identical to consuming the Completed event. In our example of retrieving syndication feeds, we can report how many bytes of the total amount have been retrieved:

In this case, the second parameter (progress) is of type RetrievalProgress. This type contains two parameters (bytesRetrieved and totalBytesToRetrieve) that are used to report our ongoing progress.

For deeper material (involving asynchronous programming in WinRT, or asynchrony in general), you can check out:

• “Async Everywhere” talk from the //Build conference
• Asynchronous Programming in JavaScript with “Promises”
• Task-Based Asynchronous Pattern
• Asynchrony in .NET

In closing

What’s interesting about asynchrony being so prevalent in WinRT is how it impacts the way you structure your code and architect your app. You start thinking about your app in a more loosely-connected way. If you have any feedback in this area, we would love to hear from you! Let us know by leaving a comment here or on the Dev Center forums.

We want your customers to love your Windows 8 apps. We want those apps to start alive with activity, and remain alive with activity. And we want you to more easily create those apps. We want you to be able to easily connect to social websites, store data in the cloud, work with files on the hard disk, communicate with other gadgets and devices, etc., while providing your customers with a great user experience.

–Jason Olson

Program Manager, Windows

Windows 8 app developer blog

This short video demonstrates UI enriched with smooth animations.

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:

1. A brief overview of the animation engine
2. How to get started using the Animation Library
3. Custom animations and how to take advantage of the animation engine improvements
4. 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

<script>       
   function runAnimation(){
      enterPage = WinJS.UI.Animation.enterPage(input);
   }
</script>

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:

1. Adding a UIElement to the page or visual tree.
2. Removing a UIElement from the page or visual tree.
3. 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's children go here -->
</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 CSS3</title>
   </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's children go here -->

    </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:

1. Animating property that affects layout: These properties, such as CSS Width, trigger re-layout and are not supported independently.
2. 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.
3. 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

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

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

3. 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.
4. 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.

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

1. 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.
2. 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.
3. 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