One of the many things you need to consider when submitting your app to the Windows Store is the ability to handle rotation and snap view. Now, as far as I know it’s not mandatory because in the first release of DeTV I lacked both but it was approved anyway. Also some apps are not even meant for running in snap view. Nonetheless if you can you should always try to support both snap view and rotation. In this demo I’ll guide you through the basics you need to know for implementing both orientation and snap in your app. But first a little background on layouts and resolutions: according to the Windows Store certification requirements your app must support a minimum resolution of 1024 x 768. Also your app must remain functional when it is snapped and unsnapped. From this you can conclude that at a minimum your app has to support the following three visual states:

1024 x 768 (the minimum resolution and while in filled state),

320 x 768 (snap view) and

the default resolution you plan for your app (generally 1366 x 768).

Of course it’s not appropriate to just shrink or stretch the UI of your app in order to support the snapped and filled views. Luckily there’s a few tricks you can use out of the box for rearranging the display when snapping and unsnapping your app – kind of like responsive web sites change looks when viewed on a smartphone or pad. By default all Windows Store App templates support rotation but for some apps that might not be the preferred state. For instance for a game it maybe only makes sense to run in landscape mode. If you open the Package.appxmanifest file and check the Application UItab you can choose which rotations your app should support.

Supported rotations in the Package.appxmanifest

Getting started

Start by creating a new Blank Windows Store App. Unless your computer supports rotation run your blank app in the simulator. If you rotate it you’ll see that the app supports all rotations by default. You can play with the supported rotations in the Package.appxmanifest and view the results in the simulator as well. Now open the MainPage.xaml file and add a TextBlock. We’ll use it later for feedback on the rotation and snapped state.

That’s it for the MainPage.xaml for the moment. Now open up the MainPage.xaml.cs file and start by adding a using statement: using Windows.Devices.Sensors;. Next we need an instance of the SimpleOrientationSensor.

[sourcecode language=”csharp” highlight=”1,8,12,26″]
using Windows.Devices.Sensors;
using Windows.UI.Popups;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Navigation;

This is the code so far. Instantiate the SimpleOrientationSensor in the constructor and do a quick check in the OnNavigatedTo event if we have one available or not. Note: the messageDialog.ShowAsync(); will give you a warning because it’s not awaited but you can ignore that.

Even if you run the app in the simulator you probably don’t get the result you’d expect

This is because the simulator actually simulates the computer you’re working on. So, if it’s like mine, a 10+ kg workstation, odds are that you’ll be greeted with the above message. This also means we’ll need to come up with some other solution in order to test the rotation. Luckily there’s a simple solution to the problem. That is if you have a second device with rotation sensors available. In short you’ll need to install the Remote Tools for Visual Studio 2012 on the device. You can get it from the Visual Studio download page and I have a tutorial on remote debugging that explains how to install and set it up. Now if you run your app on the remote machine your textblock will tell you the current rotation of your device but it won’t reflect any rotation changes. For that we’ll have to add an event handler to our code to catch the changes.

[sourcecode language=”csharp” highlight=”2,11,15,19,32,45″]
using System;
using Windows.Devices.Sensors;
using Windows.UI.Popups;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Navigation;

The code above is what we need for our project for the moment. Press F5 to start it on your remote machine to see how it behaves. You can see that in addition to the landscape and portrait orientations there’s also facing up and facing down. These will trigger if you lay the device down or flip it upside-down. This way you can take actions in your code to rearrange the content for different orientations. You can also choose which orientations you want to act on. If you disable any of the orientations in the Package.appxmanifest file you’ll discover that the event is still fired for your disabled orientations even if the screen doesn’t flip that way.

About the code; first add using statements for the Windows.Devices.Sensors and Windows.UI.Popups namespaces. The Popups namespace is of course only for the message box and is not really needed for detecting orientation. Then add a SimpleOrientationSensor and instantiate it in the constructor method. If no rotation sensor is present this will return null.

In the OnNavigatedTo event handler check that a sensor is present and if not pop up a message and return. Otherwise add an event handler that will subscribe to the OrientationChanged event of the SimpleOrientationSensor. Lastly call the method for displaying the current rotation.

When leaving the page unsubscribe from the OrientationChanged event in the OnNavigatedFrom event handler. It’s no longer necessary.

OrientationChanged is the event handler that is assigned to subscribe to orientation changes. Note the async keyword in the method declaration. It’s used for making the method awaitable. Inside the event handler make a call to the ShowOrientation method for displaying the current rotation. Since the ShowOrientation method doesn’t have any awaitable code use the Dispatcher.RunAsync method for making the call asynchronously.

In the ShowOrientation method add a switch block for determining the current rotation and type in the messages that will be displayed for each rotation. Using this method the appearance of the app could now be revamped to fit the current orientation. But there’s an easier way.

The VisualStateManager

While acting on orientation changes in code is a possible way to re order the appearance of an app it might not be the most straightforward path. This is where VisualStateManager comes in.

In the project add a new Basic Page and call it RotationPage.xaml. As you can see in the description for the Basic Page it supports layout awareness. This is the magic key to using visual states in your app. The Basic Page is a LayoutAwarePage and provides in itself the structure to orient itself and snap properly. In addition to the VisualStateManager the Basic Page also adds a back button, title and a grid to your new page.

When you click on add you will most likely be greeted with a message telling you that the Basic Page is dependent on files missing from you project. Click Yes to add these files automatically.

The new files are added to the Common folder in your project.

Rebuild your project once for resolving the missing dependencies. Now you should be able to see your new page in the Design View in Visual Studio. Now take a look at the XAML. Look for the VisualStateManager.VisualStateGroups block. You’ll see a VisualStateGroup which in turn contains the visual states:

FullScreenLandscape

Filled

