Archive

Posts Tagged ‘Metro’

WP to W8: Application Framework

April 26, 2012 5 comments
This article is part of a series about my experience porting apps from Windows Phone to Windows 8. Official porting guidance can be found here and don’t forget to follow the Building Windows 8 blog and the Windows 8 App Developer blog for the latest information.

If you are currently working on a Windows 8 app that you’d like reviewed for possible early entry into the marketplace, please contact me.

 

In this article I’ll talk about the differences in application runtimes between Windows Phone and Windows 8. Windows Phone developers are already comfortable building Silverlight applications and luckily those skills apply equally well to Windows 8. But there’s a powerful new framework called the Windows Runtime (WinRT) that you need to know about, and we also need to understand and write asynchronous code.

 

WinRT

When the Windows team was planning the developer story for Windows 8 they were given some hard challenges to solve. Though I haven’t seen the actual design specs, I imagine some of the goals went something like this:

  • It must be fast and fluid (to support Metro design)
  • It must expose capabilities of the underlying OS in a way that’s both secure and easy to use
  • It must be easily accessible in all of the supported languages
  • It must feel natural to use in each of the supported languages
  • It must provide equal capabilities across all of the supported languages

 

Those are some pretty lofty goals, especially when you consider that the languages Microsoft wanted to support included C#, VB, C++ and JavaScript. To my knowledge no framework has ever been created that provides equal capabilities and feels natural to use across so many languages. But that’s exactly what the product team did when it created the Windows Runtime (WinRT).

To C++ developers WinRT looks a lot like a C++ library that’s been linked to the project. To JavaScript developers WinRT looks a lot like an external .js file that’s been referenced. To C# and VB developers WinRT feels a lot like the .NET framework. In fact it feels and looks so much like .NET that if you don’t know exactly what to look for you might just assume it is. This caused some confusion at our //build conference and is still a point of confusion for many developers today, so I’d like to try and demystify it a little for those of you coming from Windows Phone. The truth is that WinRT is actually closest to what the C++ developer sees. WinRT is a runtime, created by the Windows team, written in C++ and exposed to all four languages in a natural way. This is probably easiest to understand by looking at a code sample (or three).

 

C++
ImageEncodingProperties^ imageProperties = ref new ImageEncodingProperties();
imageProperties->Subtype = "JPEG";
imageProperties->Width = 320;
imageProperties->Height = 240;     

auto opCapturePhoto = m_mediaCaptureMgr->CapturePhotoToStorageFileAsync(imageProperties, this->m_photoStorageFile);  

 

C#
ImageEncodingProperties imageProperties = new ImageEncodingProperties();
imageProperties.Subtype = "JPEG";
imageProperties.Width = 320;
imageProperties.Height = 240;

await mediaCaptureMgr.CapturePhotoToStorageFileAsync(imageProperties, photoStorageFile);

 

JavaScript
var photoProperties = new Windows.Media.MediaProperties.ImageEncodingProperties();
photoProperties.subtype = "JPEG";
photoProperties.width = 320;
photoProperties.height = 240;

