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.
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.
(no pun intended )
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.
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.
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:
- Create it in XAML
- Create it in code
- 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.
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.