Taking a closer look at Universal Apps

 Jun 04, 2015

Universal Apps were publicly introduced in Microsoft’s BUILD 2014 conference held in San Francisco in April 2014. With Universal Apps, you can develop one code base and with just a few tweaks to the user interface to account for the differences in the form factors and hardware capabilities, you can sell your app in two stores instead of just one. In today’s blog post, I will dig deeper into the concept of a Universal App and compare it with other code sharing strategies.

Windows Phone 8.1 was rolled out at BUILD 2014 on April 2, 2014 and reached general availability on July 15, 2014. Microsoft also made available at BUILD 2014 a release candidate of Visual Studio 2013 Update 2, which had it as its main new feature support for Windows Phone 8.1 apps development and of course, the introduction of Universal Apps, which is essentially a combination of a Windows 8.1 project in the same solution with an additional shared project containing the common code base for both platforms.

If you have, at the very least, the Visual Studio 2013 Update 2, you will find new templates for Universal Apps for C#, JavaScript and C++. At BUILD 2014, it was announced that VB would also have support for Universal Apps, but up to the Visual Studio 2013 Update 4 which was released in November 2014, the templates for VB are not yet included.

In the following screenshot you can see the templates for C#.
universal-apps-01
The next screenshot shows the Solution Explorer for a Blank App which I named DemoApp1.
universal-apps-02
As you can see, we have 3 projects in 1 solution. All the shared code should be placed in the DemoApp1.Shared node at the bottom. We refer to the first 2 projects as head projects. The template has included separate xaml files for the MainPage in each head project, but if this page does not require a different layout for the Phone and the tablet or PC, we certainly can move it into the shared project as you can see in the next screenshot.
universal-apps-03
Next, I added a TextBlock into the MainPage.xaml and configured Visual Studio to start both projects at the same time. We are using the simulator for the Windows App instead of opening the app full screen. The Windows Phone app always uses the Windows Phone emulator. You can see the result in the next screenshot, the Windows Phone 8.1 emulator on the left side and the Windows 8.1 simulator on the right.
universal-apps-04
A question you may ask is how I could get different messages displayed by my TextBlock if I am sharing the same file between the Windows and Windows Phone head projects? If we had kept the 2 pages as they were originally, it would be obvious, but now both projects share the same xaml page. The answer is quite simple and shows one of the main techniques to adapt your code to the 2 platforms as the next screenshot shows you.
universal-apps-05
We are looking at conditional compilation directives. Note that the code after the #else is greyed out.


In the next screenshot, I expanded the drop-down on the top left and selected the WindowsPhone option. Now every piece of code that compiles exclusively for the Windows platform will be greyed out.
universal-apps-06
We have above just one very simple example using conditional compilation to adapt the code to the 2 platforms. The following code snippet shows another example.

#if WINDOWS_PHONE_APP Windows.Phone.UI.Input.HardwareButtons.BackPressed += this.HardawareButtons_BackPressed; #endif

The code above is assigning an event handler to the Back button of your phone. This code does not make sense for a tablet or PC, only for the phone. The conditional compilation directive takes care of only compiling it for the Windows Phone platform.

For those pages that will need a rather different layout in the 2 platforms, we would simply maintain each one in its own head project and not use any conditional compilation in the corresponding code behind file. It’s not uncommon that many pages would not make into the Shared project as only in simple cases, we would expect the UI to be shared between a phone and a tablet. Most of the logic of your app should not be located in code behind files but in other classes, they would almost certainly be located in the Shared project. If you follow the MVVM pattern, that will definitely be the case.

The convergence between the APIs for Windows 8.1 and for Windows Phone 8.1 is above 90%, so it makes quite easy to write code that runs in both platforms. For those cases where we do need different code for each platform, we can rely on conditional compilation. The majority of the classes that are not coded behind for xaml pages would be shared. Another great candidate for sharing are assets like pictures.

Another approach to code sharing is the use of Portable Class Libraries (PCL). PCLs we introduced in January 2011 as an add-on to Visual Studio 2010. They are still supported in the latest updates for Visual Studio 2013. When you create a new project using a template for a PCL, you can choose which platforms your library will support and then only code that compilation for all selected platforms that can be included in your project.

In the following screenshot I am selecting the 2 platforms you have in a Universal App, Windows 8.1 and Windows Phone 8.1.
universal-apps-07
A PCL is quite different from the Universal App in the sense that you can only write code that compiles for all the platforms. There is no conditional compilation involved. Once you compile the PCL, you can add it separately as a reference to other projects. So the PCL is not at all equivalent to the Shared project node you have in a Universal App solution. All the code in the shared project of a Universal App is compiled as part of the head projects; the Shared project itself is not compiled individually.