mediaCaptureMgr.capturePhotoToStorageFileAsync(photoProperties, photoStorage).then(…

 

The code snippets above are from the MSDN Sample Media capture using webcam. These 5 lines of code turn on the web cam, capture an image, resize it to 320 x 240 and save it as a file in JPEG format. (Yes, you really can use the webcam and save local files using JavaScript – assuming the user has given your app permission to of course.)

Notice that the 5 lines of code use the same object names and property names whether you’re using C++, C# or JavaScript. And notice that the name casing changes from Title Case for C++ and C# to camel Case for JavaScript. This ability of the WinRT to “morph” into your language of choice is called Projection and it’s pretty amazing. The WinRT is written in C++ to be as fast as possible, but its objects and capabilities can be used in all supported languages just as if the WinRT were written natively in that language.

image

As you can see from the graphic above, the surface area of WinRT is immense. All four languages are provided with unified APIs for storage, media capture, sensors, GPS and more. With the sheer size of the WinRT and how transparently it’s projected, no wonder developers are mistaking it for the “New .NET”.

So is the .NET framework dead? Not at all. In fact it’s still alive and well with version 4.5 in desktop mode. And though WinRT provides most of the things C# developers need to build Metro style apps, a good chunk of the .NET framework is available in Metro mode too. This can blur the lines between what’s .NET and what’s WinRT, but a good rule of thumb is that WinRT components come from Windows.* namespaces and .NET components come from System.*.

For an in-depth look at leveraging the .NET framework inside Metro style apps, see .NET for Metro style apps overview.

 

WinRT Components (and WinMD)

Now that you know what the WinRT is and how projection works, you might be thinking “Wouldn’t it be cool if I could create my own WinRT libraries and sell them or share them with other developers?” Well you can, and they can be written using C++, C# or Visual Basic. Though you can’t author WinRT components using JavaScript today, components created in any of the other languages are automatically projected and are usable by all of the languages - including JavaScript.

Creating a WinRT component is a lot like creating a class library. In fact, class library projects can be converted to WinRT libraries by simply changing the project output from “Class Library” to “WinMD File” (MD stands for MetaData). There are rules that must be followed when creating WinRT components because of the automatic projection system. For example, public methods and properties must only return native WinRT types or basic .NET types like string and int. Private methods and variables, however, can be any .NET type supported in Metro style programs. There are other rules to be aware of, such as how collections are mapped and how to implement asynchronous methods. Luckily, Visual Studio enforces these rules at compile time and even offers instructions on how to correct mistakes if they’re made.

You can read all of the rules and requirements in the article Creating Windows Runtime Components in C# and Visual Basic. Keep in mind that .NET class libraries are still supported, so if you aren’t looking to interop with C++ or JavaScript you may not need to create a WinRT component at all. If WinRT is what you need, be sure to check out Creating a simple component in C# or Visual Basic and calling it from JavaScript.

 

Async and Await

You may have noticed the new await keyword in front of the call to CapturePhotoToStorageFileAsync in the sample above. When you hear the Windows team say ‘Fast and Fluid’ they mean it. And to stand behind that statement they’ve made every single WinRT call that could possibly take longer than 50 milliseconds asynchronous.

But asynchronous programming is hard right? I mean, one can just do a search for “Silverlight asynchronous” and find a long list of developers who were upset coming from the desktop world to find they couldn’t do blocking calls to online services anymore. But developers weren’t upset that they couldn’t block the UI thread, they were upset at how much uglier their code looked and how much harder it was to maintain. To illustrate this problem, consider the following Silverlight code to download a page from a URL:

private void DownloadPage()
{
    WebClient client = new WebClient();
    client.DownloadStringCompleted += DownloadStringCompleted;
    client.DownloadStringAsync(new Uri("http://www.bing.com"));
}

private void DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
{
    // Only proceed if there wasn't an error
    if (e.Error == null)
    {
        …
    }
}

 

In this example control flow actually leaves the DownloadPage method and moves to an entirely new method called DownloadStringCompleted. Any data (or state) that existed in the DownloadPage method is not available in DownloadStringCompleted. If a choice needs to be made in the callback based on variables defined in DownloadPage, they have to be promoted to class level variables or somehow passed to the handler.

Anonymous methods and lambdas help this pattern tremendously. For example, we could rewrite our sample above to look like this:

private void DownloadPage()
{
    WebClient client = new WebClient();
    client.DownloadStringCompleted += (o, e) =>
        {
            // Only proceed if there wasn't an error
            if (e.Error == null)
            {
                …
            }
        };
    client.DownloadStringAsync(new Uri("http://www.bing.com"));
}

 

Now the handler is actually inside the DownloadPage method and has access to all its local variables. (This works, by the way, because of a lesser-known feature of modern programming languages called closures.)

The problem with this approach is that it leads to what I like to call “Death by Indention”. For example, if the handler now needs to call something else async, another lambda is required.

private void DownloadPage()
{
    WebClient client = new WebClient();
    client.DownloadStringCompleted += (o, e) =>
        {
            // Only proceed if there wasn't an error
            if (e.Error == null)
            {
                WebClient client2 = new WebClient();
                client2.DownloadStringCompleted += (o, e) =>
                    {
                        // Only proceed if there wasn't an error
                        if (e.Error == null)
                        {
                            …
                        }
                    };
                client2.DownloadStringAsync(new Uri("http://www.microsoft.com"));
            }
        };
    client.DownloadStringAsync(new Uri("http://www.bing.com"));
}

 

And if that handler needs to call another async method, well I think you see the problem. The code is messy and it doesn’t feel natural. We’re even writing what we want to do with the results before we write the lines of code that fetches them! It feels “upside down”. All this work is necessary because we’re asking developers to compensate for the fact that asynchronous methods complete using callbacks.

But what if we could write code that looks like it’s blocking but is actually yielding time while the asynchronous call completes? That’s what the await keyword does and with it our sample can be written like this in Windows 8:

private async void DownloadPage()
{
    HttpClient client = new HttpClient();
    string bing = await client.GetStringAsync("http://www.bing.com");
    string ms = await client.GetStringAsync("http://www.microsoft.com");
}

 

Which one would you rather maintain? :)

To learn more about why asynchronous programming is so important on Windows 8 see Keeping apps fast and fluid with asynchrony in the Windows Runtime. To dive deep on how the async keyword works and to learn advanced topics like receiving progress reports, check out the awesome post Diving deep with WinRT and await.

 

In the next article I’ll start diving into API differences between Silverlight for Windows Phone and the Windows Runtime for Metro style apps.

WP to W8: View States using Visual State Manager

April 22, 2012 9 comments
This article is part of a series about my experience porting apps from Windows Phone to Windows 8. Official porting guidance can be found here and don’t forget to follow the Building Windows 8 blog and the Windows 8 App Developer blog for the latest information.

If you are currently working on a Windows 8 app that you’d like reviewed for possible early entry into the marketplace, please contact me.

 

In my last blog post I talked about using the Visual State Manager to deal with different screen resolutions and the new Snapped view. I thought it would be helpful to share an example of how to do it.

image

In the screenshot above we have a simple user interface for a music player. The left side shows album art and the right side shows the track list on top of the playback controls (Play, Pause, Stop, etc.). Notice that the screen is divided into three rows and two columns and notice that the rows are different heights. These will be important in a minute.

The playback buttons were created using the technique I described in my previous post. I copied AppBarButtonStyle and removed the label under the circle. Then I changed the Content property for each button to the character I needed for each “icon” (in Sego UI Symbol). Finally, the buttons were grouped into a horizontal StackPanel which allows me to organize and scale them as a group. Since the buttons are vector (font) based, I can make them extra large by selecting the containing StackPanel and setting it’s scale to 2.

image

With this layout we basically get ‘Filled’ view for free. The grid is a little more narrow so the track list isn’t as wide, and the album art shrinks just a little. But it still looks great so let’s focus on ‘Portrait’ mode next.

As I mentioned in the previous article, to properly work on View States in Blend right now you need to change both the Platform tab and the States tab. Let’s change to the ‘Portrait’ view (Platform tab) and to the ‘FullScreenPortrait’ state (States tab).

image image

Now let’s make the changes for Portrait:

  1. Select the AlbumArt image and change RowSpan to 0 and ColumnSpan to 2. Now the Album Art is at the top and is centered on the screen.
  2. Select the TrackList and change Column to 0 and ColumnSpan to 2. Now the track list is also centered on the screen.
  3. Select the PlaybackControls panel and change its Column to 0 and ColumnSpan to 2. Like the track list, the playback controls are now centered on the screen.

 

Save your work. It should look something like this:

image

Now it’s time to work on Snapped view. Lucky for us it’s a lot like Portrait view. In fact, we’ll do exactly the same steps we did with Portrait but we’ll add one more step at the end.

Switch to ‘Snapped’ view (Platform tab) and ‘Snapped’ state (States tab).

image  image

Now the changes for Snapped (same as Portrait):

  1. Select the AlbumArt image and change RowSpan to 0 and ColumnSpan to 2. Now the Album Art is at the top and is centered on the screen.
  2. Select the TrackList and change Column to 0 and ColumnSpan to 2. Now the track list is also centered on the screen.
  3. Select the PlaybackControls panel and change its Column to 0 and ColumnSpan to 2. Like the track list, the playback controls are now centered on the screen.

 

The album art scales nicely. The text looks larger because the list isn’t as wide. We might want to decrease the font size but I think it actually looks good so I left mine. The biggest offenders are the playback controls. They’re way too big for the space.

image

The cool thing about our buttons is that since they’re vector, we can scale them back down just the same way we scaled them up. Select the PlaybackControls stack panel and scale it back down to 1x.

image

Now we have a cool little snapped view for our music player.

image

Run the application and test it in portrait, landscape, filled and snapped views. Because the page inherits from LayoutAwarePage, the correct Visual State is loaded on each change and our UI works great. You can play around with changing other properties and you can even test more complex layouts by adding additional controls and showing and hiding them based on the view state. Pretty cool!

 

Download the Sample

The sample project includes both a ‘Starting’ point and a completed version. Note that the app isn’t a functional music player, it’s just a sample layout to help you get familiar with the Visual State Manager.

Categories: Development, UX Tags: ,

WP to W8: User Interface

April 12, 2012 7 comments
This article is part of a series about my experience porting apps from Windows Phone to Windows 8. Official porting guidance can be found here and don’t forget to follow the Building Windows 8 blog and the Windows 8 App Developer blog for the latest information.

If you are currently working on a Windows 8 app that you’d like reviewed for possible early entry into the marketplace, please contact me.

 

In this article I want to expand on the information already available about porting user interfaces from Windows Phone to Windows 8. The most important place to start is an article titled Porting Silverlight or WPF XAML/code to a Metro style app on MSDN. It covers slight changes in the Application object, Window object and Navigation system. It also covers more involved changes to the Resource model and to Touch. I’ll talk briefly about touch at the end of this post and I’m dedicating an entire article to resources (hyperlink here when it’s done). If you haven’t done so yet, consider switching over to the official guide and coming back here when you’re done.

 

Metro

One of the biggest adaptations developers needed to make coming from any other platform to Windows Phone was learning to use the Metro design language in an effective way. If you’ve already built a successful Windows Phone app, chances are you’ve already made this change. Still, there are new and unique guidelines for Windows 8 apps that you need to become familiar with. In fact there are guidelines for things you might not have thought about having guidelines for, like drag and drop and edge-based animations.

These guidelines exist to make the Windows 8 experience consistent from application to application, which is important because consistency builds confidence for users. Luckily a good chunk of the work is already done for you simply by leveraging the built-in controls. Even if you’re creating highly customized content or your own controls, WinRT makes it easy to fit in by providing standardized animations and transitions right out of the box.

To learn more about the standardized animations and transitions see Quickstart: Animating your UI. For tons of great Metro guidance see Making great Metro style apps, UX guidelines for Metro style apps and design.windows.com.

 

Controls

Windows 8 of course has all the basic controls you’re used to like Button, CheckBox, ListBox, etc. As you may have heard, though, the namespaces are a little different. For the most part, simply changing references from System.Windows to Windows.UI.Xaml will get most of the basic tags working. But since we’re on the topic of namespaces, it’s important to note that the namespace syntax itself has changed.

Here’s the old syntax:
xmlns:myns="clr-namespace:xxx.yyy/assembly=zzz”

And here’s the new one:
xmlns:myns="using:xxx.yyy"

