See Part 1 for creating views.

Creating a new view doesn’t actually make it visible—the view’s HTML, CSS, and JavaScript and C#/XAML are all loaded and running, but nothing will have appeared on the screen.

For that you need to use one of two APIs: the ProjectionManager (this part) or the ApplicationViewSwitcher (Part 3 of this post series), both of which are in Windows.UI.ViewManagement.

The ProjectionManager is meant for full-screen scenarios and work with a single secondary view. Its projectionDisplayAvailable property [and I’m going to give the member names in JavaScript casing, so C# readers please translate!], first off, tells you whether projection is possible and, along with the projectiondisplayavailablechanged event, is what you use to enable a projection feature in an app.

To make the view visible you pass its viewId to startProjectingAsync along with the ID of the primary view (the one from ApplicationView.getForCurrentView().id). Later on, call stopProjectingAsync to close the view and swapDisplaysForViewsAsync to do what it implies.

For a simple [JavaScript] example, refer to the SimpleViewProjection example in the companion content for Chapter 8 of my second edition. On startup it gets the primary view and the ProjectionManager (js/default.js):

var view = vm.ApplicationView.getForCurrentView();
var projMan = vm.ProjectionManager;

The Start button in the example is itself enabled or disabled according to the ProjectionManager:

btnStart.addEventListener(“click”, startProjection);

projMan.onprojectiondisplayavailablechanged = function () {

function checkEnableProjection() {
    btnStart.disabled = !projMan.projectionDisplayAvailable;

When you click Start, the app creates the view and starts projecting, using the id’s of both views:

viewProjection = MSApp.createNewView(“ms-appx:///projection/projection.html”);
() {
// enable/disable buttons


​Other buttons will call stopProjectingAsync and swapDisplaysForViewAsync, and other code handles selectively enabling the UI as needed. There’s also a button to do a postMessage to the projection with the current time.

function sendMessage() {
var date = new
var timeString = date.getHours() + “:” + date.getMinutes() + “:”
+ date.getSeconds()
+ date.getMilliseconds();
msgObj = { text: timeString };
        document.location.protocol +

The projection page is in projection/projection.html with associated .css and .js files. Within its activated handler it retrieves the opener view and listens for the consolidated event (js/projection.js):

var opener = MSApp.getViewOpener();

var thisView = Windows.UI.ViewManagement.ApplicationView.getForCurrentView();
thisView.onconsolidated =
() {

where sendCloseMessage is a function that just does a postMessage with a “close” indicator so the main app can reset its UI. The same thing happens when you click the Close button in the projection, after which it calls window.close.

For another demonstration–which includes C# and C++ variants–refer to the Projection sample in the SDK. It basically does the same thing as the simple example above, adding a little more to set view properties like the title. I didn’t show any code from the sample, however, because it buries the basic API calls like createNewView and getViewOpener deep inside helper classes called ProjectionView.ViewManager (for the primary view) and ProjectionView.ViewLifeTimeControl (for the secondary view) [in the C# version there’s a SecondaryViewsHelper.ViewLifetimeControl class for the same purpose]. These classes s a little too complicated to use as an introduction to the API!

This same mini-framework is also used in the SDK’s Multiple Views sample, which demonstrates the methods of the ApplicationViewSwitcher class, that will be our subject for Part 3.

[The following is taken from Chapter 8 of ​Programming Windows Store Apps in HTML, CSS, and JavaScript, Second Edition/Second Preview​, available at I’ve added a few notes that I hope will be useful to C# developers, though not working in C# much I can’t give as much detail.]

Many years ago, when I was very actively giving presentations at many developer conferences, I so much wished that Microsoft PowerPoint could present my slides on the main display for the audience while I got a view on my display that showed the next slide as well as my notes. You might be laughing because PowerPoint has had this feature for quite some time (I wasn’t the only one who made the request!). The point, though, is that there are certainly app scenarios where a single app wants to manage multiple independent views, possibly and oftentimes on separate monitors, and the user has the ability to rearrange and resize those views, which includes dragging them between monitors. Any one view, though, is limited to a single display (that is, a view cannot span displays).

Projection scenarios like PowerPoint are clearly one of the primary uses for multiple views; a game might also use a second view for various controls and output windows so they don’t interfere with the main display. A different kind of use is where an app has several independent (or loosely coupled) functions that can operate independently and can benefit from being placed side by side with views from other apps (multitasking at its best!). A customer-management system for a mobile sales rep might have one view for appointments and contacts, another for data entry forms, and a third for managing presentations and media. Although these functions could be part of the same layout within a single app view, they don’t need to be. Having them as separate views—which means they operate on different threads and can only share data via the file system—allows the user to place them in relation to other apps such as a web browser (for customer research) and an email app.

The caveat with multiple views is that they run on separate threads and therefore each have their own script context. Views can only communicate with each other through postMessage calls in JavaScript (as are used to communicate between the local and web contexts), or Dispatcher.BeginInvoke in C#. Views can, however, exchange data via appdata settings and/or files, which they share in common.​

In JavaScript, a view is created through the MSApp.createNewView API, provided by the app host and not WinRTs specific to apps written in HTML and JavaScript. The one argument you give to this method is a string with the ms-appx URI of an in-package HTML page to use for the new view (only ms-appx URIs are allowed, meaning the view runs in the local context). That HTML file can, of course, reference whatever own stylesheets and script (including WinJS) that it needs. All of this will be loaded as part of the createNewView call, even though the view is not yet visible. The usual DOM events like DOMContentLoaded will be raised in the process, and you can use the WinJS.Application events as always (provided that you call app.start() to drain the queue).

The MSAppView object that createNewView returns will have a unique viewId property to identify it, along with postMessage and close methods. The latter is what the app clearly uses to close the view. Within the secondary view, it will receive message through the window.onmessage event, as usual. The new view can also call window.close to close itself, and the user can also close the view with touch/mouse gestures or Alt+F4. As for sending data back to the app, the view calls MSApp.getViewOpener to obtain the MSAppView object for the app’s primary view—its postMessage method will raise a window.onmessage event in the primary view. These relationships are shown below:
View communication

A primary view creates a secondary view through MSApp.createNewView. The secondary view retrieves a reference to the primary view through MSApp.getViewOpener. The result in both cases is an MSAppView object whose postMessage call sends a message to the other view.

The C# analog to MSApp.createNewView is CoreApplication.CreateNewView. This produces a new CoreWindow object, and if you send that to Windows.UI.ViewManagement.ApplicationView.GetApplicationViewIdForWindow, you get the unique viewId. The view can close itself with ​Window.Current.Close()​, and it can access the primary view through App.Current.MainDispatcher (and App.Current.MainViewId).

Let me note up front that if a secondary view closes itself, the app won’t receive any kind of event. Typically, then, the secondary view will inform the app that it’s closing. This is also where the secondary view should subscribe to the ApplicationView.onconsolidated event to detect when the user closes it directly, and post a message to the app. We’ll see examples in later posts.

One of the areas that has seen the most change between Windows 8 and Windows 8.1 is the WinJS ListView control. The whole control was basically overhauled from its WinJS 1.0 incarnation. It’s WinJS 2.0 version is much more performant, supports drag and drop, used CSS grid/flexbox for layout rather than absolute positioning, supports more built-in layouts, makes it easy to write custom layouts, and improves keyboard support.

In writing the chapter on collection controls for the second edition of Programming Windows Store Apps with HTML, CSS, and JavaScript, I didn’t want to burden the chapter with describing all the changes–I made the decision early on that the book would really present the state of the platform in Windows 8.1 and talk very little about changes or migration. A blog is better for that!

Toward that end, this post is summarizes all the changes that are documented or that I’ve encountered in writing the book chapter.

First of all, here’s the list of ListView 1.0 features that are deprecated in ListView 2.0, and what replaces them:

  • Incremental loading properties. Incremental loading is handled either through the data source or the item rendering function. The new HTML ListView incremental loading behavior sample ( shows how, by adding more items to the Binding.List in the item renderer.
    • loadingBehavior=’incremental’
    • automaticallyLoadPages
    • loadMorePages
    • pagesToLoad
  • Backdrops were a feature added late for ListView 1.0 as a band-aid for its performance on ARM devices. Given that ListView 2.0 performs so much better, this feature is often no longer needed, but even so, it’s handled through CSS now. So the following properties are obsolete in favor of the win-backdrop CSS selector in WinJS 2.0:
    • ListLayout: backdropColor, disableBackdrop
    • GridLayout: backdropColor, disableBackdrop
  • The GridLayout’s new orientation property obsoletes its earlier horizontal property. A GridLayout supports both vertical and horizontal orientations.
  • The ListLayout’s vertical property is obsolete in favor of the orientation property, which supports both vertical and horizontal.
  • Cell spanning happens how through the CellSpanningLayout class, obsoleting the GridLayout’s earlier cell-spanning features:
    • itemInfo, groupInfo, and maxRows. In the CellSpanningLayout you’ll find itemInfo, groupInfo, and maximumRowsOrColumns.
  • The ListView’s resetItem and resetGroupHeader methods are deprecated because the control no longer recycles items. In WinJS 1.0, as a performance optimization, a rendering function could receive a second parameter that was an already-created item element tree, in which you’d replace the data. These properties let you centralize the cleanout process, but as recycling is no longer used, these methods do nothing.
  • The earlier IListLayout and related interfaces for custom layouts, which were really never documents, are obsolete. Layout has been overhauled from an absolute positioning model (which introduced many performance issues) to one based on pure CSS. As a result, the custom layout model for WinJS 2.0 is much simpler, using the IListLayout2 and related interface. The HTML ListView custom layout sample shows this (

It’s good to note that WinJS.Binding.Template controls are compiled by default in WinJS 2.0. If you find a problem with that, the Template object has an option called disableOptimizedProcessing that, when set to true, will impose the WinJS 1.0 interpreted template model.

Other changes to the ListView for WinJS 2.0 introduce new features and capabilities:

  • Invocable headers: groupHeaderTapBehavior and headerInvoked properties.
  • Drag and drop: itemDrag* events, itemsDraggable, itemsReorderable properties.
  • ListView uses maxDeferredItemCleanup property instead of 1000 as the default.
  • ListView implements the WinJS standard dispose pattern and triggerDispose
  • CSS-based layout, which enables easier custom layouts, improves performance quite a bit.


There are new APIs for working with the user’s calendar and contacts, which are found in Windows.ApplicationModel.Appointments and Windows.ApplicationModel.Contacts. There are also some smaller improvements in the file pickers and Share contract. For all this there are two //build talks: Building apps that work together (2-010) and Building Apps That Integrate with People and Events (3-007).

Fulfilling a common request for new APIs, Windows 8.1 adds a PDF rendering API that’s found in the Windows.Data.Pdf namespace and demonstrated in the PDF viewer sample and the more extensive PDF viewer showcase sample. The API itself can open and load PDFs, then you request that individual pages be rendered to a stream. That stream can then be turned into a graphic for whatever UI framework you’re using. The //build talk is Rendering PDF Content in Windows Store Apps (3-175).

Windows 8.1 also adds a text-to-speech API, which you’ll find in Windows.Media.SpeechSynthesis and demonstrated in the Speech synthesis sample. The //build talk on this is Making Your Windows Store Apps Talk (2-171).

Speaking of text, also look at the Windows.Data.Text namespace, where there’s a bunch of new stuff for text segmentation and Unicode. There are some related samples, but I haven’t worked through those enough yet to comment further.

On one hand I’m not entirely sure that the changes in Windows 8.1 for the Search contract and app sizing count as a “new API”–but they are certainly things you need to pay attention to!

Variable app sizing is certainly a new feature for Windows users, and thus something that apps want to handle well. This is one case where some APIs (like tryUnsnap) are actually deprecated! For apps written in HTML/CSS/JS, this means that the view state media features of (fullscreen-landscape, snapped, filled, and fullscreen-portrait) are obsoleted, replaced by the CSS3 standards for responsive web design, namely the orientation feature (portrait or landscape) and using max-width and min-width. I demonstrate some of this in Chapter 2 of my second edition preview. I’ll have more in my Layout chapter in the next preview, but you can also see more in the //build talk Beautiful Apps at Any Size on Any Screen (2-150).

Search also changes in that the Search charm now reaches out to web content, not just in-app content. As a result, in-app search is a feature that an app should show in its own UI (on-canvas or app bar). See Design and Build a Great Search Experience in Your App (3-144) for the details.

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: