Windows/Phone 8.1–Building for Both, Part 1

Note: the official view of //Build comes, of course, from the keynote session at //Build and the individual speaker sessions so if you find that anything that I write here seems out of sync with what you see at //Build then, of course, you should apply a pinch of salt to what I’ve written – I can be wrong and it’s early days yet.

You should also check out these 2 blog posts:

Cortana (yes!) and Many, Many Other Great Features coming in Windows Phone 8.1

Extending platform commonality through universal Windows apps

I’ve written quite a few times on this blog about the idea of trying to build code that’s sharable in as much as is possible across the two app platforms that Windows and Windows Phone present (along with some other platforms as well);

and so I thought it’d make sense to try and write up some early impressions of what has been newly announced at the //Build conference today around the convergence of Windows/Phone 8.1.

The important things I think to get out of the way in the first instance around Windows Phone 8.1 are;

It’s an update to existing Windows Phone 8 users and will come pre-installed on new phones.
It runs existing apps/games that are running on 8.0 today.
There’s lots of new end-user functionality that I’m not going to attempt to go into here – see the post referenced above.
A developer can continue to work on their 8.0 app/game and re-publish new versions to the Store in the confidence that the app will continue to work on all 8.0 and 8.1 devices.
A developer can choose to build an 8.1 app/game (possibly by upgrading their existing code) and take advantage of the new UI layers, runtimes and APIs that 8.1 brings to them.

Before delving into any more details though, I’d like to take a little bit of time to talk about where we are today which perhaps sets the scene for what Windows Phone 8.1 brings to a developer that wants to “Build for Both” Windows and Phone.

Note – in the discussion below I largely focus on “app” platforms rather than “games” platforms but that’s mostly because the games platforms are already somewhat more unified and also to try and keep what’s already going to be a long article down to a smaller size.

Also, I focus on .NET technologies in the discussion below. There’s another discussion that could be had around HTML/JS technologies.

Where Are We Coming From?

Looking at the Windows/Phone app platforms today, I drew the picture below;

Those numbers come from the “Microsoft by the Numbers” site and I think they’d be something of a surprise to someone who was completely fresh to the state of play on Windows/Phone.

Given that these 2 platforms are “Windows” and “Windows Phone”, it might be reasonable to expect that there would be pretty much an equal number of apps on the Windows Phone as there are on Windows. But, there’s a 100,000 gap between the two Stores. Some reasons why that might be the case;

The Windows Store hasn’t been around as long as the Windows Phone Store.
Developers typically think of “phone” devices when they think of developing for “mobile” rather than thinking of “tablet/laptop/all-in-one” platforms. I take that from the “State of the Developer Nation” report which says that only 12% of developers think of non-phone devices (e.g. tablets) when they first develop an app.

That said, how come developers don’t just build for the Windows Phone and then simply produce a Windows Store variant? I think that comes down to a couple of reasons;

There’s two reasons there – one is that phone apps and other apps are used differently and the other is that there are differences in the development platforms between Windows/Phone which means that a developer has to do work in order to get an app onto both.

For me, I think one of those differences is going to stick around. The other I’m hoping is on its way out…

Phones are “different”

The picture below has a few reasons that I cooked up around how I see phones as different from other devices;

Personally, my phone is used very differently from my tablet. My phone is pretty much always with me. It’s always turned on. I don’t like having to charge it but I’ll accept it maybe once a day or a little more if I’ve been using it intensively.

My tablet’s very different. It rarely leaves my house. I turn it on and off a lot. I care about the battery but I can accept when I have to charge it.

Again, my laptop’s different too. I mostly plug it in. I never, ever take it out and hold it in my hand in the street. I connect it to a wide variety of hardware (e.g. mice, printers, scanners) that I would never expect to be able to plug into my phone (which is interesting because the same underlying Windows code OS could make that possible).

It’s interesting to take a look at a couple of apps and see how they navigate this difference across Windows/Phone…

Twitter – Homogeneity Across Form Factor

This is the official Twitter app screenshotted on Windows Phone 8.0 and Windows 8.1;

I’d argue that the user experience here is largely the same across the Phone and the tablet/laptop/all-in-one devices. There’s some slight difference perhaps in the way that the command options are placed and maybe in the way that you can compose a tweet but, for me, this official Twitter app seems to have taken the approach of ironing out the differences across the form factors.

OneNote – Heterogeneity Across Form Factor

The screenshot below is of OneNote running across my phone and my laptop;

The way that I use OneNote on my phone is completely different from the way that I use it on a tablet or a laptop and the user experience is (to me) quite different. On the Phone I rarely take notes beyond a couple of short bullet points but I do like to be able to open up notes and refer to them. However, I’d never expect to grab a piece of text and start dragging it around the screen and doing fancy reformatting on it.

On my laptop, that’s exactly what I expect to do – I need the full productivity that having a mouse, keyboard, touch and pen can give me and I want to make use of all the real-estate of the landscape screen to get stuff done.

I don’t think there’s a “right answer” here – I suspect that a lot of apps will present different UX on a Phone than they do on a tablet/laptop and, in some cases, apps may only be suitable for one form factor and not another although, clearly, we get into something of a grey area when we think about phones that are pretty much tablet-sized at 6” and tablets that are pretty much phone-sized at 8”.

However, there’s that second difference between Windows/Phone…

The Platforms are Different

Anyone’s who been working with Windows/Phone for a little while will know only too well that in the current Windows 8.1/Windows Phone 8.0 incarnations there are quite big platform differences between the two.