Not only is the new syntax simpler, but it leaves all of the assembly management to the underlying framework. This change does impact how you create things like strings though, so I highly recommend you read Porting Silverlight or WPF XAML/code to a Metro style app for more details.

You might be surprised to learn that Windows 8 does not include the Panorama or Pivot controls from Windows Phone. Keep in mind those controls were created to deal with small screen real estate, which isn’t much of a problem on Slates and desktop monitors. It’s vitally important to make good use of all the screen real estate available and the new SemanticZoom FlipView and GridView controls can help you accomplish this. Though FlipView could potentially be used to create sliding panels similar to a Panorama, don’t get caught up in trying to port your phone experience as-is. Instead, spend plenty of time playing with Windows 8 applications and understand the new controls. A GridView combined with SemanticZoom can offer a better experience on a larger screen than a Panorama would.

In my opinion, one of the most aesthetically pleasing apps in Marketplace right now is Flixster. Not all of the features from Windows Phone made it into the current demo, and it doesn’t currently use SemanticZoom, but I think it shows a good migration from Panorama to the new Windows 8 style.

image

After you’ve played around with Windows 8 for a while, check out Quickstart: adding ListView and GridView controls and Quickstart: adding SemanticZoom controls.

 

M-V-VM, Data and Portability

“Oh no!” you say, “Now that there are new controls all of my UI code has to change!” Not true if you’ve been following the popular M-V-VM pattern. M-V-VM allows you to separate the underlying business logic from what’s displayed on the screen. With M-V-VM there’s a ViewModel that provides data and commands that the View can bind to. If you’ve already done the work to put M-V-VM in place, your XAML will change but the underlying ViewModel may not have to change at all.

There are other interesting tricks you can employ to share code with Windows Phone. For example, Visual Studio 11 has the new Portable Library project which allows you to create DLLs that can be referenced and used in both projects.

If you haven’t been using M-V-VM or if you’d like to learn more about these techniques, be sure to read Improving Maintainability. To learn more about data binding in Windows 8 (including Grouping for GridView and SemanticZoom) see the article Data binding with XAML and the XAML data binding sample.

NOTE: There’s currently a bug in Consumer Preview with data binding to ObservableCollection<T>. The XAML data binding sample provides a workaround.

 

 

AppBar

The Windows 8 AppBar feels similar to the Windows Phone Application Bar, but there have been several improvements. One of the improvements I’m quite happy to see is support for data binding. I mentioned commands as part of the M-V-VM pattern above. In the current Windows Phone SDK there’s no way to bind AppBar buttons to M-V-VM commands, but in Windows 8 you can.

Windows 8 will run on a wide range of devices so user interfaces need to scale. Because of this need to scale, vector graphics are preferred for iconography over bitmap images. (WinRT has mechanisms for scaling bitmaps beautifully too, which I’ll talk about below.) With scalability in mind, the Windows team did something I think is very cool: they embedded the most common AppBar icons in a font called Sego UI Symbol. Font scaling works very well for this purpose, and if you drop an AppBarButton onto the art board and change its Scale (Transform panel) you’ll see what I mean.

image

Unfortunately there isn’t currently an easy way to choose icons from the font using Blend or Visual Studio, but there are a few tricks. First, you can run Character Map and select Sego UI Symbol. Once selected, scroll down to the bottom and you’ll see the icons.

rvd0olh5

Click the ‘icon’ you want, click Select and then Copy. The ‘icon’ is then placed on the clipboard, ready to be pasted it into any button (or text block) that’s using Sego UI Symbol.

Tip: To run the Character Map tool, from the start experience just start typing the word “character”. The start experience will automatically switch to ‘All Applications’ mode and begin filtering the list on what you type.

wrhfojub

 

Now to make things a little easier on developers, Visual Studio includes a file in every project called StandardStyles.xaml. This file has within it a number of predefined button styles that are setup to use these icons. Blend allows you to drag these styles out from the asset panel to automatically create a button with the style already applied. So, for example, if we wanted to create a help button we could drag out the following:

