Mobile Corner

Windows Phone 8.1: A Giant Leap Forward for Convergence

It may look like a simple point upgrade, but it isn't. Examine more closely, and you'll see why the latest iteration of Windows Phone is a big deal.

• By Nick Randolph
• 05/02/2014

Those familiar with the Microsoft mobility story are aware that convergence has been a topic long discussed both by Microsoft and its community of developers. Back in the Windows Mobile/.NET Compact Framework (.NET CF) days, it was a niche space where you had to be a mobile specialist in order to build great applications.

While there were some similarities between the .NET CF and the full .NET Framework, there were specific Windows Mobile APIs, and due to the underlying OS being based on Windows CE, there were implementation differences with which to deal. Windows Phone 7 was seen as a major step forward in platform convergence since it adopted the Silverlight programming model, but it was actually a step back for most mobile developers. Windows Phone 8 was the next major step forward in platform convergence, as it switched across to the NT Kernel and started to integrate the Windows Runtime (WinRT) APIs. What's interesting about the Windows Phone 8.1 update is that it's probably one of the most significant steps in this convergence story. Don't be confused by the minor version increment -- this is a major step forward for developers, since the programming and application lifecycle model is now unified with Windows 8.1. In this article I'll look at why this is a big deal, and some of the other features that come with Windows Phone 8.1.

Prior to Windows Phone 8.1, if you wanted to write applications using XAML and C#, you used a programming model based on Silverlight. As part of the new convergence story, you can now use Windows XAML, which is compatible with the model used for creating Windows Store apps. Recognizing the investment developers have already put into Windows Phone Silverlight applications, Microsoft ensured they could leverage some of the new platform features without having to re-write applications into Windows XAML. As such, there are now three choices for developing applications for Windows Phone 8.1:

• Build a Windows Phone 8.0 Silverlight application
• Build a Windows Phone 8.1 Silverlight application
• Build a Windows Phone Windows XAML application

There are benefits and limitations associated with each of these choices, so it's worth reading some of the documentation on the Windows Phone Dev Center.

Retarget to Windows Phone 8.1
If you have an existing Windows Phone 8.0 Silverlight application and want to start using some of the new platform features, the first thing you'll have to do is re-target your application to Windows Phone 8.1. Microsoft has provided a shortcut to this workflow within Visual Studio: right-click on your project file and select Retarget to Windows Phone 8.1, as shown in Figure 1.

