Converting to Windows 8 from Windows Phone | Looking back–what would we do differently (12 of 12)

We started with a Windows Phone application and converted it to a Windows 8 equivalent. The end result was far from a clone, neither visually nor in function, but that was never the goal. The goal was to take a real application through the trembling steps of converting into a fully functional prototype on Windows 8.

The idea of this last post in the series is to look back and discuss what we had done differently building the Windows Phone app, knowing what we know now.

This post is a part in a series – you can find the full index here.

Isolate 3rd party libraries

Yes, we know – there are lots of great frameworks out there. Yes, we know – the wheel should not be reinvented over and over. So, to be clear, we are not against 3rd party libraries on Windows Phone. But before adding that library reference through nuget, there are a few things to consider.

  • Does it solve a problem in a smarter way than something I would be able to create in matter of hours?
  • Do I have full control over the impact on performance?
  • Can I jump to Windows 8 and find the same component or rewrite my code easily?
  • Can I isolate the component or will it scatter across my code base?

We had a couple of 3rd party components in the Reseguiden Windows Phone application. We removed them all when converting to Windows 8. Silverlight Toolkit was easy since it was only used by the views, and they were removed in the conversion as well. We only used a fraction of Caliburn.Micro so that was easily removed and rewritten. The big hit came when all JSON parsing had to be rewritten to replace ServiceStack.Text.

So, the big lesson learned here is, if you are to use 3rd party libraries, make sure they are isolated. It will help when converting to Windows 8, and will surely help in other situations as well.

Isolate navigation

Yepp, navigation has changed. From working with Uri’s and query strings to navigate and pass data, Windows 8 instead uses types and objects.

The advantage of the new way of navigating is that you don’t have to deal with a bunch of strings. The drawback is that you have completely rewrite your navigation handling. In other words, if you have spread out the navigation code throughout your code base you have quite a task at hand. Luckily for us, we had all navigation logic in one class. Replacing that class with a Windows 8 version was done in minutes.

Isolate storage

(no pun intended Smile )

Of course there are way to store data locally both on Windows Phone and Windows 8. One difference though is that Windows 8 also has both temporary and roaming storage. Another difference is that also storage has moved from .NET to WinRT.

What we’re leaning towards here is that you win a lot by isolating your storage behind and interface, or at least keep everything in one class. The storage code has to be rewritten anyway when converting to Windows 8, so if it’s tucked away in one single place it won’t interfere with your other code.

We also mentioned the temporary storage in Windows 8 – a cache. Windows Phone does not separate temporary storage from storage. But doing this separation yourself logically in your Windows Phone app, even though it eventually is stored in the same storage, will help you when going to Windows 8.

MVVM

To be hones, we cannot say what this conversion would have been like without view models, we haven’t tried it. We haven’t tried converting an app with a lot of code and logic in the xaml.cs code behind files. We also haven’t tried converting where text formatting is done in the view instead of the view model.

We are glad we haven’t.

Will you be able to use your view models right off the bat? Well, since the views in Windows 8 probably will look a bit different that on Windows Phone the view models will not fit perfectly. But as a starting point they are really nice to have. It was quick for us to make the small modifications needed for the view models to fit our Windows 8 views.

To try to share view models completely between Windows Phone and Windows 8 will probably be counterproductive. A view model is there to serve a specific view and serve data in the exact way that view wants it in. Since the views will be different (they should be different) the view models will be different. Hence forcing the use of the same view models will make them unnecessarily complex.

Localization

The use of resource files differ between Windows Phone and Windows 8. To make the transition as smooth as possible, we recommend naming your resource keys according to the Windows 8 convention (Uid.Property, e.g. LoginButton.Content) also in your Windows Phone application. If you in addition to this bind to your resources directly in your views, all you have to do in your Windows 8 application is to copy the strings to a new resource file.

So, even if it’s not reusable as-is, also the localization can be transferred pretty smoothly.

Data bind ApplicationBar

In Windows Phone there is, as we all know, an application bar. What we also know, to everyone’s frustration, is that you cannot data bind directly to it. You have been limited to three options:

  1. Create it in XAML
  2. Create it in code
  3. Write a wrapper and data bind to that

Our advice is – write a wrapper. Why?

The application bar in Windows 8 can be data bound against. So if you’ve chosen option number 1 or 2, you all of a sudden have some code to rewrite. (yes, XAML is code too). But if you’ve gone for option 3, you can simply bind your view model to your application bar in Windows 8 instead of Windows Phone and your done.

Conclusion

Altogether this conversion took 3 days and honestly speaking, the biggest hurdle was Visual Studio 11 Beta and Resharper Beta. The conversion itself actually was pretty frictionless. Worth mentioning is;

  • We did not do a full conversion – we only chose a subset of the functionality and got that to work
  • The application we started with is small – only six views in total

If we instead had chosen to convert one of the larger apps we’re working on (40+ views) this article series would probably have been a tad bit longer…

The goal has from the beginning been to take a real world application and see what kind of problems we run into. We have run into problems, but nothing that we haven’t been able to solve. We would like to end this series with some thoughts on the future.’

One might speculate… that there is a new version of Windows Phone in the future

One might speculate… that it will build on the same kernel as Windows 8

One might also ponder whether the right way to go is to separate the code bases today and migrate back from Windows 8 to Windows Phone 8 in the future. We think so.

This Post Has 9 Comments

  1. You mentioned Caliburn.Micro. Is this what you used for your MVVM framework, or did you roll your own?

  2. @Lancelot Rolled our own MVVM. We only used Caliburn.Micro for INPC (INotifyProp…) handling and BindableCollection.

  3. Ah. I use CM pretty heavily in my phone apps. I’m gearing up for a new one which will also be a metro app and I was wondering how difficult it would be converting CM’s viewmodels (that implement Screen). It seems to me like it would be quite a chore.

    I’ve tried using MVVMLight in the past, but it was too simplistic for my needs.

    I reaalllyy don’t want to roll my own framework but it’s starting to look like I may need to go that route.

    Anyway, thanks for the feedback and article series.

  4. How did you workaround absence of Implicit DataTemplates and custom markup extensions?

    1. As neither implicit data templates nor custom markup extensions are part of the Windows Phone platform, there were no need for these features for the conversion.

      Implicit data templates isn’t a big problem. Template selectors are still applicable, although not as elegant as implicit data templates.

      When it comes to custom markup extension< there are no easy answers, sometimes it's possible to use type converters but more often you have to rethink how your view models work. Hopefully the functionality will reach WinRT XAML but for now rework for this has to be done if you are trying to port a SL5 or WPF project. And I would suggest reworking most of the views anyway as the design and interaction in Metro design is quite different from what you normally do in WPF and Silverlight.

  5. You said the conversion took 3 days. Was that 3 calender days for the 3 of you or 3 man-days of work?

    1. The basic conversion took 3 man days. But that was to get the communication working and displaying the information.

      However, the 3 man day did not include getting the UX in place for the Win8 Metro application. We spent i little bit more on that part I would say that the complete UX work took at least 2 man weeks. (wireframes, graphics and UX dev)

Leave a Reply

Close Menu