Thinking about the app platform, I can sketch out what Windows Phone 8.0 presents to a developer as;

There’s a UI layer here that I’ve called “Silverlight XAML” because it’s Silverlight that does the rendering on Windows Phone 8.0. That UI might be created in XAML or it might be created in code but it’s using the controls etc. that the layer provides.

An app then has some code that somehow links in to that UI layer and makes calls down into the platform APIs below. The primary API for a Windows Phone 8.0 app today is what I’ve called “Silverlight .NET” which is a subset/superset of .NET framework specifically for building Phone apps. It’s also possible to call into a small set of the WinRT APIs from Windows 8.1 and a small subset of Win32 APIs via platform invocation.

When you look at the platform for Windows 8.1, it’s quite different;

Firstly, there are more choices here – a developer can write a native app using HTML/CSS as the UI layer or XAML. They can then (to some extent) mix and match whether they back that UI layer with code written in JavaScript/C++/.NET and there are supporting libraries (such as WinJS and “.NET for Windows Store”) to go along with that work.

Underlying that code, the platform API set is really WinRT. It’s WinRT that pretty much provides everything the developer uses from accessing the file system to the camera or the network. There are also a small number of Win32 APIs available to the developer but most developers don’t need to make use of them.

In terms of what’s common between Windows 8.1/Phone 8.0, the diagram below highlights what a .NET developer has got to play with;

A .NET developer can build a portable class library which can be used on both Windows 8.1/Phone 8.0 but that developer is somewhat limited in that the code which can be built into that library can only make reference to the subset of APIs that is truly common across both platforms and this is a small subset.

What that means is that, for example, a portable class library like that can’t contain code which makes API calls to access the camera or to update the application’s tile. That makes portable code only useful in the context of being provided with quite a lot of abstraction.

Developers working with a pattern such as “Model View ViewModel” (MVVM) are relatively well placed to code their way around this by building different Views (UI) for Windows/Phone and ensuring that those views are not tightly coupled to the classes that support them (ViewModels) by generally only linking those two entities together by declarative data-binding statements.

ViewModels are generally in the business of “presenting Models” and it’s possible with this sort of approach to build a portable class library that contains ViewModels, Models and any other portable algorithms and so on that don’t need to differ across Windows/Phone.

Where a ViewModel needs to call out to a service which is platform specific (e.g. a service which persists objects into the file system) it’s common to abstract that service behind a platform-neutral interface which can be modelled using the types in a portable class library;

With a little bit of additional bootstrapping code, it’s possible to use techniques such as inversion of control and dependency injection to inject platform-specific service implementations at runtime. In the diagram above, these are the services represented at the bottom left and right of the diagram respectively.

An Example – Mike’s “Classic” flickR Search Example

I’ve published many a blog post where I’ve used a Windows 8.1/Phone 8.0 example of searching for Photos on flickR. The project structure that I have for that example in its current form looks something like this inside of Visual Studio;

There is a Windows 8.1 app, a Windows Phone 8.0 app and a CrossPlatform portable class library which is referenced by both apps. As per the previous discussion, most of the code in this simple solution is in the cross-platform library and is partitioned into Model, ViewModel and Service;

The application relies on 1 Model class and 4 ViewModel classes all of which are written to be portable. In turn, those ViewModels rely on 3 services;

A service to access the online flickR service (IFlickrService)
A service to download a photo and save it in the photos library on the device (IPhotoSavingService)
A service to navigate from one View/ViewModel to another (INavigationService).

Of those 3 services, the flickR service can be written portably as it simply uses a portable class (HttpClient) to reach across the network, talk to flickR and deserialize JSON data (using the portable JSON.NET library).

The other two services are defined portably by their interface but need a specific implementation for each platform and so the Windows/Phone projects provide implementations;

Each project also defines its own startup code in the form of the App.xaml file and the App.xaml.cs and each project provides its own Views using the variant of XAML for Windows 8.1/Phone 8.0 respectively;

If we dig into one of those views such as the PhotoDetailsPage.xaml view, it is made up entirely of declarative XAML with data-bindings. For example;

In the screenshot above, there is a button whose implementation is bound to a “SaveCommand” property on a ViewModel. The ViewModel itself is portable code and has dependencies on the three services previously discussed as this constructor suggests;

and a “locator” class (referenced by the DataContext binding in the previous XAML snippet) is responsible for creating an instance of this ViewModel when required to by the View and resolving all 3 dependent services for the ViewModel using an IoC container.

With that in place, it is simple enough to bootstrap the IoC container with platform specific code such that it provides one set of services on Windows 8.1 and another set of services on Windows Phone 8.0 and then resolves types correctly to use the particular set of services for that platform.

Summary

This post got long very quickly but I wanted to set down some thoughts around what I think doesn’t change with the arrival of Windows Phone 8.1, that is;

“Phones are Different”

and what I think has been a barrier to building apps that are portable across Windows/Phone today;

“The Platforms are Different”

so that it’s then possible to talk about what I think Windows Phone 8.1 changes which is that second point. I think that we are going to continue to have to think about Phones and other devices differently to a certain extent but I think that the Windows/Phone 8.1 platform changes announced today largely take away that second barrier of the platforms having differences.

What’s Next?

What does Windows Phone 8.1 bring? I’ll get to that in the next post.

Mike Taulty

I do some developer stuff on Microsoft technologies in the UK

Windows/Phone 8.1–Building for Both, Part 1