Before upgrading your application to point to the new platform, and adding in missing assets and manifest files required for Windows Phone 8.1, Visual Studio will warn you that you should back up your project before proceeding. In fact, the recommendation should be to take a clone of your application and upgrade that (or if you're using a source control repository you might consider a separate branch). The upshot is that you'll want to be able to maintain a Windows Phone 8 build of your application as long as possible to ensure the widest market available to your application.

For a lot of applications re-targeting will not alter or break your app. However, before making any further changes, or starting to incorporate any new features, it's important to verify your newly re-targeted application is still operating as expected.

Universal Projects
One of the main reasons for using Windows XAML is compatibility between your Windows and Windows Phone applications. In this release, it isn't possible to build a single package that can be deployed to both environments. However, there is so much compatibility between the platforms that most code and markup files can be shared across both projects. Recognizing that the ability to share files between projects wasn't being handled well in Visual Studio, Microsoft came up with the notion of Universal projects, which contain a Shared project along with different "head" projects for each target platform.

Figure 2 illustrates a newly-created Universal application based on the Hub template. It has three sub-projects: one for each of Windows and Windows Phone (that is, the "head" or target projects), and one Shared project. From the toolbar you can select not only whether to run on the emulator or a device, but also which target you want to run (Windows or Windows Phone).

Of course, sometimes your project will start as just one target and end up having to deliver multiple targets. Luckily, this migration path can be easily achieved in Visual Studio by right-clicking on the original project and selecting Add Windows Phone 8.1 or Add Windows 8.1. Both these options will create two new projects; one for the other target and one shared project. It's then up to you to work out how much of your code and markup can be shared. Note that this isn't an option for existing Windows Phone 8.0 Silverlight applications.

Pick Your Language
Web development for Windows Phone has always been a second-class citizen, relegated to being displayed within a WebBrowser container, following the PhoneGap style pattern in order to expose device capabilities. With Windows Phone 8.1, developers have their choice of technology and language. For games, C++ and DirectX will give the best performance. For rapid development, the combination of XAML -- to declaratively lay out pages and control -- and C# (or Visual Basic) to write the application logic is the best option. For Web developers, the introduction of the WinJS programming model to Windows Phone allows you to leverage your existing skill set to build across both Windows and Windows Phone platforms.

Microsoft has taken this one step further, announcing that it's open sourcing WinJS and continuing to evolve it to work across multiple platforms. This means application developers should be able to leverage a common set of APIs for working with device features (likely taking advantage of project Cordova to provide the low-level device integration), as well as some of the rich UI elements provided by WinJS, the GridView and ListView controls, for example.

Layout
The distinction between phones and tablets has increasingly become less about size and more about usage patterns. As the Windows platform evolves and converges with the Windows Phone platform, it seems logical that what was once a discrete choice between developing for a phone or developing for a desktop/tablet is now becoming a continuum of different device shapes and sizes.

Windows Phone developers will be used to developing their applications based on a width of 480 units. Depending on which device your application runs on, this might equate to 480, or some other number of actual pixels. This allows for a very simple layout model, because you only need to account for whether the device is in portrait or landscape mode (and in reality, most applications are only designed to work in portrait). However, as devices scale beyond 6 inches, this simplicity means the layout doesn't make effective use of the additional screen real estate available on larger devices.

Windows Phone 8.1 has a shared virtual layout canvas, with a 166 logical DPI. This means devices with the same resolution but different physical size will have a different effective resolution. This sounds much scarier than it really is. A lot of layouts will still use alignment to control the size and position of elements. Where it becomes relevant is for list and, particularly, grid controls -- instead of having two columns of tiles that simply grow with device size, you'll automatically see additional columns appear as the effective resolution increases.

As the effective resolution of your application varies, you may want to adjust the arrangement of controls to leverage the additional space, or in the case of smaller devices, perhaps reduce the amount of content visible. This can all be done using visual states. First, define your visual states in Blend for Visual Studio. Then, as the screen size varies, simply change the current state using the VisualStateManager. This strategy not only works for screens with different effective resolution, but also varying device orientation and screen splitting for desktop applications.

Windows Phone 8.1 applications are able to share controls with Windows. This means there are some controls (Button and TextBlock, for example) that are common across both platforms. There are other controls where the API is the same, yet they're optimized for the different platforms. There are also platform-specific controls (such as Pivot for Windows Phone). When building controls, you, too, can share (or customize) those controls for the different platforms.

Application Lifecycle and Navigation Model
The lifecycle model for a Windows Phone 8.1 application is the same as a Windows 8.1 application. This means your logic for suspend and resume can be shared. In addition, the navigation model is the same, based on navigating to the type of a page, rather than its Uri. A side effect of this is that Windows Phone developers will have to learn how the NavigationCacheMode can determine the page lifecycle. Simple guidance such as enabling the cache mode on forward navigation, and disabling it on a back navigation, may work for simple applications, but may need to be tweaked for applications that have a different navigation flow.

Multi-Tasking
The agent and task model of Windows Phone 8.0 is replaced by the Windows model for background processing. This leverages a number of triggers an application can listen for, such as NetworkStateChange, Location and Time triggers, and push notification triggers. When a trigger is raised, the application gets to execute and react to the changing state of the background device.

Tiles and Notifications
Windows Phone 8.0 exposed three tile sizes and three tile templates, but application developers still felt the need to generate custom background tile images to get them to look perfect. With Windows Phone 8.1, the majority of the tile templates available to Windows 8.1 are now available, although some templates vary on Windows Phone to account for the different layout and style.

The notification platform has also taken a massive step forward by adopting the same infrastructure as Windows applications, the Windows Notification Service (WNS). This makes for more reliable notifications and the ability to share push notification logic, rather than having different logic for each platform. Instead of manually creating the XML necessary to send to WNS, the NotificationExtensions project on NuGet can be used, which provides a rich managed code wrapper for sending notifications.

App Data and Share Contract
Windows Phone 8.1 applications can now take advantage of roaming settings. In the case of Windows Phone and Windows Store applications that share the same store identity, this means they'll be able to use the same roaming settings, so developers can delight their users by providing a continuous experience across whichever device they're using.

Unlike Windows 8.1, with a dedicated Share charm, Windows Phone 8.1 only inherits the Share contract. Windows Phone 8.1 applications need to expose their own interface for launching Sharing, but thereafter the experience is controlled by the platform. This means any application can act as a Share source, and any application can act as a Share target. The list of default content types that can be shared is similar to those supported on Windows 8.1, whilst also supporting an extensible model allowing developers to specify their own schema.

Location and Geofencing
Finally, I'll touch on the location services available to Windows Phone 8.1 applications. This is really an evolution of the APIs added in Windows Phone 8.0, and one of the most exciting additions is the ability to create geofences. These are circular areas where your application will be invoked if the user enters, leaves or remains for a given time. This opens up a world of context-aware applications – for example as you walk past a theater, the app can notify you of what events are coming up, or any last minute walk-in tickets that are available.

This article provided a quick walk-through of some highlights coming in Windows Phone 8.1. This is by no means a complete list, and there are other areas like sensors; enterprise applications and management; media; and Bluetooth, which have all had significant investment and continue to evolve with Windows Phone 8.1. This is no minor update -- there are lots of exciting new applications just waiting to be built. I encourage you to see what's available.