Windows

Porting a WP7 app to Windows 8

Justin James shows how working with native Windows 8 apps is similar to writing Windows Phone 7 apps. Find out why the UI is one of the biggest pain points of the process.

It has been just over a year since Windows Phone 7 (WP7) was released. While the WP7 application ecosystem has been expanding quickly (in comparison to its market share), some developers have concerns about the future of the platform, particularly with regards to the upcoming Windows 8. The good news for WP7 developers is that working with native Windows 8 applications (i.e., those built with the Metro UI and the WinRT API) is extremely similar to writing WP7 applications. I'll walk you through the process.

In a nutshell, the WinRT API has the majority of the calls that are available in the WP7 Silverlight APIs; there are some differences, though not many. For example, the graphics items, especially XNA, are not available. Push notifications are specific to WP7 and will not work in Windows 8, and there are some differences in Live Tiles. Read the Microsoft documentation to get a better idea of the differences.

The first thing to do is to get a copy of the Windows 8 Developer Preview up and running, and a copy of the Visual Studio 11 (VS11) Developer Preview (an Express version comes with the Windows 8 Developer Preview) installed. For my work here, I am using a full version of VS11 installed directly within Windows 8; I don't believe it's a great idea to mix and match preview copies of Visual Studio with my main production work machines, but that's just personal preference. I pushed a copy of an existing application to the Windows 8 machine.

The first hitch I found was that VS11 did not like the solution from my WP7 project. Trying to create a new solution in VS11 showed that there was no WP7 solution types installed. No worries, I just went ahead and created a new solution. I tried to add the existing project to the solution, but no dice. What did work was doing an "add existing items" to the project, and then picking all of the class files, graphics, XAML, and codebehind files from the project I wanted to convert. I had to close the default MainPage.xaml that was open so it would overwrite. I suppose that if I my previous project had direct changes to App.xaml or App.xaml.cs I would need to cautiously merge them. Then I did a find/replace to change the references to my old project's namespace to the new project's namespace.

I tried to do a Rebuild, but it failed (as expected) due to all of the places that I was using references to the WP7 APIs instead of the Windows 8 APIs. Not a problem. Using the migration documentation and the compilation errors, I replaced the bad references with the right ones in the codebehind files. In the XAML files, a bit more work was needed. I replaced the <phone> tag with <UserControl> (and updated the inheritance on the codebehind file). I also discovered that the references to namespaces in the XAML are a bit different.

The next pain point was in the UI. The biggie was that the Pivot control does not exist in Windows 8. In fact, the entire UI paradigm is different enough that it may be easier to make a new page entirely, and then try to cram the controls from the old page into the new one, or just start from scratch entirely on the UI side. Ugh. This is when you really value the separation of UI from code.

Another oddity is the lack of the InputScope attribute on the TextBox control. This is a valuable item, especially on the tablets that Windows 8 hopes to capture.

Outside of these changes, the biggest kick in the pants was regarding IsolatedStorage. I had to switch to Windows.Storage.ApplicationData.LocalSettings, which is backed by the registry. Instead of the simplified settings system, now you need to create ApplicationDataContainers and instead of directly accessing them by name, you need to burrow into the tree of containers and pull the "Values" property and index your settings within that. Yes, it's more capable, but it's a big pain the neck compared to the simple settings in WP7.

Overall, the conversion is not quite as rosy as the MSDN documentation suggests, essentially because the documentation omits any of the issues around the UI. Once you get past the UI end of things, the conversion is not bad -- it's mostly tedium, to the point where compiler directives and XSLT can handle much of it. The changes to the UI controls are not fun. That said, Windows 8's form factors are different enough from WP7's that you would want to change the UI anyway, and if you are using the MVVM pattern (like you probably are for any application of even moderate complexity), the issues are much less painful.

J.Ja

About

Justin James is the Lead Architect for Conigent.

2 comments
techrepublic
techrepublic

Something tells me that WinForms will be around for a while yet. Long live WinForms.

authorwjf
authorwjf

I appreciate this post. One can read the MSDN conversion docs all day but hearing from someone with first hand experience gives me as a developer a real feel for what is involved. I find myself cautiously optimistic about WP7 and W8. I look forward to more write ups of this nature as you continue to explore both platforms.

Editor's Picks