What’s New in Windows Phone 8.1- Platform Convergence (Part 1 out of 5)

April 2, 2014

Spring time again and it means new (RC) SDK from Microsoft is out to the wild. This time it is long awaited Windows Phone 8.1 SDK RC. In this series of posts I will highlight important features in new SDK and discuss recent changes every Windows Phone developer should know.

This post is about the “keyword” of this SDK release: Platform Convergence

 

What does it mean to developer?

First of all – new SDK usually means improvements, new features, bug fixes. This SDK is not exception. It brings many new features by merging Windows platforms into one and gives developer more power by enabling (finally) to target Windows and Windows Phone devices in one code base without having too much code differences if any. With great power comes great responsibility and it will be discussed later in the post.
Next, it brings “surprise” by introducing new version of Windows Phone Silverlight!

 

Silverlight 8.1 apps for Windows Phone 8.1

Just a second! Didn’t we said “Platform Convergence”? What Silverlight (“SL”) is doing there? Well – it turns out that Windows Phone 8.1 (“WP8.1”) supports two different runtimes (actually three, but I will not discuss JavaScript apps for Windows Phone 8.1 in my blog posts)! First is Silverlight (the new SL8.1 version). Second is WinRT compatible by 90% with Win8.1 Store apps and very small set or phone-specific APIs.
The developer can choose the framework to use when starting new WP8.1 app. Framework selection will determine then the set of available APIs, XAML version, accessible features and app behavior. Let’s see what is in WP8.1 SL so the developer want to consider it as a framework.

First of all, WP8.1 SL apps supports all features that are available for WP8 apps with some breaking changes. In addition SL8.1 adds some new features such as:
* Social extensibility for photos – this allows the app to register as a photos provider for contacts in the People hub.
* Seamless VoIP call upgrade – this allows  the VoIP apps seamlessly upgrade calls from cellular to VoIP when it is supported by both the caller and the callee.
* Selected set of WinRT features – this means that developer can use either set of APIs. The partial list of WinRT features accessible from SL8.1 are:

Accessibility (UI Automation, large text, high contrast)
Roaming app data
File access (incl. input and output streams and Windows.Storage.KnownFolders)
Storage and Data enhancements
Share contract
Push Notifications with WNS
Tiles, badges and notifications using WinRT APIs and tempaltes
Email and attachments
Networking (Http, AtomPub, Syndication)
Geolocation and Geofencing
Media transcoding
Windows Imaging Component (WIC)
Direct2D and DirectWrite
many more…

Note, that SL8.1 can choose the platform for push notifications (through app manifest editor) and use either WP8’s MPN or Windows Store WNS push notifications. 
Next, there is a small set of features that are not available in WinRT but still available through SL. If app relays on some of those features – the choice is obvious.
So here is the list of features supported only in SL apps:
* Clipboard APIs
* Lock screen backgrounds
* Ringtone provider
* Alarms and reminders
* Lens
* Bitmaps generation (for example for the Live Tiles) in a Background Task using managed code

Lastly, the amount of breaking changes between WP8 SL and WP8.1 WinRT. The WP8.1 SL is just good old version of SL with set of new features and some breaking changes that help to support new WP8.1 better. From this point of view it is much easier (and faster) to address breaking changes in WP8 app than to convert whole app including XAML (in most cases) to the new WinRT model. Here are few breaking changes that might affect the framework selection:
Silverlight/XNA interop is blocked – while it was not officially supported by WP8, it was not blocked so some apps used some XNA functionality. New SL8.1 cannot use XNA at all
Static fields initialization – updates to the CLR now require that static fields that are initialized in the variable declaration must explicitly provide a static constructor, which will cause the system to initialize the static fields. The following example shows how to properly initialize the static variable:

public class TheClass 

{ 

    //...

    public static TheStaticField myStaticField = new TheStaticField();

    //...

 

    //This static .ctor is required to initialize the myStaticField properly

    static TheClass() {} 

    //...

}

 

For the complete list of the breaking changes refer to the official documentation.

 

Windows Store apps for Windows Phone 8.1

WP8.1 converges with the Windows Store apps platform into a single developer platform that runs the same types of apps. The WP8.1 shares very large APIs set with Windows Store apps. In addition now the platforms share a similar app model and life cycle, a shared toolset and a common XAML UI framework. Naturally there are still some small differences in behavior and supported features between WP8.1 and Windows Store apps. Some of these are the result of timing of the different product cycles, and they may not appear in future releases. Some differences are the result of the different natures of phones and tablets, their sizes, and the way people use them. 

