Today I’m picking up a couple of smaller additions/changes to Windows 8.1, as yesterday’s post was quite lengthy.

First is that there’s much deeper SkyDrive integration in Windows 8.1. You can learn about this in the //build 2013 talk, What’s New for Working with Files (2-119). I haven’t gone into this in detail yet, so I’m not sure where it intersects with the WinRT API.

Second is that there are new tile sizes (small and large) with associated tile templates, along with some expanded capabilities in secondary tiles. With the latter, you can now provide multile tile sizes and multiple images per size so that the user can select their desired tile size and image directly in the consent popup, rather than having to do it on the Start screen. You can see more in The Windows.UI.StartScreen.SecondaryTiles class, as well as the Secondary tiles sample. My own talk at //build, Alive with Activity (3-159), covers all the tile changes.

On the subject of tiles, there are a couple more talks on push notifications and Windows Azure Mobile Services that are relevant:

We purposely included many talks at //build 2013 about performance because it's one area that's very important for all the apps you're creating as well as for consumers' overall experience of the system. Windows 8.1 Preview has better performance across the board, so in many ways apps just benefit without doing anything special. Then we're introducing more tooling around performance, and have more experience now at best practices for apps.

Here's a rundown of the perf-related talks from //build. Pick and choose those that are relevant to your chosen language and presentation layer:

General (including reliability):




One of the most significant changes in Windows 8.1 relates directly to the Windows Store but doesn’t involve any new APIs. This is the auto-update feature for app, which means that you no longer need to rely on users manually updating your apps from the Store. The primary impact of this is that if you make feature updates and especially add in-app purchases, those features will become available to all your customers unless they’ve specifically opted out of auto-updates. This should help quite a bit with monetization over time.

At //build 2013, Ted Dworkin’s talk gives the overview: Windows Store Overview for Windows 8.1: New Design, New Promotion and Monetization Opportunities (2-123).

As for new APIs, the key features here are added support for consumables (in-app purchases that can be re-purchased over and over), and support for large catalogs of in-app purchases (going beyond the 100 item limit of Windows 8). See the Windows.ApplicationModel.Store APIs, as well as the talk Monetization Opportunities for WIndows Store Apps in Windows 8.1 (3-121).

Speaking of the Store, there are a couple of other related talks from //build 2013:

One of the most significant additions to the WinRT API in Windows 8.1 Preview is found in the Windows.Devices namespace, showing that Windows 8.1 is opening the floodgates for apps that can make sure of a wide range of peripheral hardware.

The self-explanatory API areas are listed below, along with links to //build 2013 sessions that talked about them. Note that a number of the sessions were pre-recorded–we did this because there were more specific topics than we could accommodate in the live venue.

Personally, I’m looking forward to working on devices chapter in the second edition of my book (first preview here), as it will give me an excuse to buy some fun toys to play with like a Sphero and LEGO Mindstorm! My nearly 7-year-old son will enjoy that too.

This new API is not something added to WinRT, but something that’s available through existing HTML5 APIs. WebGL, the standard for 3D graphics on the web, is available in Internet Explorer 11 as well as WebView controls inside Windows Store apps. However, WebGL is not at this time supported for direct use within apps [this is a correction from my original post] but will be in Windows 8.1 RTM.

WebGL is accessed through the HTML5 canvas object’s getContext method, using the argument “webgl”. The resulting context provides access to the API.

Some talks at //build 2013 that discussed WebGL are New Platform Capabilities for Advancing Web Development (2-067) and Hyper-Fast Web Graphics with WebGL (4-072).

As one who works in HTML/JS most of the time, it’s exciting to see a number of new WinJS controls and some improvements to existing ones, namely the ListView and the AppBar.

