Office Hours

I hold weekly Office Hours on Wednesdays from 12pm to 2pm. On the 1st and 3rd Wednesdays of the month I hold them at the Microsoft store in the Galleria mall. On the 2nd and 4th Wednesdays I hold them online.

 

What are Office Hours?

Simple, it’s a time where I’ll be available for folks who are working on Windows 8 apps to come by and ask questions, show off apps in progress, and in general get help getting their apps in shape for publishing to the Windows Store. I’ll also will be able to help with Windows Phone 8 apps and Windows Azure questions… I just may have to do additional research before I can get you an answer.

 

Schedule

 

Please sign up for a slot via the ohours.org button above so that I can manage my time more effectively, and let me know if you’re coming to get some questions answered (and a heads-up on the questions will give me some time to do any needed homework) or just to spend some quiet time coding. Feel free to email me at jbienz [at] microsoft.com.

Windows 8 App Madness

 

We’re excited to announce the new Windows 8 App Madness Challenge for Students. With this challenge we hope to excite and motivate thousands of students to build Windows 8 apps over the next 2 months!

Overview:

· $100/app for up to five Windows 8 apps students publish to the Store.

· Accelerator: 4 sprints during the challenge. The student who publishes the most apps during the sprint wins a trip for 2.

o Facebook poll of students will determine the trip destination. Get voting!

· Timing: From February 12^th – April 11^th.

 

Here’s the link to get started:

http://aka.ms/Windows8AppMadness

WP to W8: Application Framework

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.

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: User Interface

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.

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.

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.

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.

 

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:

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.

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.

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.

 
^{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”.

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:

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):

And here it is in Snapped state:

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).

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:

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).

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

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

Windows 8 at Frontier Fiesta

Windows 8 is coming and it brings a huge change in mobile computing. If you own an iPad or an Android tablet today you know they give you longer battery life and a touch interface that’s easy to use on the go. Unfortunately they’re also completely different to use, have different apps, and none of your documents, photos and music are available on them unless they’ve been synced. Imagine a computer with long battery life and apps that work just as well with touch as they do a keyboard and mouse. Then imagine popping a portable device out of a dock and taking absolutely everything with you when you go. That’s the power of Windows 8.

 

Get Windows 8 Beta at Frontier Fiesta

Starting Saturday the 24^th we will have 20 flash drives loaded with Windows 8 Beta and the Windows 8 Developer tools. Come by the booth with any laptop you’re willing to put beta software on and we’ll help you install fresh or upgrade to Windows 8. Just remember it’s a beta. Back up your important things before you arrive.

 

Win an 8GB Flash Drive

The first 20 students to install Windows 8 at the booth will get to keep one of the 8GB flash drives. You have to come back at the end of the event to claim your prize though, we’ll need em!

 

Learn to Use Windows 8 and Build Apps

Jared Bienz from Microsoft will be at the Cougar CS booth Saturday from 11:00 AM to 6:00 PM. He’ll have a prototype Windows 8 device and he’ll show how to use the OS and answer questions about the dev tools.

If you’re interested in building apps for Windows 8, be sure to come by the booth at 3:00 PM. Jared will demo using Visual Studio 2011 and the latest Expression Blend tools to design, build and simulate running a Windows 8 app on different devices.

169 Apps in 24 Hours

As a Mobile Evangelist a big part of my job is trying to figure out how to get people excited about building apps. My team and I have tried a number of strategies this year ranging from training to creating tools and even hosting our own events. Unfortunately, we just weren’t reaching the numbers we were hoping for and I had this nagging feeling we were missing something important. Over the holidays I worked with some really smart people to come up with a few ideas that resulted in 169 apps in 24 hours. This blog post is the story of how.

Back in October I bumped into Paul DeCarlo at Houston Techfest. I had originally met Paul a year earlier when I was teaching Windows Phone development at U of H and Paul was completing his masters. In the time that followed, Paul actually started his own side business selling applications in the Windows Phone marketplace and business was good. I had an idea that I wanted to do something with students, but I didn’t quite know what. While we were talking at Techfest I found out that Paul was the Microsoft Campus Rep, Asus Campus Rep and Rockstar Campus Rep all at the same time while he was at U of H. He told me about these crazy LAN parties where they would bring in Rockstar and bands and stay up all night. I knew there was an idea there, but I didn’t know what it was.

Fast forward to December and Paul was reaching out to me because he had a friend he wanted to nominate as the new Microsoft Rep at U of H. That friend was Rick Gentry and I was able to help get Rick nominated and hired in that same month. About that time I was talking with Deanna Robison about our marketing budget and about trying to excite students. We kicked around the idea of buying a bunch of $10 Amazon cards as a way to entice students to build their first app. She also knew we were getting a bunch of phones. We didn’t know how many but we liked the idea of giving students a phone for every three apps they got into marketplace.

On a Tuesday night in early February, Paul and Rick and I all got together at a small Vietnamese place on Bellaire. I got Microsoft to pay for the meal and the three of us brainstormed for several hours about how we could do something big at U of H. We knew we wanted apps and we knew we wanted to include as many people as possible. Going on the assumption of cards and phones, we identified three different “groups” of students that might attend our event. The first group were Sr. CS students who had development experience and just wanted the challenge. The second group were actually business students who didn’t have strong development skills but were interested in being able to say they had put an app in the marketplace. The third group were Jr. CS students that were somewhere in between. Meaning they had some development experience but were new to coding and maybe hadn’t seen .NET before.

For each group of students we tried to identify what we could do to make that group a success. For the Sr. students we thought it’d just be best for me to sit with them and answer all their questions. Easy enough. For the business students we thought it would be great to teach them AppMaker. We knew we needed something different for the Jr. developers, but what? Something that could take a little experience and turn it into a lot. Then I remembered the awesome starter kits people like Chris Koening and Danilo Diaz had been creating and I put together a Resources for New Phone Developers blog post that ended up getting used at BAOC and other student events. One starter kit in particular really stood out to us, and that starter kit was the Social Viewer template by Nick Randolph. Paul had recently started the basics of his Just a Fan apps on the Social Viewer template and Social Viewer had far more functionality than AppMakr ever would. More importantly, we had access to the Social Viewer Source. We knew we wanted to leverage it but we didn’t know how.

January ended up being a busy month. I reached out to Nick Randolph with the idea of creating a UI configuration tool for his Social Viewer template. The idea was to make Social Viewer as easy as AppMakr. Nick was very supportive and gave me access to everything I needed. But then things started to fall apart when I found out that our Windows Phone hackathon was going to be competing for students against an Android hackathon scheduled at the same time. We decided it would be best to either lead the Android event or follow it so that we weren’t competing. But the Android event was scheduled for the third week of February and pushing ours out into March would be too late. It would have to be in early February, and to make matters worse, new rules were coming down that required the use of dev tools at our events (meaning AppMakr would not be allowed). We did manage to get an exception for AppMakr since the event was already scheduled, but we knew we needed a strategy that would be successful without it going forward.

On January 26th, Paul, Rick and I stood in front of a room full of Cougar CS students at U of H. Paul gave a presentation on the amount of money he’d made creating apps for Windows Phone and we talked about why having a smaller marketplace is actually better for developers. We closed by announcing the Windows Phone hackathon and, thanks to Deanna, $1,000.00 worth of Amazon cards and 10 phones. We knew we could get more phones and cards, so we hinted that there would be something going on past the event too. All of the students seemed interested and even suggested we plan it for a full 24 hours. The three of us went home excited that night. Rick created a flyer and I started work on a super secret project.

Two weeks later AppFactory was born and I let Paul know what I’d been working on.

AppFactory is, for all intents and purposes, a glorified MSBuild script with a pretty front-end. It’s purpose in life is to take template projects (or starter kits) and turn them into factories of applications. Paul had actually a simplified version of AppFactory for his Top Music Videos and “Just a Fan” suite of applications. Paul wasn’t alone. Anyone who’s built a company based on multiple applications on a similar codebase knows this problem. You start from a template, add custom logic, bring in your data, sprinkle in artwork, reconfigure services, build the solution, rinse and repeat. This problem has been solved before, but it’s always been solved uniquely for one project and never shared for others to use. And that, specifically, is what I wanted to fix with AppFactory. I think Paul was a little surprised and shocked to see AppFactory, but he realized right away what it meant for him. It meant he could get out of managing his build process and focus specifically on the part he cared about – his IP. In less than 24 hours Paul had completely replaced his custom build process with AppFactory. 24 hours after that he had used AppFactory to rebuild all 300 Just a Fan Applications. AppFactory would come back later to help with our event.

On February 10th, Paul Rick and I met for dinner on the U of H campus just before our hackathon. We had Asian food, as seems to be our tradition, and we talked about how we thought the night would go. I personally expected about 25 students and I expected to lose half of them before the night was over. We knew we’d start with Rick giving a presentation on AppMakr and follow it up with Paul giving an overview of the Social Viewer template. In a last minute stroke of genius we thought it would be cool for Paul to use a football team as the subject for his Social Viewer talk. Then, if we had time later, I could do a walkthrough of converting that to a suite of applications using AppFactory. We didn’t discuss the number of apps we thought we’d end up with, but I remember thinking I’d be happy to get 30 or 40 by the time we were done.

At 6:00 PM we walked into a computer lab packed wall-to-wall with students.

 

There were more than 50 people waiting to get started, and there were so many unexpected attendees that we had to overflow some of them into the next room.

Because we had so many people that had never done Windows Phone or .NET before, I started with a 20 minute overview of Visual Studio and Expression Blend. After running to the gas station to get us some ice, Rick followed up with his presentation on AppMakr. Not long after that Paul did his presentation on Social Viewer. It was awesome.

 

Rick, being the Rockstar promoter, got everyone hopped up on caffeine and within three hours we’d already given away our first phone.

 

The second phone went about 30 minutes later and the pace just kept up like that the rest of the night.

I knew a 24 hour event would be tough, even for college students hopped up on Caffeine. Luckily I had thought of that ahead of time and my awesome boss Nathan approved budget for food and for an XBOX. I brought my own copy of Rock Band and I also brought my own personal RC helicopters and RC trucks to drive around. Together with some loud music between Rock Band sessions, these distractions proved to be just enough to keep everyone going all night long. Though we did still lose probably 50% of the attendees at night, keeping 25 college students interested in anything for 24 hours is no small feat. Here’s a photo of us playing Rock Band at 4:00 AM.

About an hour after that picture was taken I was given a special surprise. Paul had been taking notes when he gave his Social Viewer presentation and he noticed a team of four guys were really paying attention. Entirely on his own, and without me knowing it, Paul sat down with that team and walked them through using AppFactory to take his football sample and turn it into a suite of 32 applications for the NFL. Those guys showed up with very little programming experience and left with $320, a phone for each of them and the start of a new business. It doesn’t get any better than that.

When 6:00 PM rolled around on Saturday I was surprised at how lively everyone was; even me. I felt like I could have stayed a few more hours (and part of me really wanted to since apps were still getting submitted at a regular rate) but luckily I had just kicked of AppTastic with U of H allowing students to continue submitting apps even after the event was over.

When I finally sat down and really looked at the spreadsheet I couldn’t believe my eyes. I checked and double-checked to make sure there wasn’t a copy-and-paste mistake. Did we really make 169 apps in 24 hours? We did. Not only that but I had created a column called ‘Is AppMaker’ to keep an eye on how we were doing with custom dev. Out of 169 apps, 104 were custom code. That means that only 38% of the applications were AppMakr. Many of the students started with AppMakr to get something done quickly and then moved on to custom code. Lots of the AppMakr apps were quality work too, like the Recipes app and Adventure Time.

 

All in all we consumed more than $300 worth of pizza, 36 kolaches, a dozen doughnuts, 2 crates of Rockstar and 12 liters of softdrink. We gave away $1,500.00 worth of Amazon gift cards and I still owe $180 more. We gave away 10 phones and I still owe 31! This has been one helluva learning experience, and I hope I get to do it again.

 

