by Andreas Hammar and Håkan Reis and Peter von Lochow - .Net
In our previous introductory post we set the stage for what we’re going to accomplish with this conversion. Now it’s time to take the first step. Before we dive in, lets lean back and think about how to proceed. We have a working Windows Phone application and we have nothing when it comes to Windows 8. So, what’s the next step, or more correctly, what’s the first step.
In this article we’ll list the different porting strategies that we considered, say which one we chose and why. We will look at the following options.
Let’s get started.
We could start over completely. The advantage of doing so is to get rid of all the incompatible luggage that you might bring over from the Windows Phone client. Then, if you find blocks that can be copied over and used that’s fine. The drawback is of course that the code base will be split in two and you will lose a lot of the work you’ve put in. Starting over is not a bad option, but would not be so interesting in an article series on porting so let’s skip this for now.
Another way to port is to use compiler flags to separate the Windows Phone-specific code from the code that is specific for Windows 8. This would look like:
|
1 2 3 4 5 |
#if WP // windows phone code #elseif WIN8 // windows 8 code #endif |
The big advantage here is that you truly have a common code base, but that is also the Achilles’ Heel of this method. We did not feel like creating a complex code base full of if/else-statements. You even risk having an if/else in every class – in which case you might as well separate the classes completely. We opted out of this option as well.
There is one way of avoiding compiler flags and still being able to share code, at least to some extent. What we’re talking about is the Portable Class Library (PCL).
The PCL can be summarized by:
PCL is a class library built to be used from different platforms such as Windows Phone and Windows 8.
So we can build a class library with all the common code and compile it as a PCL. What we gain is an elegant way of sharing code between the platforms. The drawback is that if the Windows Phone app was not written with the PCL in mind, a lot has to be rewritten. In our case we had not prepared for the PCL so we’ll pass on this option too.
Copy/paste has a bad reputation in developer circles, often well deserved. ![]()
It encourages using code that you don’t understand and helps in breaking the DRY principle. So at first the thought of just copying all the .cs files over to a Windows 8 project did not feel good at all.
But after considering the other options this is the one that we went with. We will take the code from our Windows Phone application and step by step modify if towards a Windows 8 application. Now, before you cry wolf and judge us, let us list our reasons:
So – our final choice is to copy all code files over and use that as a starting point for the new Windows 8 application. Let’s begin!
[...] Converting to Windows 8 from Windows Phone | Conversion strategy (2 of 12) → [...]
[...] language, Metro, we will be able to reuse a lot of the C# code and XAML that we already have.”Converting to Windows 8 from Windows Phone | Conversion strategy (2 of 12) (Jayway Team Blog)“We have a working Windows Phone application and we have nothing when it [...]
Loving this article series. Looking forward for more blogs :)