Physics Games: Multi-targeting Windows 8 + Windows Phone 7

Physics Games: Multi-targeting Windows 8 + Windows Phone 7:

DISCLAIMER: THIS BLOG POST DISCUSSES DEVELOPMENT UNDER A PRE-BETA VERSION OF WINDOWS 8! THINGS CAN AND WILL CHANGE IN THE FUTURE.

With the release of Windows 8 Developer Preview, one seemingly simple goal I had was to port my 2D physics apps that run on Windows Phone 7 and Silverlight to Windows 8. Since many of my games use vector graphics, they could scale up or down cleanly depending on the device they were deployed to.

Today I am a bit closer to my goal with an updated version of the Physics Helper XAML project - which now supports both Windows 8 Metro and Windows Phone 7 development, using a single set of XAML design files and logic.

[HOME] [DOWNLOAD] [DOCUMENTATION]

Multi-targeting WP7 + Windows 8 Metro

You would think this would be a simple thing to do, right? I mean these platforms are both properties of a single company, and you use Visual Studio to create apps for both of them. And when WP7 was released, it was a cinch to port Silverlight Web applications to the phone - in some cases you didn't even need to recompile your assemblies!

Well, with Windows 8 Metro, it's unfortunately not so simple. Microsoft is a huge company and it is apparently impossible for all divisions to agree on a single development framework that allows creation of client solutions across all of their properties. So we have fragmentation and breaking changes with Windows 8 Metro. Lots of them.

But with a little work, it is certainly possible to support both Windows 8 and Windows Phone 7 apps with a single set of design files and code. Here is a list of some of the issues I ran into while trying to multi-target these two platforms with a single code base:

• xmlns changes
  To reference an external library in XAML, we need to use the xmlns attribute. WP7 and Win8/Metro handle this differently right now (hopefully this is remedied in the future!)
  
  WP7 and Silverlight look like this:
  xmlns:xx="clr-namespace:xx"
  
  While Win8/Metro looks like this:
  xmlns:xx="using:xx"
  
  This was a problem in my apps because I wanted to maintain one set of resources for both platforms. My solution was to create a utility named CleanUsingXmlns which can be added to the prebuild step of your projects to change. Note that CleanUsingXmlns was thrown together very quickly and is not the most elegant solution, but it gets the job done.
  
  To use CleanUsingXmlns, go to the Build Events tab and add a call to the utility in the format:

CleanUsingXmlns [addusing|removeusing] [folder] [namespace1,namespace2]

... where [addusing] will add in the using clause for Metro, and [removeusing] will add in the clr-namespace syntax for WP7 and Silverlight. [folder] is the directory containing XAML files you wish to add and [namespaceX] is a list of namespaces you wish to be involved in the replacement.

As an example, the Metro demo projects contain the following in their prebuild steps to add the "using" clause into XAML files:

$(ProjectDir)..\..\CleanUsingXmlns\bin\Debug\CleanUsingXmlns addusing $(ProjectDir) Demo.Advanced,Spritehand

• Namespace Changes
  Somtimes you wonder if the architects over at Microsoft are just trying to push your buttons, you know what I mean? Take for example the shuffling of all of the Silverlight namespaces we know and love. This forces us to write code like the following when we try to multi-target:

#if METRO
using System.Threading.Tasks;
using Windows.Foundation;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Input;
using Windows.UI.Xaml.Media;
using Windows.UI.Xaml.Media.Animation;
using Windows.UI.Xaml.Shapes;
#else
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Media.Imaging;
#endif

... but with Win8/Metro, this is just the beginning. There are lots of little breaking changes all over the place which mostly seem to be there to bang your head on the keyboard and force you to litter compiler directives all over your code.

Which brings me to my final note:

• HINT: Target Lowest Profile!
  If you find yourself like me, trying to create a project that targets both Win8/Metro and Windows Phone/Silverlight, one important strategy is to target the lowest common profile. In this case, that lowest profile is Metro. By doing this, you have a much lower chance of introducing unsupported API's into your code.
  
  This table, from the BUILD conference, gives a good overview of the size of three .NET profiles:
  
  

Conclusion

While it isn't as easy as you might expect, it is certainly possible to create apps with a single set of design and code files that multi-target WP7 and Win8/Metro. Remember that this is a pre-beta release of Windows 8, and perhaps this story will improve in the beta.

If you're interested in creating your own 2D physics apps for WP7 and Win8/Metro, check out the Physics Helper XAML project on codeplex.

by andy@andybeaulieu.com