Facebook Event Page – Lots of great commentary, especially the oldest pages.

Photos of the Event – Photos shown in this article and many more.

App Photos – Photos of 48 custom applications written at the event.

Sharing Data Across Pages on Windows Phone

Most Windows Phone applications (and for that matter Windows 8 applications too) will quickly evolve to include more than one page. Very simple “utility” apps like calculators might get away with a single page, but even applications that fit a bunch of information on one screen using a Panorama will eventually end up navigating to a second screen when the user taps on something. Single page applications are simple because all of the data is in one place. As soon as a second page gets added to the application the question always comes up “How do I share data between pages?”

Windows Phone has at least three different recommended options for sharing data across pages and I’ll cover all three in this article. These tactics will apply to Windows 8 too, but I’ll wait until after the beta to see if there’s anything special to add here for Windows 8.

The first option for sharing data is to pass it as part of the query string when you navigate to the page. If you’ve done any web development before this method should feel right at home. On Windows Phone, to navigate from Page1 to Page2, you write code like this:

NavigationService.Navigate(new Uri("Page2.xaml", UriKind.Relative));

But what you might not realize is that you can also pass parameters as part of the navigation like this:

NavigationService.Navigate(new Uri("Page2.xaml?ProductId=114&Rating=5", UriKind.Relative));

Now the parameters ‘ProductId’ and ‘Rating’ are being passed to page2.

The next question, obviously, is how do to receive those parameters on page2. that is accomplished by overriding a special method on the page class called OnNavigatedTo. In our example above we would write something like this:

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    // Let base handle
    base.OnNavigatedTo(e);

    // Get the ProductId
    string productId = NavigationContext.QueryString["ProductId"];

    // Get the Rating
    int rating = int.Parse(NavigationContext.QueryString["Rating"];
}

There are some important things to notice here. First, the page grabs these values through a special object called the NavigationContext. Second, I’m not showing it here but these named values aren’t guaranteed to exist so we really should check for them before we try to use them. And finally, the only type of data we can pass this way are strings. That’s why we have to use int.Parse for the rating value.

Query string parameters work well for simple values. In fact query string parameters are how data gets passed into your application when it’s launched from a toast or from secondary tiles. Query string parameters can be pretty restrictive though, since they can’t be used to pass around objects (classes). Let’s take a look at a fairly common scenario which would be difficult to handle with query strings alone.

 

Let’s say we’re building a game and our game has three pages:

1. MainPage – Where the main menu to start a new game, watch the credits, view the high score, etc.
2. GamePage – The page where the user actually plays the game. This may be a Silverlight / XNA hybrid page or it could be just Silverlight.
3. HighScorePage – A page that shows the score rankings and the initials of the top players.

At first you may not think these pages need to share data, but think for a moment about how high score systems work. Obviously HighScorePage needs the data to be able to show it, but GamePage will also need the data to be able to notify the user when they’ve beat a high score and ask them to enter their initials. Even MainPage might want access to score data to be able to show the top player.

 

Whenever I see this sort of pattern I stop and ask myself if it makes sense to provide the data as a service. Now, ‘service’ tends to be an overloaded term in programming so let me be clear that what I’m talking about is a simple reusable component. (For more info see Service Orientated Architecture or SOA.)

If I was going to keep track of high scores as a service I’d probably make a simple class to represent a single score:

public class HighScore
{
    public string Initials { get; set; }
    public int Score { get; set; }
}

And then I’d make a simple ‘service’ class for managing the scores:

public class HighScoreService
{
    public Collection<HighScore> Scores { get; private set;}
    public void AddScore(HighScore score) {…}
    public void LoadScores() {…}
    public void SaveScores(){…}
}

What’s neat about making this a service is we’ve hidden the work of loading, saving and updating high scores in a single place. So today we can store high scores locally as XML and tomorrow we could change to storing high scores on a server and sharing them across devices. The only code that would need to change would be inside of HighScoreService and the rest of the application would work exactly the same.

