The two ways to handle orientation in your Windows 8.1 app

Ah, elegance. Handling orientation basically means adjusting your app to account for real estate changes when the user pivots their device from Landscape to Portrait, or when the user adjusts your app’s width.
In Windows 8.0, there were four possible orientations: FullView (1366x768), FillView (1024x768), SnapView (320x768), and Portrait (768x1366). In Windows 8.1 there are two possible orientations: Landscape (width > height) and Portrait (width < height).

CAVEAT: In either case, screen size (inches) can vary across devices. An increase in screen size (not to be confused with resolution), introduces new (or less) real estate for your app’s UX. As a result, developers should build responsive layouts to handle increases and decreases in screen real estate.

Nostalgia: Yonder SnapView?

Kids today don’t even know what we’re talking about when we say SnapView. We might as well be talking vacuum tubes and punch cards. So, where’s SnapView? Here’s the secret: it’s still there! In Windows 8.1 the minimum app width is 500 pixels. However, with a simple setting in your app’s manifest the 320 pixel width comes right back! You just don’t have SnapView enum anymore.

Approach 1: Raw code

I am a big fan of coding the solution. If that’s what you want to do, you’ll need to change your approach from Windows 8.0 and use the simpler Bounds.Width property of the CurrentWindow. That same Window has a SizeChanged event that can detect the change when it occurs.

If you want to do a simple test to see if your app is in Portrait or Landscape, it would be as simple as testing if Width is > Height or not. But, why mess with that when you can use something that is already part of the platform. In this case, the ApplicationView. Like this:

That property returns an enumeration defined like this:

Note: You might also notice the Visual State references in those samples. To be clear, these states do not exist by default in your app. No. They exist only when you define them, and you might want to define your own. I explain Visual States in this article. If you need a refresher, I think it’s a pretty good starting place.

Lets see this done, okay?

Option 2: Blend Behaviors

Blend behaviors are a powerful capability of Blend. I explain Blend Behaviors in this article. In short, they are a way to add functionality to your app without requiring you to code custom implementations. That’s because behaviors are wrapped implementations with a few properties to customize them.

Introducing the Orientation Behavior

I created the Orientation Behavior to simplify the handling of orientation.

Simply drag the OrientationBehavior from Blend’s Assets tab onto the top control within the scope of dyour visual states; identify which state represents landscape and portrait. Then, for added benefit, identify which (optional) state represents the snap, or narrow, view you might have created. Want to consider 500 pixels narrow? Just change the NarrowWidth property to 500 and you’ve got it. From that point forward, states will be changed for you as the user changes the shape of the app or the orientation of their device.
Get the code here. XAML and all.

Here are some tips:

1. If you have defined your states on the root grid, then put the behavior there.
2. I like to create user controls for each state, that way I can easily design them.
3. The name of your state does not matter at all. But it’s smart to make them clear.
4. Transitions in orientation changes can have a very nice effect when the user is simply resizing your app’s width. Using them is up to you.
5. Every property in the behavior can be bound to your view model, if you want.

You want me to show you? Sure!

In the video above, I walk through the implementation of the Orientation Behavior which you can get here (which includes some sample XAML). The best part of using this Behavior is that the work is all done for you, but it is just a simple class file you can update if your app requires tinkering.
This is my Christmas present to you!

Last note

There are, of course, more than two ways to handle orientation. A third possible approach is to determine the correct view in your view model and bubble that up to the view through a notification property. Then, using either a behavior or code-behind you listen to and react to the property value change, setting the correct state as a result. I have mixed feelings if I like listening for orientation in the view model. In some cases, it’s easy and simply doesn’t matter. In other cases, the view models are abstracted away and the necessary namespaces are missing. So, as a default, I do not prefer doing it that way. But that’s just me. You’re the developer! I wanted you to know your options.
Best of luck!