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.
- Starting over
- Shared code and compiler flags
- Portable Class Library
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.
Shared code and compiler flags
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:
// windows phone code
// windows 8 code
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.
Portable Class Library
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:
- No need to change the stable Windows Phone code
- We don’t know what we have to refactor to a PCL before we know what is needed in Windows 8
- It’s not a lot harder to refactor both solutions to a PCL later on when we have two stable code bases to build upon
- It’s likely that Windows Phone 7 soon will become Windows Phone 8 and have a lot more in common with Windows 8. We could then port our Windows 8 app back to Windows Phone 8 and extract parts into a PCL.
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!