Now that we’ve created our High Score service, how do we share it across pages? There are two easy ways to do this on Windows Phone.

 

The first option is to add the service as a property of the Application. Every Windows Phone project has a file called App.xaml.cs (it’s hidden under App.xaml in the Solution Explorer).  Inside of App.xaml.cs you’ll find something like this:

public partial class App : Application
{
    …
}

So every project has a class called ‘App’ that inherits from Application. You can add any properties you want to this class and they will be available on every page. So, we could add our service to our Application like this:

public partial class App : Application
{
    public HighScoreService HighScores { get; private set; }
    …
}

Then we could get to it on any page like this:

HighScoreService highScores = ((App)Application.Current).HighScores;

Let me explain the slightly ugly syntax there. Application.Current can be used from any code to get access to the currently running application instance. Unfortunately, what we get back is the generic Application base class so we have to cast it to the App version that’s part of our project before we can see our custom properties.

 

The second way we can share our high score service around our application is to make it a singleton. Making a class a singleton is basically saying “there can only ever be one of these things in existence at any time”. The way you implement it in .NET is like this:

1. Make all of the constructors private (if there is no constructor add a default one and make it private)
2. Make a static public property on the class called ‘Instance’ that returns the class itself.
3. Inside the “getter” of the property, check a static private variable to see if the instance has already been created.
4. If the instance hasn’t been created, create it. Otherwise return the existing instance.

Therefore our High Score Service converted to a singleton would look like this:

public class HighScoreService
{
    // Private constructor
    private HighScoreService() {}

    // Regular service stuff
    public Collection<HighScore> Scores { get; private set;}
    public void AddScore(HighScore score) {…}
    public void LoadScores() {…}
    public void SaveScores(){…}

    // Private 'instance' variable
    static private HighScoreService instance;

    // Public property to get at the single instance
    static public HighScoreService Instance
    {
        get
        {
            // If not created yet, create it
            if (instance == null)
            {
                instance = new HighScoreService();
            }
            return instance;
        }
    }
}

The code to access this service from any page would then look like this:

HighScoreService highScores = HighScoreService.Instance;

Or even more simply:

HighScoreService.Instance.AddScore(new HighScore()…);

 

Conclusion

So which pattern is better (adding the service as a property of the App class or making it a singleton)? Most of the time it comes down to a matter of preference. I personally think the “instance” code inside a singleton class make it a little uglier, but I also think the singleton pattern looks cleaner throughout the rest of the codebase. On the other hand, when you expose services as properties on the App class that gives the App a chance to create those services and potentially wire one service up to another. If you start finding yourself with a lot of services in a single application, especially services that depend on each other, you really should look into something like the Managed Extensibility Framework (MEF) or Unity to help you manage the services and dependencies.

Resources for New Phone Developers

I’m starting to do a number of hackathons with students and so I wanted to pull together a listing of resources that can help everyone get started quickly. Below is that uber list of resources. Hack on!

Education

• Jump Start Videos – 19 videos covering common developer tasks in Windows Phone.
• AppHub Catalog – Tons of tutorials, samples and articles on Windows Phone development.
• 31 Days of Windows Phone – 31 articles that show you step-by-step how to incorporate key features of the Windows Phone OS into you application.
• 31 Days of Mango – 31 articles that show you step-by-step how to incorporate new features in the of Windows Phone 7.5 OS into your application.

 

Additional Tools

• Silverlight Toolkit for Windows Phone – Includes more than 28 additional free controls like AutoComplete Box, List Picker, Hub Tile, MultiSelect List, Toggle Switch, Time Picker and more.
• Marketplace Test Kit – Included in the Windows Phone 7.1 tools (but not well known). This tool can check for many of the common mistakes that cause applications to be rejected before your app is even submitted into the marketplace.
• An image editing program such as PhotoShop, GIMP (free) or Paint.NET (free) – Needed for editing artwork, creating application icons and tiles, etc.
• A vector graphics editing program like InkScape (free) – May come in handy for editing scalable drawings that can be used in Silverlight applications and games.
• An audio editing program such as Audacity (free) – May be useful for editing and converting sound effects or music.

 