New controls can be found when you scan the WinJS.UI namespace in the updated documentation:

  • BackButton: a cleaner back button implementation that hooks directly into WinJS.Navigation APIs. Previously, most of this functionality was provided through the Visual Studio templates, where a standard <button> was just styled to look like a back button, and the PageControlNavigator code handled the details like calling WinJS.Navigation and handling keyboard events. The BackButton does such things in a more encapsulated way. Refer to the Navigation and navigation history sample.
  • Hub: a significant new control for implementing app home pages with a hub design. In Windows 8, developers had to do this manually, or use a third-party library (Telerik created a hub control, for instance). So now we have a standard implementation. Refer to the HTML Hub Control sample.
  • ItemContainer/Repeater: Together, these provide for a lightweight list implementation, namely where you just need to create a repeating, templated display of data items and don’t need all the interactivity of a ListView. Refer to the HTML ItemContainer sample and the HTML Repeater control sample.
  • NavBar: a standard implementation of a top app bar as used for navigation. Refer to the HTML NavBar Control sample.
  • SearchBox: with in-app search moving to the app canvas instead of the search charm, WinJS adds a control that provides the same kind of search contract interactivity with the app that the charm did. Refer to the SearchBox control sample.

Where the ListView is concerned, many things have changed. I haven’t had a chance to get into the details yet, but one thing I know is that doing a custom layout is much simpler as the whole layout model has changed from a complex custom interface to one based primarily on CSS (called ILayout2). Custom layouts were possible before, but very difficult to implement and it never really got documented–so now they’re easier. For more, see the HTML ListView custom layout sample. Note that we also have some new WinJS layouts, such as CellSpanningLayout, an Orientation option to make the GridLayout (pan vertically), options to add group headers to the ListLayout. There is also drag-and-drop reordering support now–see the HTML ListView reorder and drag and drop sample.

For more details and demonstrations (as well as bits on the AppBar), see Paul Gusmorino’s What’s New in WinJS talk from //build 2013.


One of the next most interesting APIs added to Windows 8.1 that I also write in Chapter 4 of my Second Edition Preview is the Windows.Web.Http.HttpClient API (and associated classes). On the surface–and the API is designed to be very simple and easy to use for common cases–it seems redundant with other available APIs like WinJS.xhr (i.e. XMLHttpRequest) or the HttpClient API in .NET. In that sense it at least provides a robust HTTP API for C++ developers.

Digging down a little deeper, however, this new API goes well beyond the existing ones and should, in time, obsolete the other methods. For one thing, it provides cache control and access to cookies unlike the existing APIs. In comparison to the .NET API, this new WinRT API works with the WinINet cache, so benefits from any caching that happens via Internet Explorer, other apps, or the pre-caching API that’s now in Windows.Networking.BackgroundTransfer.ContentPrefetcher class.

The new API also provides a low-level hooking mechanism called filters that allows you to place handling code beneath the level of app logic. The HttpClient sample that’s now available shows how to create filters for authentication, 503 retries, and network cost awareness, meaning that the rest of the app can ignore the details of such concerns. That is, instead of having every HTTP request in your app have to think about cost awareness, you let the filter do that. The rest of the code either just gets the data or doesn’t, which makes it a lot simpler to write.

For additional details, also see Peter Smith’s talk from //build 2013: Five Great Reasons to Use the New HttpClient API to Connect to Web Services.

One of the most important features in Windows 8.1 Preview for HTML/JS developers is the x-ms-webview element that’s added to HTML. If you’ve never developed in XAML before, the webview is a control that renders arbitrary HTML, CSS, and JavaScript, and allows for the app to invoke script within the webview and the webview to raise events to the app. Yes, you could do some of this with the iframe element in Windows 8, of course, but the iframe had a number of limitations. For example, if the site you wanted to host contained frame-busting code, you were simply out of luck. HTML/JS apps also lacked a way to load up downloaded or locally-generated HTML/CSS/JS into an iframe. It’s also not possible to render an iframe to a bitmap.

Fortunately, you can do all this with the webview, as well as hook into an app-provided link resolver for cases where references within the HTML need to be patched up at runtime (as when referenced images aren’t directly on the file system).

I’ll let you learn more about the webview yourself. I already wrote a bunch about it in the first preview of Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition, specifically Chapter 4.

You can also learn more from John Hazen’s talk at //build 2013 which we just presented last week: Webview: bringing the web to your app.