image

It turns out that Sego UI Symbol includes around 150 icons, but StandardStyles.xaml currently shipping with Visual Studio only includes styles for 29. You can either edit the style and use the Character Map trick above, or you can download an Updated StandardStyles from Tim Heuer. His awesome blog post XAML AppBar Button Styles for Windows 8 covers this topic and using these styles in even more depth.

150 icons is great, but what if you don’t find the icon you’re looking for? Don’t worry because there are several other really great options remaining. One of my favorites is the awesome Metro Studio package by Syncfusion.

image

This package includes over 600 Metro style icons and gives you unprecedented control over their presentation. You can change the background type (none, square, outlined circle, filled circle), the padding, the background color, icon color and even the size. You can export the customized icon as .png, but even better you can copy the customized icon as a scalable XAML ready to be pasted into your applications resource dictionary. How much does this incredibly cool package cost? $0.00. Yup, free. Just drop ‘em a note to say thanks on Twitter, Facebook or Google+.

Okay, so that’s 750+ icons. But what if you still can’t find what you’re looking for? Well, there are plenty of other icon packs (just search for Metro Icons) and you can always create exactly what you need using Expression Design, Adobe Illustrator or my new favorite InkScape.

image

InkScape is free, open source, and can save as scalable XAML natively.

 

Scaling

Windows 8 supports a wide range of devices with varying resolutions and DPIs (dots per inch). This is different from Windows Phone which today supports only one resolution. Those who have written apps for Android might know what a challenge this can be, but fear not! Once again WinRT does most of the heavy lifting for you.

First, Windows 8 supports ViewBox, just like Windows Phone, which is great for games and fixed-layout interfaces. On the other hand, GridView and Grid are great tools for creating flexible layouts. Something you might not expect is that even in flow layouts, Windows automatically increases the scale of some UI elements as the DPI goes up. This automatic scaling makes sure that items like buttons and sliders are just as easy to grab with your finger at 260 DPI as they are at 130. This scaling, however, does not happen continuously across the full range of DPIs. Scaling only happens at certain thresholds. This is because apps still use bitmap images and bitmaps don’t tend to look great when they’re scaled to arbitrary sizes.

Graph shows 3 sweet spots to be 1366x768, 1920x1080, and 2560x1440 
from the Building Windows 8 blog post Scaling to different screens

The scaling thresholds are set at 140% and 180% of the baseline resolution 1366 x 768. When these thresholds are reached, vector graphics inside ‘auto-scale’ elements are automatically scaled too. But what about bitmap images? Well, the WinRT resource system is smart and it will look for higher resolution images (based on a naming convention) to be automatically swapped in when the scale changes. The key takeaway, for me at least, is to design at 1366 x 768 and use the Platform tab in Blend and the Simulator to test designs at all resolutions and DPIs. At the very high end of the scale, it’s probably also prudent to consider modifying layout or swapping in different Data Templates to make the best use of the space.

More than anything I highly recommend the excellent article Scaling to different screens on the Building Windows 8 blog. It covers everything I covered here in far greater detail and it gives an inside peek at the factors that lead to this design. I really did find it fascinating. Guidelines for scaling to pixel density and Guidelines for scaling to screens are two other excellent references that cover naming conventions, fixed and flex layouts as well as general “Do’s” and “Don’ts”.

 

View States

Windows Phone developers are used to having the entire screen available for their app. Even system dialogs like phone calls and toasts appear on top of the application and don’t change available real estate. A Windows Phone developer today can design a user interface at 480 x 800 and expect it will work across all Windows Phones (though Microsoft has always reserved the right to add additional resolutions at some point).

In addition to supporting a much broader range of screen sizes and resolutions, Windows 8 applications are also required to support two new view states: “Snapped” and “Filled”.

image

