What’s changed for app developers since //build/ (part 1)

The Consumer Preview is now available and hopefully, you’ve had a chance to see what we’ve been up to. Our engineering team has been working hard since //build/. We’ve been listening to your feedback and using it to improve our development platform. At the same time, we’ve been putting the finishing touches on lots of platform features that you haven’t seen before.

Along with the work we did directly on Windows, we’ve also improved our Visual Studio tools substantially since //build/. There have been improvements for Metro style app development and for other scenarios as well. I’ll talk about Metro style development here, but if you’re interested in other VS features, Jason Zander’s blog is a great place to start.

We know that you’ve been busy too. You started over 5,000 different threads on the MSDN Developer Preview forums and posted close to 30,000 messages. Our telemetry also tells us that you’ve been using Visual Studio to try out our development platform. You’ve created 1000s of app packages since September.

And that brings me to the topic at hand. When you start building your apps on the Consumer Preview, what kind of changes can you expect? One of our primary focuses in the Consumer Preview was to make Windows a better platform for you, the developer. We’ve been making it easier to use the APIs and create standard controls of the Metro style UI. We’ve improved the tools so you can be more productive and create fast and fluid apps. And we’ve created brand new features for you to harness even more of the richness of Windows and the power of the hardware.

In this two-part post I’ll highlight some of the important work that we've done to improve the platform and tools in the Consumer Preview. We added some new features, and made improvements to existing features, all to provide you with a better experience in developing Metro style apps. We think you’re going to like the changes.

DX support in XAML

“We need to be able to render very fast with the use of DirectX … also we want to make use of Metro style UI—by that, I mean we do not want to write whole UI from scratch in DirectX.”
– Metro style app developer

This is a common theme that we heard after we released the Developer Preview. Developers like you wanted to combine the high-performance immediate-mode rendering capabilities of DirectX with the rich interactivity, control model, and design-time experience of XAML.

We heard you. With the Consumer Preview, you can now smoothly integrate XAML and DirectX 11 in the same Metro style app to create a fast and fluid experience. For example, you can now create a DirectX game and use XAML to process input, create graphics for heads-up displays and menus, or bind to your app’s data model.

To this end, we added 3 new XAML types to support a broad range of DirectX interop scenarios, each with different capabilities:

  • SurfaceImageSource enables full composition of DirectX content into a XAML app. This allows drawing DirectX content into the XAML visual tree, useful for complex image effects, data visualization, and other immediate-mode drawing scenarios.
  • VirtualSurfaceImageSource isused for large-scale virtualized content. This is targeted toward apps that require panning and zooming of large content, like maps and document viewers.
  • SwapChainBackgroundPanel targets full-screen, DirectX-focused scenarios. This is great for games and other low-latency, full-screen DirectX apps with a XAML overlay.

This is really powerful stuff—take advantage of the full graphics power of DX, blended with the ease of XAML. If you’re as excited as we are about these new capabilities, take a look at our DirectX and XAML tutorial on MSDN.

There are also sample apps available:

Blend and the Visual Studio designers


We have more great news. Visual Studio beta includes not just Blend for HTML, but also an early preview of Blend for XAML. One Blend now supports design in both HTML and XAML—all you have to do is pick the project type you want. Blend for XAML brings support for animation and visual state authoring into the mix, ready for your Metro style apps.

Full screen view of Blend designer for XAML, showing how you can edit button properties

The new Blend designer for XAML which is included with the Visual Studio tools

In Visual Studio, the XAML designer now supports control and data template editing, and provides better support for Metro style app controls such as SemanticZoom, GridView, and AppBar.

Previewing a XAML layout in Visual Studio. The desiger view is in the main viewing pane, and corresponding XAML markup is in the pane below.

Take advantage of the XAML designer directly within Visual Studio


Blend for HTML comes with numerous improvements for building HTML apps.

HTML ListView control shown in the Blend designer for HTML. ListView UI is in the main viewing pane. HTML and CSS markup used to create and style the control are in separate panes below.

Take advantage of the extended capabilities of the Blend designer for HTML

Among other things, we expanded the editing capabilities for Metro style app controls, which now include interactive editing of data templates for ListView. Plus, you can now edit HTML fragments in place, right on the page where you use them, and they can be as deeply nested as necessary. In addition, there are many productivity improvements in the CSS property inspector and the HTML attributes panel, including highlighting of values that JavaScript has overridden.

After you download Visual Studio, fire up the designers and try out some of these improvements for yourself.

Windows Library for JavaScript navigation

Another area that’s been getting a lot of attention is the Windows Library for JavaScript (WinJS), where (among many improvements) we’ve simplified the navigation model. The VS templates at //build/ explicitly called the WinJS.UI.Fragments APIs to dynamically load new chunks of HTML (fragments) into the DOM at runtime. But the fragment loader is a very low-level API, and required the templates to also contain a bunch of fairly complex boilerplate code to complete the actual scenario.

If you tried using the code generated in the Developer Preview templates, you know it can get complicated.

  • The code was hard to read and use.
  • You were responsible for the code that kicked off initialization of the fragment.
  • You were responsible for initializing WinJS controls on the new page.
  • It was very difficult to keep track of state on each page.

In response to your feedback, we created a new feature to make your life easier: page controls.

Page controls are built on top of the fragment loader, and add the high-level pieces needed to easily do single-page navigation:

  • A well-defined creation lifecycle
  • A well-defined scope for your data
  • Automatic activation of WinJS controls at the right time
  • Automatic parenting of content to the DOM
  • An API that is easier to read and use