You can combine PCLs with Universal Apps. It is very convenient to use a PCL to hold utility code that can be consumed by both head projects in the Universal App solution. You just add the PCL as a reference to both head projects. Note, that once the reference is added to the head projects, the code in the Shared project can also make use of the PCL utility classes.

We can see the Universal App as an evolution of the linked file concept, which has been available since the very beginning of Visual Studio .NET in 2002. When you add an existing item to a project, you usually make a copy of the original file into the project folder, but if you click the down arrow on the right of the "Add" button, you see an option to Add as Link. Now the file is just linked to the project and any modifications will still be stored in the original location of the file.

Let’s explore the concept of linked files to get at something that resembles a Universal App. Start by adding a Windows 8.1 Store project and a Windows Phone 8.1 to the same solution. Now right-click the solution and select Add | New Solution Folder. Call the folder "Shared." Click the Shared folder and add a class to it. If you define conditional compilation symbols WINDOWS_APP for the Windows 8.1 project and WINDOWS_PHONE_APP for the Windows Phone 8.1 project, you will be able to write the same kind of code in the classes in the Shared folder as we do in the Shared project of a Universal app. You will find the conditional compilation symbols text box in the Build tab of the Properties page for the project. Just type in the compilation symbol. The last step is to "Add as Link" each of the classes in the Shared folder to both projects in the solution. The next screenshot shows the end result with just one class called SharedClass1.
universal-apps-08

You can double-click SharedClass1 in either one of the two projects to edit the code, but you are always sharing the same code. When you build the solution you are building the 2 projects independently from each other and the conditional compilation instructions in the SharedClass1 would work exactly as in a Universal app.

To learn more about universal apps you can watch some of the recorded sessions of the BUILD 2014 conference.

Universal Apps were publicly introduced in Microsoft’s BUILD 2014 conference held in San Francisco in April 2014. With Universal Apps, you can develop one code base and with just a few tweaks to the user interface to account for the differences in the form factors and hardware capabilities, you can sell your app in two stores instead of just one. In today’s blog post, I will dig deeper into the concept of a Universal App and compare it with other code sharing strategies.

Windows Phone 8.1 was rolled out at BUILD 2014 on April 2, 2014 and reached general availability on July 15, 2014. Microsoft also made available at BUILD 2014 a release candidate of Visual Studio 2013 Update 2, which had it as its main new feature support for Windows Phone 8.1 apps development and of course, the introduction of Universal Apps, which is essentially a combination of a Windows 8.1 project in the same solution with an additional shared project containing the common code base for both platforms.

If you have, at the very least, the Visual Studio 2013 Update 2, you will find new templates for Universal Apps for C#, JavaScript and C++. At BUILD 2014, it was announced that VB would also have support for Universal Apps, but up to the Visual Studio 2013 Update 4 which was released in November 2014, the templates for VB are not yet included.

In the following screenshot you can see the templates for C#.
universal-apps-01
The next screenshot shows the Solution Explorer for a Blank App which I named DemoApp1.
universal-apps-02
As you can see, we have 3 projects in 1 solution. All the shared code should be placed in the DemoApp1.Shared node at the bottom. We refer to the first 2 projects as head projects. The template has included separate xaml files for the MainPage in each head project, but if this page does not require a different layout for the Phone and the tablet or PC, we certainly can move it into the shared project as you can see in the next screenshot.
universal-apps-03
Next, I added a TextBlock into the MainPage.xaml and configured Visual Studio to start both projects at the same time. We are using the simulator for the Windows App instead of opening the app full screen. The Windows Phone app always uses the Windows Phone emulator. You can see the result in the next screenshot, the Windows Phone 8.1 emulator on the left side and the Windows 8.1 simulator on the right.
universal-apps-04
A question you may ask is how I could get different messages displayed by my TextBlock if I am sharing the same file between the Windows and Windows Phone head projects? If we had kept the 2 pages as they were originally, it would be obvious, but now both projects share the same xaml page. The answer is quite simple and shows one of the main techniques to adapt your code to the 2 platforms as the next screenshot shows you.
universal-apps-05
We are looking at conditional compilation directives. Note that the code after the #else is greyed out.


In the next screenshot, I expanded the drop-down on the top left and selected the WindowsPhone option. Now every piece of code that compiles exclusively for the Windows platform will be greyed out.
universal-apps-06
We have above just one very simple example using conditional compilation to adapt the code to the 2 platforms. The following code snippet shows another example.