Starter Kits (Silverlight)

• GART – Create Augmented Reality apps and games that use the camera, compass, GPS, etc. Create Augmented Reality apps in as few as six lines of code.
•  Media and Podcasts – Play audio and video. Integrate with music and videos hub.
• Physics Helper Library – Create physics-based games and apps in Silverlight by drawing elements and attaching physics behaviors directly in Expression Blend.
• RSS – Create applications that render HTML pages shared as RSS feeds.
• Schools – Build an app for your school that includes information such as News, Maps, Links, etc.
• Social – Build apps that connect to RSS, videos, Flickr, Facebook, Twitter and more.
• Translator – Build an app that does language translation, including Text to Speech.
• WordPress – Build a native app that allows users to read any WordPress blog.

 

Starter Kits (XNA)

• Card Game – Create card games. This kit demonstrates Blackjack.
• Catapult Wars – Like a simplified Scorched Earth or Worms.
• Dice Game – Create dice games, this kit demonstrates Yacht.
• Honeycomb – Move bees around using smoke. Avoid getting stung.
• Marble Maze – Move the ball using the accelerometer. Avoid the pitfalls.
• Memory – Like Simon Says.
• Ninja – Slice bamboo, throw shurikens, avoid dynamite. Similar to Fruit Nina.
• Platformer – Build a platformer game (similar to Mario, Sonic, etc.)
• RPG – Create advanced role playing games.

 

Icons

• Metro Studio – 600 free metro style icons from the cool folks at SyncFusion.
• The Noun Project – Hundreds (if not thousands) of icons for just about anything you can think of, all free. These icons will download in Scalable Vector format (SVG) and will need to be converted to PNG at the size of 48 x 48 pixels. Either InkScape or Expression Design can be used to do the conversion.
• BRKR Design Icon Pack – This pack costs $20 but it includes 350 of the most commonly used icons already sized and ready to go. This single package includes all 350 icons for Windows Phone, iPhone and Android.

 

Images

• Every Stock Photo – Search thousands of images, many of which can be used in apps and games.  Click on advanced search, then click the Licenses dropdown and check ONLY the boxes for Public Domain and Custom Free.  When you find the image you’re looking for, be sure to follow the search result back to the original site and read the license to make sure it can be used in your application.

 

Sound Effects

• Soundjay – Hundreds of sound effects that are licensed for use in apps and games. Most (if not all) of these sound effects should play as-is on Windows Phone. You can use a tool like Audacity to convert any sounds that don’t play into ones that do.
•  Freesound – Thousands of free sound effects. Carefully check the license for each sound effect because not all sound effects can be used in commercial applications. Some sound effects may also require you to give attribution (credit) to the author in your application. Not all sound effects on this site can be played on Windows Phone. You can use a tool like Audacity to convert sounds that don’t play into ones that do.

 

Music

• Incompetech – Hundreds of high quality songs available for use in apps and games. They’re even organized by genre, "feel" and keyword. Many of these songs require attribution (listing in credits) or can be purchased for royalty-free use.
• FreePD – Another great resource for finding free music in the public domain. Their FAQ states that all of the songs listed are available for use without attribution. Double-check that the page shows "CC Zero" at the bottom.

How-To’s

• Share Data Across Pages – How to share data between two or more pages in an application.

Podcasts

• The Metro Developer Show – Hands down the best podcast for Windows developers with excellent coverage on Windows Phone.

Best Intro Videos for Windows Phone – Thanks Nokia!

Nokia has released what amounts to (in my opinion) the best intro videos for Windows Phone period. They have a channel on YouTube and they created a playlist specifically for Windows Phone features. I’m including direct links for the current videos but you can check out their playlist for any recent additions

All Videos (playlist)

Apps & Games

Browsing & Search

Office & Mail

People and Messaging

Music & Entertainment (Nokia-specific features. Not the music hub, but cool.)

Drive & Maps (Nokia-specific features. Not the standard Map app but very cool.)