At the Build conference, Microsoft just released the new Windows Phone 8.1 “blue” SDK. Looking back in time, I think that it is one of the most significant changes to the Windows Phone framework since it was first released back then in 2010. First there is a wealth of new features and APIs, and there will be plenty of articles about that! Then there is a new architectural direction which will allow even more code sharing between Windows 8.1 and Windows Phone 8.1 than in the past! And soon for Xbox too.
Windows Phone 8.1 apps
When you install Visual Studio Update 2 which was just released as a release candidate (RC), you will see that there are now two ways to build Windows Phone applications. In 8.1, you can select a “Windows Phone 8.1″ application and a “Windows Phone Silverlight 8.1″ application. This post will explain some of the differences. There is also a “Universal Application” template, and we will also talk about that.
Windows Phone 8.1 apps are in fact using a phone version of Windows RT, which powers Windows 8 devices running on ARM such as the Microsoft Surface 2 (but not the Pro!). That means that coding for Windows Phone 8.1 is very similar to Windows Store applications. In fact, much of the code can now be shared between these platforms, and we will see later how the infrastructure is helping you with the addition of so-called Universal apps. Quick point of detail, the Windows Phone RT framework is called WinPRT. Again, it is very similar to the WinRT framework running on Surface 2. The WinPRT apps are packaged in an Appx file (instead of a XAP file until now), which again is just like in WinRT.
The good news is that you won’t need new devices to run WinPRT apps. After the next update to your phone is installed, you will be able to run the new applications just fine.
Thanks to the new WinPRT framework which, again, is very similar to the WinRT one, we now have a new type of apps. These new applications are named “Universal applications”. The name is a little overreaching seeing how these apps are really “just” for Windows Phone and Windows Store, but this is a really important step. This will encourage developers to apply all we learned in the past few years about sharing code between these two platforms, both with Portable Class Libraries (PCL) and shared files (linked files).
When you create a Universal application in Visual Studio, you get a Solution folder with 2 projects and a “Shared” node. One of the projects is a Windows Phone 8.1 app. The other is a Windows 8.1 app. And the Shared node is interesting: Anything you put in there will be automatically shared by both applications.
For example in the screenshot above, the App.xaml file (and its App.xaml.cs which is not currently visible in the Solution Explorer) are shared by the Windows Phone app and by the Windows app. In fact, under the cover, it is nothing but shared files (aka linked files) in Visual Studio. When you add new files to the Shared node, Visual Studio will automatically create the linked files and add that to both projects. The files will then be compiled (if they are code files), built and packaged in two Appx files.
While the Shared node can be used to add shared files, you cannot use it to add references to your WinRT and WinPRT apps. References must be added twice, once to the Windows 8.1 project and once to the Windows Phone 8.1 project. This can be a little confusing, because (get that): If you have a C# file in the Shared node, it will be able to use the assembly you added! As long as the APIs you are using are defined for both WinRT and WinPRT, you’ll be fine. In a next article, I will show you how to build a Universal app with MVVM Light, which should help to clarify things.
References you add can be of multiple kinds:
- You can use portable class libraries built for Windows Phone 8.1 and Windows 8.1 (and maybe for more frameworks). In this case you will simply add a reference to the exact same DLL in both projects. In MVVM Light, the GalaSoft.MvvmLight.dll and the GalaSoft.MvvmLight.Extras.dll are PCL assemblies, so both the Windows Phone 8.1 and the Windows 8.1 apps use the same files.
- You can also use platform specific DLLs. For example in MVVM Light, the GalaSoft.MvvmLight.Platform assembly is specific to each platform. It means that the one for Windows Phone 8.1 is not the same as the one for Windows 8.1. This is because some things cannot completely be shared yet. In MVVM Light, specifically, the DispatcherHelper had to be moved in the platform assembly because the implementation is not exactly the same everywhere. But since the methods and properties are named the same, you can still have one single ViewModel that uses the DispatcherHelper, and this ViewModel is in the Shared node. Confusing? A little bit, but hopefully with practice this becomes clearer.
Of course, the platform specific assemblies can also have methods and properties that exist only for one of the targeted platforms. For example, imagine that you want to handle the phone’s contact book but not on Windows 8.1. Nothing prevents you to add a contact book service to the Windows Phone 8.1 app, but not to the Windows 8.1 one. Of course if you refer to these non-shared APIs from your shared ViewModel, it won’t compile. In that case, you might need to add preprocessor directives to avoid compilation errors.
- Finally you can also add Windows Runtime components which can give you access to unmanaged components.
Working with files
When you add files to a universal app, you can either add them to the Shared node, or to each application separately.
In the first case, like we said before, the files will be shared as link, and when you build your project, they will be built twice. It is possible that you have to add preprocessor directives in some cases, if code differences exist but are minimal.
In the second case, the code files will be built only for the application to which it was added either Windows Phone 8.1 or Windows 8.1. This is preferable when you have larger chunks of code which are not shared. In fact, this way of doing (sharing or not, preprocessor directives or not), PCL or platform specific assemblies are exactly what we were doing before when we were sharing source code file between a Windows 8.0 and a Windows Phone 8.0 applications (and even WPF and Silverlight…). The only thing that changed here is the way that this looks in Visual Studio. Oh, and you don’t HAVE to create a universal app if you want to share code, the good old way still works just fine.
Windows Phone 8.1 with Silverlight
In addition to the Windows Phone “RT” applications, developers also have the possibility to create Windows Phone 8.1 applications with Silverlight (just like in 8.0). Think of this as an upgrade to the Windows Phone 8.0 framework. This is a little confusing, so try to follow: If you have an existing Windows Phone 8.0 application and want to take advantage of the new APIs, porting it to Windows Phone Silverlight 8.1 is the best choice. On the other hand, if you start a new application from scratch, it is probably better to start with Windows Phone 8.1 “RT” or a Universal app (if you want to share with Windows 8.1).
Note that if you create a new Windows Phone Silverlight application, you will be shown a dialog to select 8.0 or 8.1. That can be useful if you still need to create an application for Windows Phone devices which don’t have the new 8.1 update installed. If possible however, I would rather target the 8.1 framework (as soon as it is available) to enjoy all the new APIs and features.
However Windows Phone 8.1 “RT” is brand new and a little rough around the edges. There are a few things that are not completely finished and you want to inform yourself thoroughly before you decide which framework you pick. In the future we will see additional work on these two Windows Phone frameworks, and things will settle. Eventually, I think it is safe to assume that we will see a total convergence, with up to 100% code sharing between Windows Phone and Windows Store, and maybe differences in the XAML. We’re not totally there yet, but boy we are closer than ever. And that is really awesome.
So if we recapitulate:
- You can create new Windows Phone 8.1 apps which run WinPRT, very similar to Windows RT used for Windows 8.1.
- You can create Windows 8.1 apps which use WinRT.
- You can create universal apps, which are really just a Windows 8.1 and a Windows Phone 8.1 apps with shared files.
- Or you can create Windows Phone Silverlight 8.1 apps, which is similar to the phone apps we did until now, but with new APIs (like Windows Phone 8++).
Blend and Visual Studio designer support
That section will be very short because: It just works! Right click on any XAML file in either the Windows Phone 8.1 or in the Windows 8.1 project, then select Open in Blend, et voila! Full designer support for the universal apps. Alternatively you can open the XAML files in the Visual Studio designer too. YAY design.
MVVM Light support
In the next article, we will see how you can create a universal app for Windows 8.1 and Windows Phone 8.1, and add MVVM Light to these two applications. I ported MVVM Light to Windows Phone 8.1 as a Portable Class Library. In fact, this PCL also covers .NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0 and Windows Phone Silverlight 8.1. We will see how to create the app, add the assemblies with Nuget, add the viewmodel layer and connect everything. So make sure to check it out, and hopefully that should make everything I described in this article clearer!