#if WINDOWS_PHONE_APP Windows.Phone.UI.Input.HardwareButtons.BackPressed += this.HardawareButtons_BackPressed; #endif

The code above is assigning an event handler to the Back button of your phone. This code does not make sense for a tablet or PC, only for the phone. The conditional compilation directive takes care of only compiling it for the Windows Phone platform.

For those pages that will need a rather different layout in the 2 platforms, we would simply maintain each one in its own head project and not use any conditional compilation in the corresponding code behind file. It’s not uncommon that many pages would not make into the Shared project as only in simple cases, we would expect the UI to be shared between a phone and a tablet. Most of the logic of your app should not be located in code behind files but in other classes, they would almost certainly be located in the Shared project. If you follow the MVVM pattern, that will definitely be the case.

The convergence between the APIs for Windows 8.1 and for Windows Phone 8.1 is above 90%, so it makes quite easy to write code that runs in both platforms. For those cases where we do need different code for each platform, we can rely on conditional compilation. The majority of the classes that are not coded behind for xaml pages would be shared. Another great candidate for sharing are assets like pictures.

Another approach to code sharing is the use of Portable Class Libraries (PCL). PCLs we introduced in January 2011 as an add-on to Visual Studio 2010. They are still supported in the latest updates for Visual Studio 2013. When you create a new project using a template for a PCL, you can choose which platforms your library will support and then only code that compilation for all selected platforms that can be included in your project.

In the following screenshot I am selecting the 2 platforms you have in a Universal App, Windows 8.1 and Windows Phone 8.1.
universal-apps-07
A PCL is quite different from the Universal App in the sense that you can only write code that compiles for all the platforms. There is no conditional compilation involved. Once you compile the PCL, you can add it separately as a reference to other projects. So the PCL is not at all equivalent to the Shared project node you have in a Universal App solution. All the code in the shared project of a Universal App is compiled as part of the head projects; the Shared project itself is not compiled individually.

You can combine PCLs with Universal Apps. It is very convenient to use a PCL to hold utility code that can be consumed by both head projects in the Universal App solution. You just add the PCL as a reference to both head projects. Note, that once the reference is added to the head projects, the code in the Shared project can also make use of the PCL utility classes.

We can see the Universal App as an evolution of the linked file concept, which has been available since the very beginning of Visual Studio .NET in 2002. When you add an existing item to a project, you usually make a copy of the original file into the project folder, but if you click the down arrow on the right of the "Add" button, you see an option to Add as Link. Now the file is just linked to the project and any modifications will still be stored in the original location of the file.

Let’s explore the concept of linked files to get at something that resembles a Universal App. Start by adding a Windows 8.1 Store project and a Windows Phone 8.1 to the same solution. Now right-click the solution and select Add | New Solution Folder. Call the folder "Shared." Click the Shared folder and add a class to it. If you define conditional compilation symbols WINDOWS_APP for the Windows 8.1 project and WINDOWS_PHONE_APP for the Windows Phone 8.1 project, you will be able to write the same kind of code in the classes in the Shared folder as we do in the Shared project of a Universal app. You will find the conditional compilation symbols text box in the Build tab of the Properties page for the project. Just type in the compilation symbol. The last step is to "Add as Link" each of the classes in the Shared folder to both projects in the solution. The next screenshot shows the end result with just one class called SharedClass1.
universal-apps-08

You can double-click SharedClass1 in either one of the two projects to edit the code, but you are always sharing the same code. When you build the solution you are building the 2 projects independently from each other and the conditional compilation instructions in the SharedClass1 would work exactly as in a Universal app.

To learn more about universal apps you can watch some of the recorded sessions of the BUILD 2014 conference.

How do your Excel skills stack up?   

Test Now  

About the Author:

Newton Godoy  

With over 17 years of in-class training experience and over 16 years of industry experience, Newton offers students a wealth of real-world technical knowledge and expertise in the areas of .NET application development, SQL Server and SharePoint Server. After spending several years lecturing as a professor, Newton found his true calling and began his career as a MCT. He worked as a technical trainer for some of Brazil's and Australia’s largest corporate training organisations before finally finding a home with New Horizons where he is now one of our top trainers. Newton brings a thorough mentoring capability to the classroom where he can advise on technical issues and challenges often beyond the scope of the course curriculum. His combination of technical knowledge and instructor experience make him one of the most respected instructors within the IT training industry.

Read full bio
top
Back to top