What Does It Mean To Be Universal

So what does it mean to be universal when it comes to Windows 10?  A new way of building applications is coming in Windows 10. The past few years Microsoft has been on this path of converging all of their operating systems to run on a common core.  Windows 10 is the culmination of this journey. One of the benefits of having a common core is the ability to create an API that will allow apps to run across all the devices that use this core.  So Microsoft introduced the Universal Application Platform (UAP). 

 

The UAP will allow developers to build applications that will run across the One Windows Platform. There are many challenges to achieve this goal of write once and run on all these devices. There are all kinds of devices that these apps can run on from phones with 4” screens, to running on Xbox with 52” screens, to devices with no screens at all. These different device have different capabilities. So how do you address these needs.

How Did We Get Here

Back in the day Microsoft’s “cross” platform solution was to create a portable class library. These libraries were restricted to the least common denominator of frameworks you want to address. This created a dll that could be referenced by the reference frameworks. This was great except that you were restricted on which API’s you had access to plus you ended up with multiple applications.

With Windows 8.1, Microsoft introduced a universal application template that helped developers build phone and modern Windows 8.1 apps. A “minor” convergence of the API happened, bringing the phone and the tablet closer together. The converged API allow for more code reuse and minimal device specific code. It did this by creating a shared project that injected the common files into each project (Windows and Phone). So you could share a lot of code but in the end you still have two applications. And the code you write for these universal apps was specific for the phone and modern applications (formally known as Metro).

Moving Forward

In Windows 10, Microsoft is taking the concept of universal apps from Windows 8.1 and expanding on it to cover a wider array of devices. The common core operating system was the first step. At the base of the Universal Application Platform is this thing call the Universal Device Family. This is the set of APIs that are guaranteed to be available to all applications written with UAP.  Once an UAP app is compiled there is one app package that can run on all these different device families.

From the diagram above you can see that there are many device families that your application can target (one, some, or all). Does that mean there will be Xboxs API installed on my desktop? There has to be if I expect my code to compile, right? Also how do I take advantage of device specific functionality, like the hardware back button on my phone? Hey some of those IoT devices are pretty small to be having all these APIs installed, remember we are creating one package to rule them all.

Microsoft handles this through Extensions. When you need to target specific functionality tied to one of these device families, you add a reference to the extension for that device family. Those extensions are just metadata files with the available API’s for that device family. When the application compiles it does so against these metadata files.  The actual API’s will be installed on those specific device families.

ApiInformation

Now that I have those references I can start writing code for the phone back button and expect that code to run just fine on the Xbox right? Well not quite. You don’t want to try to call an API that is not implemented on you specific device family where your app is running.  You will get all kinds of run time errors. How do you handle these API calls?

In the past when we had shared code, we would isolate device specific code in #IF statements. But wait you said there would be one app package and #IF suggest multiple since it is a compiler directive. In Windows 10, you do not want to query for device types. Device types will be added all the time and your #IF statements could get out of control. Instead, Microsoft, has provided a means to query for capabilities/API.  They have introduced the ApiInformation class. 

The ApiInformation class allows you to test for the presence of the API you want to call. Here is an example checking to see if there are phone hardware buttons present.

On thing to notice is the use of Magic Strings.  Those are bad. I hope that Microsoft comes up with a better way to do that. Maybe have a constants file that contains the most common types users are going to query for and the leave it up to the user to handle the exotic cases. Either way there is a good chance that you will fat finger a fully qualified name. It is an early release of the SDK so things can and most likely will change.

By querying for specific capabilities, line 39 will only run if there are hardware buttons present.

The …

The beauty of the UAP approach is that it is extensible.  Did you notice “…” in the diagram above.  They are leaving it open for new platforms in the future, say for instance HoloLens. Or even devices that don’t exist today.  If you install the preview SDK you will see that there are only 2 extensions present, one for the desktop device family and one for the phone device family. Expect more to come in future releases.

Final Thoughts

The direction that Microsoft is going is exciting. It will be interesting to see how they follow through on this One Windows Platform vision. It will also be interesting to see if someone like Xamarin can take advantage of the UAP and extend it to iOS and Android.  Hopefully we will get more insight at Build this year.