In Part 1 we learned about creating views, and in Part 2 saw the ProjectionManager API. Now we turn to the Windows.UI.ViewManagement.ApplicationViewSwitcher class, something that’s again demonstrated in the Multiple views sample in the SDK.

Those methods of that class—with some verbose names!—are:

  • switchAsync(id): (3 overloads) Switches to a given view in the same space as the calling one. If the target view is already visible elsewhere on the screen, however, this will simply change focus to that view. A value from ApplicationViewSwitchingOptions can be used to customize the transition: default (standard transition), skipAnimation (no transition), or consolidateViews (closes the calling view).
  • tryShowAsStandaloneAsync: (3 overloads) Shows the new view adjacent to the calling view, with options from ViewSizePreference to determine the desired state of the new and calling views: default, useLess, useHalf, useMore, useMinimum, useNone. You can experiment with these variations in scenario 1 of the sample.
  • disableShowingMainViewOnActivation: Prevents the primary view of the app from showing on subsequent activations, that is, when it’s appropriate to activate the app directly into a secondary view. Showing the primary view is always the default unless this method is called. This is shown in scenario 2 of the sample, with the actual call in js/default.js.
  • prepareForCustomAnimatedSwitchAsync: Tells the views whether to run default animations on a switch; by specifying the skipAnimation option, you can attach a completed handler to this promise to perform custom animations. See scenario 3 of the sample.

Because the details and variations of these APIs get rather complex, I’ll leave it to you to explore the sample directly. Note that in the main scenarios of the app you won’t find any calls to switchAsync—these are made in the secondary view (js/secondaryView.js) to switch back to the primary view. In each case the view closes itself as part of the switch, which isn’t a required behavior, of course.

To show the basic switching behavior, then, I’ve made a few small modifications to a copy of this sample in my second edition companion content. First, the button in the secondary view to switch back to the main view does not close the secondary one. Then I’ve added a button to scenario 1 of the main app to call switchAsync on the selected secondary view. You’ll see how it brings that view up in the same space as the original one, rather than alongside. If you switch back from the secondary view, the main view will appear in that space.

Things get interesting when you create an adjacent view first, then in the main app switch to a secondary view in the space. Then you’ll see two secondary views at once. If you switch to the main app in either, you’ll then find that the Switch to Main View button in the other secondary view just changes focus to the already-visible app. Otherwise you’d be seeing the main app view twice, which would be very confusing!

In summary, I hope that you’ll find some excellent scenarios in which to use multiple views. Given the newness of the feature, you have an opportunity right now for your app to really stand out if you’re an early adopter.

Comments are closed