Windows Universal apps and more: Part 2 - full support in MobileFirst 7.1

IBM MobileFirst 7.1 has started the support for the Windows Universal app development paradigm. In a previous post I had explained a manual procedure of developing a C# Windows universal app using MobileFirst 7.0 DLLs. That post also explained in detail the Windows 8.1 Universal App development paradigm. Starting with MFP (MobileFirst Platform) v7.1 support was added for Windows 8.1 Universal apps as environments.

As you can see in the nice image below – Microsoft started the convergence process since Windows Phone 7.

Windows 8.1 was the first time Microsoft introduced the converged app model called Universal apps - with a single Visual Studio Solution for both tablets and phones. This was the first time Windows Phone apps uwing the Win RT API was introduced (Windows Phone 8 was Silverlight API based). They are referred to as the Windows 8.1 Universal apps. Just to re-cap, Windows 8.1 Universal apps are one solution with 3 projects – one for Phones, one for desktops/tablets and one for shared code. This ultimately produces 2 .appx installable files.

So in essence a Windows 8.1 Universal app produces 2 mobile app appx files.

This is the reason in MFP we represent a Windows 8.1 Universal app as set of 2 environments –

• WindowsPhone8 - Universal
• Windows8 - Universal

Of course in addition to this we have had the WindowsPhone8 environment – which is for Windows Silverlight based phone apps.
The inventory of app types in MFP looks like follows:

Upgrades

If you have existing Windows Phone app, Microsoft has provided some options to you as a developer.
We have tried our best to support you in this decision making process.

Hybrid MFP apps

When you upgrade an existing Windows8 Hybrid app, a new "WindowsPhone8 – Universal" environment is added to the app-descriptor.xml. Along with this, the folder structure of the Visual Studio project is changed to add the shared and the Phone projects and a solution file is added to tie all these in.
In case of the WindowsPhone8 – Silverlight apps – there is no change in the structure.

Native MFP apps

When you upgrade a existing native app – there is no change in the project structure – you will just see a change in the label in the studio.

This is what we finally landed up with

Our direction

To this effect we have significantly bolstered the Windows8 RT API set which is moving forward as the Windows Universal set of MFP environments. In 7.1 We have aggressively reduced the feature parity gaps between Windows and other platforms. Some of the features introduced in MobileFirst 7.1. are

• Support for Windows Universal Hybrid apps
• Basic and Extended Application Authenticity Protection
• Support for REST calls from client apps
• Device authentication
• Support for OAuth2

What is still a wild card is the Silverlight phone environment. There really is no “upgrade” strategy announced by Microsoft from Silverlight to the Universal. Its essentially a re-write of the app.

At the time of writing this post – the Windows 10 UWP has released. We are still waiting for Windows Phone 10 to be GAd. I believe there will be a significant number of MFP users who will still be building Windows 8.1 Universal apps – since their code bases are tooled to Windows 8.1, and Windows 8.1 apps will continue to work on Windows 10.

Our thought process

In terms of the environment identifiers and MFP project folder names, a newcomer might feel the naming is a bit off. But this is deliberate as we have to carry forward a legacy from previous releases.

The Windows RT API environment was called "windows8" and the Silverlight API environment was called "windowsphone8". In Windows 8.0 timeframe the Windows Phone SDK was a Silverlight SDK. As explained above, we moved forward the "windows8" environments to the full Windows 8.1 Universal app paradigm. This is where Microsoft introduced the Windows Phone 8.1 apps based on the Win RT API. So we had to add a new Win RT phone environment – but we could not call it "windowsphone8" as it was already taken by the existing Silverlight phone environment. Changing the internal identifiers (app descriptor XML tags, database, folder names etc.) would have forced a massive migration of the environments.

In my opinion that was unnecessary. So we retained the old nomenclature for the existing environments so the folder names in your source control don't go for a toss; and added the "windowsphoneuniversal" identifier to identify the Windows RT phone app type. We are still supporting the Silverlight phone environment (windowsphone8) since we are expecting some of our customers may not be ready to re-code their apps to the Win RT API set but want to leverage the platform functionalities of MFP 7.1. We will continue to watch what Microsoft announces with their Silverlight phone roadmap. But if you are starting a new app – Win RT API set seems to be the recommendation.

We are committed to our existing and new customers who support Windows mobile apps using MFP on this unification journey that Microsoft is on.