I was at the NDC London conference last week talking a little to a few developers about the idea of building for both Windows Phone 8 and Windows 8 using .NET and XAML.

It’s nothing too radical by any means and I’ve recorded a variant of this talk before,  it’s on my blog so if people came along they can grab those bits or watch another variant of that talk.

The main theme of the talk is that while the Windows 8 and Windows Phone 8 platforms are converging, there are still differences today that a developer would need to navigate in order to try and build one code base across both platforms. I have this idea of a developer trying to write code that becomes “the filling in a sandwich”;

where that “sandwich” looks something like this;

with the idea being that on each platform – i.e. Windows 8 or Windows Phone you have;

• A different version of the UX layer – i.e. the XAML renderer, the XAML language itself and the controls that you make use of whether that be by declaring them in XAML or by creating and manipulating them from code.
• The same programming language – i.e. C# 5.
• A different set of platform APIs in terms of;
  • a different subset of .NET
  • a set of “platform” APIs – on Windows 8 you have WinRT whereas on the phone you have just some subset of Win RT, sometimes called “WinPRT” with “P” meaning “Phone”.
  • a different subset of Windows APIs that are available to an app.

and so a developer who’s trying to write one set of code across both Windows 8 and Windows Phone 8 has to try and code around this by having a different UI layer on each platform and then trying to make as much of their own code as portable as possible by;

1. Minimising its dependency on the ‘XAML’ layer – this is often done by ensuring that the ‘XAML’ layer purely data-binds to the code layer meaning that the code layer has little/no knowledge of that ‘XAML’ layer.
2. Abstracting any dependency on the underlying platform APIs that are not common across the two platforms. For example – if the portable code needs to access the camera then it might do so by defining a portable interface (e.g. ICameraCapture) which abstracts the platform-specific nature of interacting with the camera and then implementing that interface for the two platforms and using some mechanism (e.g. relying on an IoC container) to inject the platform specific implementation at runtime into code which needs it.

Or, diagrammatically;

where I’d assume that each platform specific app has some way of providing the right implementation of the imaginary ICameraCapture to the code which relies on it in the portable class library in the middle of the diagram.

In many ways, that “porting sandwich” picture above reminds me of work that I was doing around 20 years ago where I had a job working on a product built in C that shipped on a number of operating systems which aren’t so common these days like various Unix operating systems ( Ultrix, AIX, HP-UX, OSF/1, Digital Unix, Solaris ), a couple of VMS variants and then also Windows NT.

That work involved writing portable C code with some conditional compilation in order to ensure (e.g.) that even simple data types like integers, longs, strings could be treated in a portable way across operating systems.

Beyond that easier stuff there was then;

• A need to abstract the UX layer – i.e. at the time this was abstracting the difference between Windows UI, X-Windows UI and DecWindows UI.
• A need to abstract the underlying interactions with the OS – e.g. the difference between opening a file on a Unix system versus opening a file on VMS/Windows. Some of that work might have been done by trying to use POSIX compliant APIs but, beyond that, there might have been a need to implement functionality a number of times for different operating systems and then abstracting any differences between them.

What’s surprising (or perhaps comforting) is how little that situation has changed and how the right hand side of the “sandwich” diagram applies equally as well to code I was writing 20 years ago as it does to writing portable code across Windows 8.1 and Windows Phone 8 today.

With Windows 8.1 and Windows Phone 8 perhaps the toughest area to navigate is around Windows 8.1 apps having WinRT as their primary API surface and Windows Phone 8.0 apps having .NET as their primary API surface – hopefully over time the platforms will converge more to mean that this is easier to navigate but, for now, there’s work to be done in being portable across those two platforms and it follows that same scheme that I was involved in 20 years ago.

“Same as it ever was”