In the screenshot above, Cut the Rope is running “Filled” and Music is running “Snapped”. These two new states are what allow two normally full-screen applications to run side-by-side and share the screen.

I mentioned in the Scaling section that ViewBox and Grid are your best friends for dealing with multiple resolutions. The same is also true when it comes to Filled and Snapped. Cut the Rope was actually written in JavaScript, but the screenshot above shows what would happen if a ViewBox was designed to be “Full” at 1366 x 768 and then put into “Filled” mode at 1024 x 768. Notice the letterboxing (black bars on top and bottom)? Letterboxing is preferable to stretching and is acceptable for games and videos. Apps that use flexible layout (Grid, GridView, etc.) will automatically adapt to fill this space.

It’s very important to point out here that the Music app looks quite different in Snapped mode then it does in full screen. The rows of album art and the large track bar have been replaced with a small and concise listing of tracks. This fairly radical change allows the Music app to remain highly useful even with small amount of space it has. It’s no surprise that users will expect this type of behavior from your apps too.

If all this sounds daunting, you’re not alone. When I first read about the Filled and Snapped states my head was filled with visions of user controls, Xaml hacking and showing and hiding things in code. Thankfully, I couldn’t have been further from the truth.

Many Windows Phone apps today support landscape since we basically get it for free. Some of the more advanced apps are even using the Visual State Manager to switch to a customized layout that looks better in landscape mode. This same trick can be used for “Snapped” and “Filled”, and the Visual Studio templates help you do exactly that out of the box.

Note: An introduction to the Visual State Manager is outside the scope of this article, but if you’ve never used or seen it before I recommend you check out the article and accompanying video Creating Control Skins with Visual State Manager on Christian Schormans blog.

 

Whenever you create a new project, Visual Studio automatically adds a file under the Common folder called LayoutAwarePage.cs. LayoutAwarePage inherits from Page and adds four new visual states to itself:

image

As you can see, the visual states correspond to the four possible view states that your app can be in at any given time. Using the Visual State Manager you can show, hide or change virtually any property of any element on the art board and those changes will only be applied when your app is running in that state.

For example, let’s take a look at GroupedItemsPage (part of the ‘Grid Application’ template included with Visual Studio). Here GroupedItemsPage is in the FullScreenLandscape state  (click for larger view):

image

And here it is in Snapped state:

image

This works because the page actually has both a GridView and a ListView on it at all times. When the Visual State changes, one control is hidden and the other is shown (accomplished by changing the Visibility property).

image

I’d like to pause and point out that in the ‘Snapped’ screenshot above, the app still looks like its filling the whole screen. That’s because the Visual State Manager and the Platform tab aren’t currently wired together in Blend. In other words, telling Blend that you want to see what the page will look like when viewed Snapped on a 10” slate doesn’t automatically trigger the Visual State Manager to switch to the Snapped state. (Remember, this is automatic switching is handled at runtime by LayoutAwarePage which Blend knows nothing about). So, to properly preview your designs in Blend you should set the correct View on the Platform tab:

image

and set the corresponding State on the States tab. When they’re both in sync, the art board should show what you’d expect to see at runtime on that device (assuming you’ve got design-time data).

image

I dedicated the second post in this series to a step-by-step example of using this technique. See View States using Visual State Manager. And for more info see Designing flexible layouts and Guidelines for snapped and fill views. These pages provide additional guidance on scaling your interface to fit and be useful in Snapped view.

 

Keyboard

The on-screen keyboard is an integral part of Windows 8 and there’s little doubt that external key devices (i.e. remote controls) will continue to grow in popularity as well. With that in mind, all Windows 8 key events return a VirtualKey enumeration rather than a literal keyboard scan code.

If your Windows Phone app somehow uses scan codes, either update it to use the new enumeration (best) or check the KeyEventArgs.KeyStatus.ScanCode property to see if the virtual key has a mapping to the original scan code.

For more information see Plan for accessibility.

 

Touch