FullScreenPortrait

Snapped

Using the Storyboard you can apply different appearance for the different visual states. First you need to set a name for the root grid of the page so that you can access it later from the XAML. Also add a textbox on the page (I called it MyViewState).

Now find the block of visual states in the XAML. By adding Storyboard and animation tags to the visual states (the snapped and portrait states already have them) for manipulating the values of objects on your page.

You can add animations to all four visual states and set different background colors if you like. If you run your app in the Simulator you will see that it actually supports the visual states even though it doesn’t support the SimpleRotationSensor object. Simple page layouts like the Basic Page really don’t need much rearranging of the content but the more complex your content gets the more you’ll have to pay attention to arranging it nicely for different visual states.

Summary

This should have given you an introduction on how to manage different visual states in your Windows Store App. For more complex layouts you will most likely have to rearrange grids or even create different layouts for the different states. The most important point you need to remember from this tutorial is that your app must support the snapped state.

Code

A very handy feature of Visual Studio 2012 is debugging on a remote machine.

Especially if you as I develop on a plain old workstation with few or no sensors available. I came across this issue when playing with the orientation sensors. In this tutorial I will walk you through the steps you need to set up remote debugging.

Remote Tools for Visual Studio 2012

You’ll find them on the Visual Studio 2012 download page: http://www.microsoft.com/visualstudio/eng/downloads. Scroll down to Additional Software to find the Remote Tools for Visual Studio 2012. Choose language and version (x86/x64/ARM) and hit download from the computer you want to use as remote machine. Once you have downloaded the package the installation procedure is straight forward.

Configuring the Remote Debugging Monitor

After the installation finishes start the Remote Debugger (you’ll need administrative privileges for the first run). This will bring up the configuration window.

You will also be taken through the procedure for acquiring a Developer Licence exactly like when you created your first Windows Store App project.

If the Windows Web Services API is not installed hit the Install button. Now choose at least one type of network for the remote debugger to communicate on.

Click on Configure remote debugging to start the Remote Debugging Monitor. You should see a message that the Msvsmon is running and awaiting connections.

From the Tools menu choose Options for changing port number, authentication method and maximum idle timeout for the monitor. By default the authentication mode is set to Windows Authentication and the idle timeout is set to 0 (= no timeout).

When using Windows Authentication mode you can set who can connect to the remote debugger from the Permissions dialog.

Setting up Visual Studio 2012

Now go back to your development machine and open up the Properties page for your project and select the Debug tab. In the Debug Start Options section select Remote Machine as target device and click Find to browse for your device. You can also select whether to use authentication or not and if you want to redeploy your app each time you start the debugger. This will allow you to run your app from a clean install each time, but you will loose any app state by doing so.

Taking it for a spin

Now you’re all set for remote debugging on another device. You’ll be able to configure break points and step through your code as if it was running on your local machine.

If you take a peek at the Remote Debugging Monitor on your device you’ll see the connection from your development computer.

Running the Remote Debugger as a service

Normally the Remote Debugger runs as a Windows application but it’s possible to configure it to run a a service instead (as usual you’ll need administrative privileges to set this up). Start the Remote Debugger Configuration Wizard and follow the screens to set it up. This can be advantageous for instance if you want to be able to debug server applications such as an ASP.NET web site without first having to log in to the remote computer.

First select which account will be used to run the service. The account will need “Log on as a service” privileges and network access rights. It’s also advisable to add this account to the Administrators group.

Then configure which networks the service will allow connections from.

Wrapping it up

I hope you’ve enjoyed this short tutorial on remote debugging in Visual Studio 2012. If you liked it or found it helpful – share it with your friends. If something seemed quirky – let me know! You can find some more information about the Visual Studio 2012 Remote Debugger at MSDN.

After too much consideration about the looks and other fluff of On Error Resume Next I’m gonna kick off with a post instead.

One of the things that bugged me while writing DeTV was the lack of tools in the toolbox for creating the charm flyouts for the about and privacy policy pages. So after a quick search I stumbled upon the CharmFlyoutLibrary by John Michael Hauck which did the trick. Still a bit tricky to get working with a gridapps due to the fact that they lack a MainPage.xaml. John Michael of course has an in-depth post about this but I though I’d give it a go with a simple tutorial on how to get CharmFlyoutLibrary up and running with a gridapp.

Grid page with the settings flyout opened

You can get hold of CharmFlyoutLibrary from the Windows Dev Center but I prefer using NuGet. I’ll be building an app from scratch in C# but you can of course follow the steps in your own app. We’ll start by creating a new Windows Store Grid App.

From the Solution Explorer in your new project right click the References folder and pick “Manage NuGet Packages…”

Type CharmFlyout in the search box and hit Install for adding the CharmFlyoutLibrary to your project.

You should see the CharmFlyoutLibrary under References in the Solution Explorer. Now create a User Control to host your flyouts and call it Flyouts.xaml.

You can get rid of the DesignHeightand DesignWidth attributes from the UserControl tag since the dimensions will be controlled by the flyout. Add the CharmFlyoutLibrary namespace to your control by adding the attribute xmlns:cfl="using:CharmFlyoutLibrary" to the UserControl tag. I chose to call it cfl but you can call it whatever you like as long as it doesn’t interfere with any other namespace in your control.

For each flyout you need you create a <cfl:CharmFlyout>...</cfl:CharmFlyout> tag. You need to supply the x:Name and Heading attributes (well, technically the heading is not required but nice to have). The contents of the flyout will be everything wrapped within the StackPanel inside the CharmFlyout.

In the above example I have two flyouts: cflAbout and cflSettings.

Next you’ll need to add the code behind for handling the flyouts.

[sourcecode language=”csharp”]
using System;
using Windows.UI.ApplicationSettings;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;