Windows 8 represents a significant market opportunity for those of us who already have published apps in the Windows Phone marketplace. How easy is it to port a Silverlight-based Windows Phone app to a Metro-style Windows 8 app using XAML and C#? We will be looking for the answer to this question in a multi-part blog as I attempt to port Saveman as a case study.
Saveman is a word game that started out as a Silverlight web app that I later ported to Windows Phone. The port itself was easy and within hours I was able to get it running in the device emulator with minimal reduction of functionality. However, making the app actually usable on a small screen and getting it certified for the marketplace required much more effort. I suspect porting it from Windows Phone app to Windows 8 will be a similar experience, but this time a little more difficult. There are several reasons for this, and we will get to them very soon.
But first, why am I porting Saveman in the first place? I ported Saveman from the Web to Windows Phone because 1) I wanted to learn Windows Phone app development and 2) the Windows Phone browser didn’t support Silverlight so the web version didn’t work here. I’m porting Saveman from Windows Phone to Windows 8 because 1) I want to learn Metro-app development, 2) Even though Windows 8 supports Silverlight in the desktop browser, it doesn’t support it in the immersive browser and 3) Putting my app in the Windows 8 Marketplace is great for me to reach possibly millions of users.
Most of the time, the simplest route for porting Silverlight apps is to use Jupiter. Jupiter is code name for XAML for immersive applications, which are built on top of the Windows Run-Time (WinRT). The good news is that commonalities between Jupiter and Silverlight are more than you’d think. You still can use C#. You still can do MVVM. The best part is that, for the most part, XAML compatibility has been preserved. Simple user controls and resource dictionaries can be ported as-is or with minimal changes.
So why then do I think porting won’t be as simple this time around? It’s because porting is way more work than just making existing code build and run on the new platform. In many cases, a new platform brings with it additional capabilities and requirements that can force you to rethink your UI design and your code logic.
When porting an app to Windows 8, there are several things to plan for:
1. Multiple Screen Sizes
Unlike Windows Phone, Windows 8 will run on many different screen resolutions. This gives you a lot more screen real-estate, but also requires you to design the UI to adjust well to different aspect ratios.
In addition to having the usual portrait and landscape full-screen modes, Windows 8 gives the user the ability to switch the app into a special view mode called ‘snapped’. A snapped app can be either to the left or right of a landscape screen. The rest of the screen can be taken up by another app, this time in a special mode called ‘filled’. All immersive apps must support both ‘filled’ and ‘docked’. For most apps, I suspect that you will want to override the default behavior Windows provides for these modes. This means new UI needs to be designed and coded for these modes.
3. State Preservation (Process Lifetime Management)
In Windows 8, immersive apps that are not in the foreground (and don’t meet the criteria for background apps) are first suspended and later terminated. The app has the responsibility to react to certain events to preserve and restore its state so that to the user it appears that the app never went away. On Windows Phone the act of suspending an app is called ‘tomb-stoning’. We will see how similar Windows 8 is to Windows Phone in a future post.
4. Pages and Navigation handling
There are some changes in Windows 8 on how a user or an app navigates between pages. Back-key handling and navigation methods are different.
5. Unavailability of certain .NET classes and APIs in WinRT
Most .NET functionality you may have been using in your Silverlight app is available through WinRT assemblies. Type names are usually the same as before, and modifying your using statements to point to the correct assembly is often sufficient. However, some classes are no longer there, and some methods and properties are absent.
6. Asynchronous Programming
Microsoft wants immersive apps to be as responsive as possible. The common practice to achieve this is to prevent the UI thread from blocking by moving I/O or CPU intensive logic to other threads. This requires the use of asynchronous programming methods. C# makes it easy to consume asynchronous WinRT methods through the use of the await and async keywords, and through the use of generic Tasks.
7. Marketplace Certification Requirements
The amount of extra effort needed to pass the marketplace certification requirements could be daunting, especially when one is new to the process. Given how larger the Windows ecosystem is, it’s reasonable to assume that the scope of its marketplace certification requirements will overshadow that of the Windows Phone.
8. Intellectual Property Protection
Reverse engineering has been around for a long time, but it’s more of a risk now than ever for .Net and WinRT apps. An administrator user can possibly poke into application folders and then use publicly available tools to quickly reverse engineer your code. This great article by Justin Angel demonstrates some examples. A developer needs to take the necessary precautions to reduce the likelihood of being a reverse-engineering target.
Hopefully, this has been useful for those of you considering porting your Windows Phone apps to Windows 8. If you want to know more, this MSDN article is a great place to start.
In my next post, I will enumerate the issues I came across and had to fix while porting Saveman. Stay tuned!