As part of this, the VS project templates also generate a new file, navigator.js, which encapsulates all the top-level navigation for your app. This is built as a custom WinJSControl, named PageControlNavigator. The navigation code in this file is much simpler than the navigation code from the Developer Preview templates.

For more info on the new navigation model, see:

DRM support

Traditionally, developing a Windows app that supports DRM content could be quite an endeavor.  As a developer, you had to have a deep understanding of the DRM technologies being used to protect your content. Additionally, thereis a rigid certification program that your app had to go through to ensure it met the requirements for DRM support.

With the release of Silverlight, Microsoft made this entire process far more streamlined. For Windows 8, we are bringing this simplified model to Metro style apps. If you already have a license service that can serve PlayReady licenses, you can add support for PlayReady DRM content within your app much more quickly than before, with minimum overhead.  And you can include this support using HTML or XAML and C++, C#, and JavaScript. It has never been easier to create a rich experience with protected content on Windows.

To help you do this, we introduced a new PlayReady Metro API surface in the Consumer Preview.  You can use these APIs to quickly implement PlayReady DRM playback support within your app. Then focus the rest of your development effort on creating other great capabilities and a user experience that your customers will love.  For Metro style apps, the SDK is free and you don’t need to submit your app to PlayReady for DRM Conformance testing. You can just focus on building amazing experiences for your users.

Here’s a code snippet showing an Individualization Service Request (JS):

 var indivSr = new Microsoft.Media.PlayReadyClient.PlayReadyIndividualizationServiceRequest();
indivSr.beginServiceRequest().then(indivSrOnComplete, indivSrOnError);

To find more info on how to support PlayReady DRM content within your app, take a look at the sample on MSDN.

Independent animations

In the Developer Preview we gave you access to a set of rich CSS animations that you could use to create your own beautiful transitions within your Metro style app written in HTML/CSS/JS. For the Consumer Preview we dramatically improved these animations by drawing on our experiences in hardware- accelerating IE; now core animations can run independent of the UI thread and entirely on the GPU. We call these independent animations, and they make it easier than ever to create a fast and fluid Metro style design.

The Windows 8 Animation Library is designed to take full advantage of independent animations. If you are creating custom animations I encourage you to use independent animations by using CSS Animation/Transitions of Transforms and Opacity only. 

The traditional way of doing animations with JavaScript puts the work on the UI thread; you just change the coordinates of your object in the DOM, and it redraws. While this is relatively straightforward, it blocks your UI thread and puts the work on your CPU, which is expensive! Here’s what that looks like:

 <script type="text/javascript">
function doAnimation() {
    foo.style.left = parseInt(foo.style.left) + 1 + 'px';
    if (foo.style.left != '100px')
    { setTimeout(doMove, 20); }

function init() {
    foo = document.getElementById('fooObject');
    foo.style.left = '0px';

When you use independent animations they are composed separately from the UI thread, and all the work happens natively on the hardware.


   -ms-transition-property: -ms-transform;
   -ms-transition-duration: 2s;
   -ms-transform: translateX(100px);

Using these animations will result in smooth/glitch-free experiences for your users because these animations are not affected by script running on the UI thread. There is no additional work or markup for you to do. You just keep using the right CSS animations and Windows will do the rest.

For more info on these CSS animations check out:

Debugging improvements

We understand the importance of having first-class debugging support for Metro style apps, and so we made a number of improvements to make this task easier.

There are major improvements in the number of C++ objects that you can inspect in the Watch windows. Instead of just seeing a COM object, you can expand it to see many of the properties and fields that you expect. (To get the great debugging experience for C++, download debug symbols from the Windows symbol server). There are incremental changes in the inspection of Visual Basic and C# objects as well.

Close-up view of the Watch window for a C++ project, showwing an example COM object and expanded fields and properties in the Watch window.

Inspect more objects in the Watch windows

We also improved debugging for async methods in Visual Basic and C#. Specifically, the debugger now treats exceptions thrown out of async void methods as user-unhandled, allowing it to break directly in the async void method. Also, in C++ you can now see rich error info when you find a WinRT exception as you can in Visual Basic, C# and JavaScript.

Another area that we’ve been working on is the UI around triggering Suspend, Resume, and Shutdown events from the Debug Location Toolbar. You can now select a specific process to trigger the event on.

Close up view of the suspend, resume, and shutdown buttons in Visual Studio. To the left of the buttons is a drop down list where you can choose a process to send messages to.

UI to trigger app lifetime events

Since //build/, we’ve added a number of features in the Simulator as well, for example:

  • Improved visuals, with thinner chrome that takes up less screen real-estate
  • Location simulation, so you can enter latitude/longitude, altitude, and error radius to simulate changes in location for the device
  • Faster rotation and improved touch emulation
  • Support for the 1024x768 resolution
  • The ability to take screenshots of the running app and save them to either the clipboard or a file

Simulator showing Windows 8 Start Screen, with a thin line of buttons along right hand side.

Updated Simulator UI with thinner chrome

More to come

We’ve been listening to your feedback and we hope you like what we’ve done with it. But we’ve done far more than I could describe in a single post. In part 2 of this post, I will highlight more changes we made, including updates to how you can work with tiles and notifications, updates to HTML/JavaScript controls, improved creation of hybrid apps, and more.

-- Jake Sabulsky, Program Manager, Windows

This post was a group effort. Thanks to: Jesse Bishop, Jonathan Aneja, Chris Tavares, Eric Salerno, Angelina Gambo, and Ian LeGrow