Windows 8.1 Universal Apps (Part 1: The Basics)
What are Universal Apps for Windows 8.1?
Universal Apps are Microsoft’s current solution to the problem of multiple devices. When you create a Universal App, you have one solution that will run on both Windows 8.1 and Windows Phone 8.1 devices.
This works because Windows Phone 8.1’s runtime (WinPRT) is, generally speaking, completely compatible with WinRT in Windows 8.1, and finally enough code can be shared between the two platforms to make this feasible.
How do they work?
I suggest that you create your own Universal App in Visual Studio so that you can see for yourself what I’m writing about.
To do this, select File -> New Project in Visual Studio and choose Templates -> Visual C# -> Store Apps -> Universal App. Please note that you need to be on Windows 8.1 to create Universal Apps.
The structure of a Universal App is very simple: essentially, you can think of it as three projects in one solution.
These solution will be named APP_NAME, and the projects will be APP_NAME.Windows, APP_NAME.WindowsPhone and APP_NAME.Shared.
APP_NAME.Windows and APP_NAME.WindowsPhone will be compiled normally, as you’d expect. APP_NAME.Shared, however, is not actually a real project, and is not compiled to anything. It’s just a bunch of code that is used by both of the actual app projects.
This shared project can’t have references, either: if you want to use a library in your Shared library, you’ll need to add the reference to both the Windows and WindowsPhone projects to be able to use it.
As a general rule, you’re going to want to have device-specific code (UI code, for the most part) in the Windows/Windows Phone parts, and the rest of your code, such as your ViewModel, should sit in the Shared project.
Other than that, it’s normal Windows 8 app development that applies to Universal Apps. Unfortunately, although understandably, most of the information online at current about Windows Phone development is about Windows Phone 8.0. Most of this information no longer applies, as we have newer APIs and a slightly different application lifecycle. As such, if you’re having a problem, try to find a Windows 8.1 solution rather than Windows Phone 8.0.
Leave A Comment