Share via

Windows Phone 8.1 for Developers–Converging the App Models

  • Article

This blog post is part of a series about how Windows Phone 8.1 affects developers. This blog post details how the app models between Windows 8.1 and Windows Phone 8.1 are converging and is written by Peter Bryntesson (@petbry57)

Introduction

The biggest feature of Windows Phone 8.1 is convergence with Windows 8.1. Convergence has happened on four major areas:

  • Supported programming languages        
  • Execution model     
  • WinRT API
  • Backend services

This blog will details the improvements in all of these areas, but to sum it up quickly: “It’s just as in Windows 8.1”!

Supported Programming Languages

In Windows Phone 8, you basically had two choices when you wanted to do an app: Either use C#/VB with .NET and XAML or write a DirectX C++ app. You could also combine the two. With the new support for the Windows Runtime application model you can also write native apps in C++/XAML as well as native apps in HTML/Javascript. Further more, in all these languages, you can write universal apps which is a special type of solution to develop for both WIndows 8.1 and Windows Phone 8.1 as efficient as possible.

Execution Model

Windows Phone 7/8 application are based in the Windows Phone Silverlight execution model. This execution model was inherited from the Silverlight application framework and includes support for C#/VB, .NET and XAML. This model is extended in Windows Phone 8.1 and remains largely unchanged. However, most of the new WinRT apis are exposed here as well and Windows Phone 8.1 Silverlight will run in the new execution model detailed below. This is an excellent path to take if you already have a Windows Phone 8 app and just want to take advantage of new features. Upgrade will be seamless.

The new execution model available is the Windows Runtime execution mode, ported over from Windows 8.1. This architectural diagram from Windows 8 is now valid on the phone as well.

image

This means that everything you’ve learned from writing Windows Store apps now applies to writing phone apps as well, including the actual code. In addition to the execution model, the application model is also identical between the platforms. This means that you could share your app.xaml between the platforms if you would like to. The navigational model is also the same, with the physical (or on-screen) back button doing a Navigate.Back(). New default for Windows Runtime apps is that when you hit Back at the top of stack, the application doesn’t close but instead suspends.

The background agent execution model has also been converged with the Windows 8.1 model. So all background tasks you’ve written in Windows 8.1 will also work unchanged on Windows Phone 8.1. Background tasks are trigger based and can be triggered from (some examples)

  • Geofencing
  • System status Changes (network Changes etc.)
  • Push notifications
  • Bluetooth messages

This gives you many new and interesting ways to start your app and it will be interesting to see how this will be used by developers.

A Windows Phone 8.1 Windows Runtime app is packaged in the exact same format as a Windows 8.1 app. It uses the same appx package format and supports delta app updates the same way. It’s even so that a specific version of a specific file is only stored once on persistent storage to reduce the amount of disk used by apps. A good example of this would be the Unity runtime engine used heavily by games.

WinRT API

Almost everything in WinRT has been ported over to the phone. This includes the entire Windows Runtime XAML stack, file I/O, Live tiles api, background agents, mapping and geofencing apis etc. Those apis that hasn’t been ported over comes in two categories:

  1. Apis that doesn’t make sense on the Phone platform; i.e Printing, search contract etc.
  2. Apis that we’re dropped due to time constraints. These are few and hopefully they will be converged over time.

But it’s really amazing how much code you can share between the platforms now, and how easy it is. I will give more detail about this in an another blog post, but you can create a Universal app that targets both Windows and Windows Phone. This solution contains three parts:

  • A Windows 8.1 Project.
  • A Windows Phone 8.1 Windows Runtime Project.
  • A Shared folder. Everything you put here will be automatically included in both projects.

New here is a way to write a WinRT component that you can share between Windows and Windows Phone, so you can reuse code easily between projects.

Backend Services

Things are converging on the backend as well. A few examples are:

  • Converged push notifications platform. Windows Phone 8.1 now uses the same (WNS) platforms as does Windows. This has proven much more reliable and a lot quicker as well.
  • Converged app roaming. Windows Phone 8.1 now supports the same app roaming capabilities as Windows does, and by using the same app id for you Windows and Windows Phone app you will actually use the exact same storage and can share data between the two apps.
  • As noted, by using the same app id, the two apps essentially become the same. So if the user has bought the Windows version he can now download the Windows Phone version for free. This is optional for the developer so he can still keep them separate of he wants to.

Summary

The release of Windows Phone 8.1 really is a very major step on the path to “One Windows” on all platforms. Never before has it been so easy to developer for both Windows and Windows Phone, At the same time, never before has a mobile platform enabled so many different developers and so many programming languages to create efficient, native and beautiful mobile apps in such a productive environment.

Comments

  • Anonymous
    April 25, 2014
    I think there is a real need for Printing capabilities on phones.  Those api's should also be ported.

  • Anonymous
    May 08, 2014
    The comment has been removed

  • Anonymous
    March 09, 2015
    Does windows phone use CoreCLR? Why doesn't it show on the picture?