Windows/Phone 8.1: Prism for the Windows Runtime (Universal)

An early drop of the Prism framework for Windows Runtime apps that supports “Universal” apps has gone onto the CodePlex site as flagged by Blaine on his blog last week.

I’ve talked about Prism for WinRT a few times (the last screencast video being only a few blog posts ago here) and I’m very keen to see the start of “Universal” support so that a developer that wants to use Prism can have a consistent framework to support them on both Windows and Phone.

I pulled down the bits from CodePlex and opened them up inside of Visual Studio – there’s 3 folders in the zip file that I pulled down;

image

and I wandered into that Converged folder and opened up the bits. In order to get them to build (as advised on the website) I also brought down the two NuGet packages;

  • Prism.Mvvm.1.1.0.nupkg
  • Prism.PubSubEvents.1.1.0.nupkg

and dropped them into a local NuGet feed folder (via the Tools->NuGet Package Manager->Package Manager Settings dialog) and then I could get things to build.

There are quite a few projects within that solution;

image

the WebServices project and the Tests projects all probably speak for themselves. There are 3 projects building up Microsoft.Practises.Prism.StoreApps – i.e. the bits specifically supporting Windows/Phone Store apps;

image

but the majority of the code builds into the Portable class library (red below) and only a single class resides in the StoreApps.Phone and StoreApps.Windows projects (blue below);

image

It’s an important class though as it provides the base class for your “App” class and that MvvmAppBase.cs file is actually linked from the Windows project into the Phone project – i.e. it’s the same source file with a little bit of conditional compilation in it where Windows/Phone have differences over;

  1. Standard support for settings (Windows has this, Phone does not)
  2. Hardware back button (Phone has this, Windows does not)

and so there’s really very little difference between the two platforms here and what looks like 3 big projects is almost 1 project with one class which needs some minor conditional compilation.

That said, this would mean that there isn’t one MvvmAppBase class in one library for your code to reference and derive its App class from. There are 2 – one for Windows and one for Phone and they build out into two separate libraries which would work well if you’re consuming that MvvmAppBase class from a piece of code that lives in a Shared project but might make life a bit more difficult if you wanted for some reason to have your App class built into a single library.

That’s all of the framework code.

The rest of the code is the “AdventureWorks Shopper” reference application with an implementation here for both Windows and Phone. In previous deliveries of Prism, the implementation was only for Windows so it’s great to see this arrive on Windows Phone.

Again, it looks like there are 2 libraries here supporting the UI logic of the app;

image

but if you look at the UILogic.Windows project above, you’ll notice that it only has one additional ViewModel within it – that’s the ViewModel for supporting Search on Windows 8.1. The rest of the code is portable across Windows/Phone 8.1 and that includes quite a lot of pieces here – across those folders Models, Repositories, Services, ViewModels above there must be 80+ classes all shared between Windows/Phone.

The AdventureWorks app sits on top of this library and it is now packaged as a Windows project, a Phone project and a Shared project;

image

If you dig into that, you’ll spot that pretty much all the code is in the Shared folder as indicated below;

image

whereas the Windows/Phone specific projects have some specific bitmaps and then, as the underlying logic project suggested, a specific handling of a search user control;

image

That results in more shared code between these 2 apps than I would have maybe expected and perhaps one reason why that’s possible here is the use of the DataTemplates.xaml file in the individual Windows/Phone projects here.

The App.xaml file which is in the Shared project is being used to merge in the platform-specific variant of DataTemplates.xaml into the app’s resources;

image

and so the Prism guys have used that as a way of having different DataTemplates with the same names across Windows/Phone to account for different sizes and styles of templated items.

Because there’s a lot of shared (design time and run time) views in the Shared project, it’s possible to edit those views at design time in both “Windows mode”;

image

and “Phone mode”;

image

with design-time data supporting those two different views (although I’m not 100% sure about the presence of the back button on that HubPage in the Phone screenshot above and I don’t think it appears at runtime so maybe there’s some tweak missing there).

Taking a quick tour around at runtime the initial screen looks to offer similar functionality on both types of device;

image

1

although there are differences at the moment in that on the Phone;

  1. I’m not sure how to search.
  2. I lose the semantic zoom (to be expected, that’s not really something you do on the Phone).
  3. I lose the navigation bar functionality that allows me to jump straight to “Home” and “Shopping Cart”.

Navigating into a particular group seems pretty equivalent;

image

2

although I wouldn’t expect the Phone to be displaying that back button Smile and product details is also similar;

image

3

and both platforms have the “Pin to Start” functionality although I think the Phone loses the FlipView that Windows is using to allow easy navigation to the next product and I’d argue (from a position of weakness as I’m no designer) that both layouts could be improved here.

The Shopping Cart view looks to be the same on both devices;

image

4

although I’d argue that the mechanism for selecting an item and then having an option to edit the quantity or remove the item feels more natural to me on Windows than on Phone where I’m not sure this metaphor is quite so common;

5

Ultimately though, this is an initial drop rather than a release so it’s great to see the Prism guys working away at Universal app support and it’s great to see them getting bits out early and the Adventure Works shopper is a great thing to have as a reference for an app developer to be able to take a look around, see how things were done in the reference implementation and apply similar techniques to their own applications.

I’m going to have a stab at updating the demo that I showed in this session to be more “Universal” and I’ll post back to the blog if I have success in getting that to work.

In the meantime, if you’re using these kinds of techniques then grab those early Prism bits and provide feedback to the team – they’re very keen to hear from you.