Windows 8 is designed to be “touch first”, but it’s also designed to work exceptionally well with a mouse and stylus. To make supporting all three pointing ‘devices’ as easy as possible for developers, mouse-specific events were replaced with new unified Pointer events like PointerEntered and PointerPressed.

Something else I found really interesting is that individual pointer events can be enabled and disabled per-element. On Windows Phone you can “hide” any element from all touch events by setting IsHitTestVisible=false. On Windows 8 you can hide it from specific events by setting properties like IsRightTapEnabled.

For more information see Responding to user interaction.

 

Well, that’s it for the User Interface article (whew!) Be sure to bookmark the series and check back soon for more articles on porting Windows Phone apps to Windows 8!

Windows Phone to Windows 8

April 12, 2012 11 comments

Those of you who know me know I’ve dedicated the last 9 years to developing on and evangelizing .NET. Of those 9 years, 6 have been dedicated to WPF / Silverlight and the last 2 have been laser focused on Windows Phone. So when my manager asked if I was interested in expanding my skills to Windows 8 and helping other Windows Phone developers do the same, I jumped at the chance.

This post is the first in a series that will continue to evolve as I make the transition. So you know what to expect over the coming weeks, here are my primary goals:

First, I want to avoid replicating any content that already exists. I might summarize a topic and add my own thoughts or tips, but I think it’s far better for me to link to official materials than try to maintain new content of my own. In fact the definitive source for information on this topic (and the place I started myself) is the article Migrate/port a Windows Phone 7 app to Metro style on MSDN.

Next, I want Windows Phone developers to be able to help each other. This series is about my own experience learning and applying the official guidance. I might have missed something or you may know a better way, and if so, please feel free to share in the comments.

I’m only going to talk about what’s currently available, which today is the Consumer Preview. Since I don’t work on the Windows 8 team I can’t really talk or guess about anything coming down the pipe. If you’re interested in the ongoing development of Windows 8 (and I know I sure am) tune into the Building Windows 8 blog and the Windows 8 App Developer blog.

My focus will be on migrating Windows Phone apps to managed Metro apps (C# and WinRT). By now you’ve probably heard that you can develop Windows 8 apps using JavaScript and HTML 5 too. I think that’s awesome, and if you want to learn more you can get started with this article.

Although I’ve spent a huge amount of time in my career on user experience and design, the Windows Design Guidelines for Metro are still evolving. I really think it’s best to let that team answer design questions, so I’ll be focusing almost entirely on framework and code.

 

Articles

Here are some of the articles I’m currently planning for the series:

  • User Interface – New and Different Controls, Porting UI, Form Factors
  • View States using Visual State Manager – Sample for handling Portrait and Snapped views using VSM
  • Application Framework – WinRT, Components, Asynchronous Code
  • API Mapping – Help mapping between Windows Phone and Windows 8 APIs and Xaml features
  • New Features – Timed Trial, In-App Purchase, Cloud Sync
  • System Integration – System Dialogs, Settings Pane, Permissions, Contracts
  • Localization – Supporting multiple languages
  • Media and Games – Local Folders, Background Audio, DirectX + XAML

 

The list may change over time but you can bookmark this page and the topics will become hyperlinks as I write them.

 

Are you building an app?

If so I’d like to hear about it. In fact, I’m one of only a few dozen field folks who can nominate your app for review and possibly early entry into marketplace. The quality bar is very high and ultimately the choice is up to the marketplace team, but at least I might be able to help you get noticed. If you’d like to talk more please contact me.

 

Official Resources

Finally, no amount of my wild rambling will replace the depth and quality of content already provided by the product teams. Be sure to check out and bookmark these amazing resources below:

Windows 8 Consumer Preview
Visual Studio 11 Beta
Additional Tools for Building Metro Style Apps
U.S. Windows Camps
Windows Developer Center
Windows Design Guidance for Metro
Building Windows 8 Blog
Windows 8 App Developer Blog
Windows Store Blog
Springboard Series for Windows 8