Let’s see the main areas of convergence:
* App model and app lifecycle – A Wp8.1 app goes through the same app execution states as a Windows Store app and uses the same events to handle launch, activation, and suspension. While this means that app can reuse most of code for saving and restoring state on both form factors, it also means that app behaves considerably different from SL8.1 app that has different lifecycle. In addition to events difference, the WP8.1 exposes different default behavior while user press Back key: the SL app navigates backward in stack (and terminates when last page in back stack is reached) but WP8.1 app being suspended and the system switches to the previous WP8.1 app. To support same Back key navigation behavior as in SL app, the WP8.1 app must override this behavior as follows in the code snippet below:

public App()

{

    this.InitializeComponent();

    this.Suspending += OnSuspending;

    //Subscribe to the event at the App .ctor

    HardwareButtons.BackPressed += HardwareButtons_BackPressed;

    //...

}

 

//Override the default behavior

private void HardwareButtons_BackPressed(object sender, BackPressedEventArgs e)

{

    Frame frame = Window.Current.Content as Frame;

    if (frame == null)

    {

        return;

    }

 

    if (frame.CanGoBack)

    {

        frame.GoBack();

        e.Handled = true;

    }

}

 

//...

Note: this functionality is added by default by VS template.
* Manifest and App package – the new WP8.1 app manifest file is named Package.appxmanifest (same as Windows Store apps) and shares same designer in Visual Studio. The app is compiled into the APPX package, which is the same for Windows Store apps
* XAML – WP8.1 apps uses same version of XAML as Windows Store apps (which is different version of XAML from SL apps)
* Notifications – WP8.1 supports notifications stack from Windows.UI.Notifications namespace. They are using same WNS push notification mechanism (and same tile/toast templates) as Windows Store apps.
* The programming model for background tasks is the same for WP8.1 and Windows Store apps. This is different from SL8.1 apps which still use WP8 background agents programming model.
* Geolocation and Geofencing – new features supported exactly as in Windows Store apps
* Background transfer APIs from Windows.Networking.BackgroundTransfer namespace replace the WP8 background transfer service APIs
* Background audio is provided by Windows.Media.BackgroundPlayback.MediaPlayer class instead of the Microsoft.Phone.BackgroundAudio.BackgroundAudioPlayer class in WP8
* AppBar uses same CommandBar and AppBarButton as Windows Store apps
* Windows.Storage APIs incl. roaming support
* Share Contract – same contract as Windows Store apps with different UX as WP8.1 doesn’t have charms.
* Many other features as Read/Write access to the SD card, Proximity, Security and monetization APIs from Windows Store apps.

For more info about those features please see my blog post here and official documentation.

Universal Windows Apps

In addition to API convergence, the Visual Studio supports new type of the apps – Universal Windows Apps. Those apps enable targeting both WP8.1 and Windows Store platforms in a single solution to complement the convergence of the platform itself. The universal apps has three “projects” in the solution – Windows 8.1 app, Windows Phone 8.1 app and Shared code/resources/XAML section that shared across both platforms:

image

Visual studio helps while writing code in the Shared project, the Visual Studio code editor uses a context that targets one platform or the other. The Intellisense is specific to the context of the code editor – that is, specific to Windows or to Windows Phone:

image

In addition, the app can also use the #ifdef directive to isolate sections of code that are platform-specific. The constants WINDOWS_APP and WINDOWS_PHONE_APP are predefined by Visual Studio.
Lastly, VS helps moving files between Shared/platform specific projects:

image

For more info about new features in tools please see my blog post here and official documentation.

 

Decisions, decisions, decisions…

Based on described above the developer must take a decision of which framework to chose. Let’s see some pros and cons of both.
For the existing WP8 app:

1. Keep using Silverlight/Keep WP8 app

Pros: No porting work required. Will run on WP8.1 (app compatibility), still runs on earlier Windows Phone devices
Cons: Will not take advantage of new platform capabilities, cannot enable targeting of Windows

2. Use SL for WP8.1:

Pros: Some work required – take care of breaking changes. Enables existing Silverlight app to take advantage of nearly all new APIs and new platform capabilities
Cons: Will not enable targeting of Windows AND will not run on Windows Phone 8 devices

3. Use WinRT XAML platform:

Pros: Enables targeting of Windows and Windows Phone while takes full advantage of new APIs and platform capabilities. App enjoys better performance & reduced memory use
Cons: Most porting work required – can be considered as app re-developed almost from scratch AND will not run on Windows Phone 8 devices

 

For the new WP8.1 app the decision “matrix” is simpler – if app must support both Windows and WP or doesn’t need Silverlight-only features (as described above) it should take WinRT XAML approach. Otherwise it should use SL approach.

 

That’s it for now. Next post will show the new and improved XAML controls available for WP8.1 apps.

 

Stay tuned,

Alex

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*