May 2015
Volume 30 Number 5
Windows 10 - An Introduction to Building Windows Apps for Windows 10 Devices
By Andy Wigley
You have lived to see it: a single Windows OS that can run across every type of Windows device. It has a single device platform to enable true universal hardware drivers and a single application platform to enable true universal Windows apps. Years in the making, this is a significant engineering accomplishment.
At the OS level, this means a single, maintainable and agile code base. For developers, it provides a unified, reliable API surface across every Windows device, from Internet of Things (IoT) devices such as Raspberry Pi to phone, Xbox, tablet, Surface Hub, laptop, PC and more (like Microsoft HoloLens). As shown in Figure 1, it’s a write-once-run-everywhere promise delivered in Windows 10 with the universal application platform (UAP).
.png "The Universal App Platform Enables Apps Across All Windows Device Families")
Figure 1 The Universal App Platform Enables Apps Across All Windows Device Families
The Journey to Windows 10
The convergence of Windows has been a long time coming. Back in 2011, Microsoft had three platforms with three OSes. The PC and server OS was Windows, built on the Windows NT code base. The phone OS was Windows Phone, a derivative of Windows CE with surface-level similarities to Windows NT, but a different code base. The Xbox 360 OS was Windows NT, but it was a 10-year-old fork so wildly divergent that it, too, was a distinct code base.
At that time, Microsoft worked to bring a common Internet Explorer to each platform. There was no Windows Core, no Windows platform, and no UAP. The implementation of Internet Explorer on these three OSes was successful, but required considerable engineering gymnastics.
With Windows Phone 8, the Windows NT OS kernel replaced Windows CE on phones. This convergence moved things down the road toward a single code base. Windows, Windows Phone and Xbox 360 all leveraged the same kernel, though each still had unique code bases. In 2013, Xbox One launched and with it an OS core shared with Windows 8. Microsoft was so close to one code base you could smell it, but it was still servicing three distinct OSes.
Windows 10 was the chance to bring together this troika and converge engineering efforts. At the same time, however, new applications of technology demanded the addition of more Windows targets: IoT, Microsoft HoloLens, Surface Hub and future members of the Windows device family. Windows 10 needed to be one OS not only for Windows, Phone and Xbox, but also for every future platform.
Microsoft did it. Windows 10 has become the small footprint, one core OS that runs on every device family. This was not as simple as File | Save As. Smart people worked hard to deliver an engineering marvel in an incredible time frame. Windows 10 is the single code base necessary to enable the UAP. Every Microsoft product from this point forward will be written against the single core that makes up Windows 10.
Unity Not Uniformity Uniting the code bases to one core OS doesn’t mean one UI across different devices. Windows Phone has a clever, much-loved, one-handed interface significantly distinctive from the 10-foot Xbox experience. The same is true with the Surface Hub, Microsoft HoloLens and Raspberry Pi. These deliver a bulk of their value through their unique experiences. Still, the OS with its libraries, runtime and frameworks, is the same. The device platform and the application platform are the same. The UI and shell features, however, are distinct and tuned to the correct usage model for each device. These are not the same.
In theory, someone could boot to this core OS and even run apps, but no one ever will because it’s just a building block. To properly support each form factor, device-specific shell components are added to the core OS—like the Start Menu, specific HID support, and any pieces and parts necessary to enable device-specific features such as desktop applications. These extra components build up from the basic OS to form the different OS SKUs you see as Microsoft products, such as Windows, Server, Xbox and HoloLens.
One Application Platform Here’s a fun game to play with your friends. Tell them you’re going to embrace the latest Microsoft app innovations, but you won’t be targeting Windows 10. How? Next-generation Windows apps won’t target the OS. Instead, they’ll target the app platform. On Windows, the UAP is a consistent application model and API surface guaranteed across every Windows device.
The UAP isn’t a runtime. A Windows app, even one written in a managed language (like Visual Basic or C#) compiles to the metal like any other app. It doesn’t run inside a runtime. It doesn’t require a runtime. UAP is a common API surface across devices, so targeting the UAP is targeting a specific set and version of APIs.
It’s worth pointing out that you build Windows apps and games with the tools and technologies you already know. Windows apps written in managed languages still enjoy the Microsoft .NET Framework, which itself is only a collection of interfaces, base classes and helper methods. The subset of the full .NET Framework that’s used in managed Apps targeting the UAP is called .NET Core. Supplementing this, the majority of the APIs you use in Apps targeting the UAP are in the Windows Runtime, which projects into every language, not just the managed languages.
It’s Not Just XAML This article will demonstrate a XAML application, but DirectX and JavaScript apps (Windows Web apps) are also supported by the UAP, just as they were in Windows 8. That being said, it’s fascinating to look at the emerging XAML story. XAML is important to many Microsoft platforms—Windows Presentation Foundation (WPF), Silverlight in the browser and on Windows Phone, and now in the Windows UI platform (which started out as code name “Jupiter”).
Microsoft Office 2016 is now a family of UAP apps. What UI technology does it use? XAML. Thanks to this relationship, the XAML platform is rich with features and controls that Microsoft and third-party developers, like you, can use in their Windows apps.
The Windows desktop shell introduces many new features, like the Start Menu and Action Center. What UI technology does it use? XAML. Thanks to this relationship, the XAML platform is hyper-performant, delivering rendering capabilities for sub-second performance if you take advantage of it.
When it comes to XAML, Microsoft is all in. Many important OS apps, like Photos, and MSN apps, such as Health & Fitness, rely on the XAML UI platform to deliver the same rich features every developer can leverage in their Windows apps. What you see in Microsoft apps you can do, too. Not only is the API surface area the same for everyone, so is the XAML UI platform.
Value to Software Developers It’s not enough to write an app that can run on every device. To deliver real value to users, your Windows app needs to light up on different devices. Thanks to the extensibility of the UAP, you can include device-specific code in a single binary that will run on every device.
You get more than one single binary with the UAP, you also get one Store for everything—for phone, tablet, desktop and even Xbox apps. The experience is simplified; the monetization is simplified; and the metrics to monitor marketplace success are simplified, as well.
That one Store and the platform let you deploy assets appropriately. This means assets intended for the Xbox experience won’t push down to the phone. And the capability in Windows 8 to package assets targeting specific resolutions and scale remain in the UAP.
As always, you stay in control. Just because the UAP supports every Windows device, doesn’t mean you have to. You choose which family of devices your Windows app will support. If your Windows app is phone-only, Xbox-only or HoloLens-only, that’s up to you. The Windows Store ensures your app is delivered to the device families you select.
The value to you is not just broader reach, but an easier overall experience. There’s one set of tooling, including Visual Studio and Blend for Visual Studio, which you already know and love. There’s a familiar set of languages, including JavaScript, the .NET Framework (Visual Basic or C#) and C++/CX. In the end, you and your team build Windows apps using what you already know.
Plenty to Consider
With great power comes great responsibility. The UAP enables Windows apps to run on every type of Windows device. This is awesome, but it comes with a caveat: Not every device provides the same UX. This means that although you get to employ many of the same responsive Web design (RWD) techniques you use in your Web applications, you must think through how your Windows app workflow plays out on different types of devices intended for different types of use. The UAP can only enable support on different devices; it’s up to the developer and the designer to build a UX that’s great on all of them.
Microsoft provides generous tooling to help build responsive and adaptive Windows apps. Visual Studio can simulate aspect ratio, scale and size during design time. Visual Studio can also simulate (and sometimes emulate) specific device targets even if you don’t own the hardware. This lets you test Windows apps and finesse your experiences along the way.
The XAML toolbox has several new controls and enhancements to help you create responsive and adaptive interfaces that look great on every device and every size display. For example, the RelativePanel is new to XAML developers. It inherits from Panel like every other layout control, such as Grid and StackPanel, but allows designers and developers to position child elements relative to other child elements. The resulting XAML visual tree is simpler to render and far simpler to manipulate in response to layout changes. Visual States are another enhancement for XAML developers, making it simpler to respond to layout changes.
This is important: Creating a Windows app that targets multiple devices doesn’t mean writing to the lowest common denominator. The UI is rich and so is the feature set. Runtime checking (using the Windows.Foundation.Metadata.ApiInformation namespace) empowers you to include device-specific capabilities that light up your apps for the best possible UX on every device. New features and converged controls are the building blocks you need to dream big.
Anatomy of a Windows App
Now let’s take a look at the essential techniques for creating a Windows app that will run across any device family. We’re assuming you’re familiar with Windows 8.1 Windows Runtime (WinRT) XAML app development. Windows apps are the evolution of those apps. You’ll find many resources on Microsoft Virtual Academy for learning, which you can find at aka.ms/w8learn. This article concentrates on new features in the UAP—for running Windows apps across device families.
In Visual Studio 2015, the Templates/Visual C#/Windows Universal node in the New Project dialog has several project templates: the Blank App, the Class Library and the Windows Runtime Component. You use the Blank App template to build a Windows app. The Class Library and Windows Runtime Component templates allow you to encapsulate UI and logic for reuse in other projects. A Class Library supports non-UAP apps, but is limited to managed languages; Windows Runtime Components can be shared across languages (including JavaScript and C++/CX), but have rules that constrain their public API surface.
For this sample, choose Blank App, as shown in Figure 2.
.png "By Default, Windows Apps Now Use the Blank Template")
Figure 2 By Default, Windows Apps Now Use the Blank Template
Where are all the other templates? Consider the Hub App template that shipped with Windows 8. Many developers used it. Many developers copied it. This rash of “me too” apps created visual consistency within the Windows Store, but didn’t contribute to ecosystem diversity. Now, the Blank App template is at center stage, encouraging developers to create visually consistent yet distinctive interfaces on the platform. Many community-based templates have already started appearing in the Visual Studio Gallery, including one, Template10, that was written by the authors of this article.
Hello World! You’ve created your first Windows app. Though the UI is blank, it can already run on every Windows device. The Visual Studio Solution Explorer reveals how simple a basic Windows app is: a single project with an App.xaml and a single MainPage.xaml file for the initial UI.
Your solution includes other familiar support files. The Package.appxmanifest declares the capabilities the app will request from the user’s machine, such as the user’s location; accessing the camera; and the file system. The XML schema has been expanded, but is about the same as the appxmanifest for Windows 8.1 universal apps.
Where are the two heads? Windows 8 universal apps required both a Phone and a Windows head project. UAP doesn’t require multiple heads. Instead, you adapt your interfaces to accommodate to wherever your Windows app is running. That being said, you certainly can create a multi-headed solution if it suits your development team’s workflow. Both approaches are equally supported.
Including Content When you open MainPage.xaml, you’ll see the improved Visual Studio XAML design-time experience. The designer is richer and faster; the ability to simulate aspect ratio and scale has improved; and the tooling itself is expanded. Now let’s add a little XAML, as shown in Figure 3. (Thanks to our colleague David Crawford for this sample.)
Figure 3 The RelativePanel Allows You to Layout Your Interface in a Simple Way
<Grid Background="{StaticResource EggshellBrush}">
<RelativePanel x:Name="PromoArea">
<Image x:Name="BannerImage" HorizontalAlignment="Right"
Height="280" Stretch="UniformToFill"
Source="Assets/clouds.png"
RelativePanel.AlignRightWithPanel="True"/>
<Grid x:Name="BannerText" Margin="24"
Background="{StaticResource BlueBrush}">
<StackPanel Margin="12" HorizontalAlignment="Stretch">
<TextBlock x:Name="Headline" Text="Come fly with us"
Margin="0,-32,0,0" FontSize="48"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource LustScriptFont}" />
<TextBlock x:Name="Subtitle" FontSize="21.333"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource DomusTitlingFont}">
<Run Text="Fly return to London"/>
<LineBreak/>
<Run Text="For only $800"/>
</TextBlock>
</StackPanel>
</Grid>
</RelativePanel>
</Grid>
The code in Figure 3 creates the page header for a simple app for a fictional airline. Specifically, it leverages the new XAML RelativePanel, which allows you to rearrange the interface in a simple way. The RelativePanel will position the banner image to the right of the page and contains the grid holding the airline’s recent special offerings.
Adding Some Assets The XAML references three files we’ve added to the Assets folder—an image file, Clouds.png, and two custom fonts, DomusTitlingFont.ttf and LustScriptFont.ttf. The fonts and custom Brush resources are declared in App.xaml:
<Application.Resources>
<SolidColorBrush x:Key="BlueBrush" Color="#FF1C90D1"/>
<SolidColorBrush x:Key="EggshellBrush" Color="#FFFAFFF7"/>
<FontFamily x:Key="LustScriptFont">
Assets/Fonts/LustScriptDisplay.otf#Lust Script Display
</FontFamily>
<FontFamily x:Key="DomusTitlingFont">
Assets/Fonts/DomusTitling.otf#Domus Titling
</FontFamily>
</Application.Resources>
These files are included in the code download that accompanies this article.
Note that the bitmap image is at one scale. If you want to accommodate devices with higher resolution, you could scale your assets and name them using the appropriate scale factor so every user gets the best visual experience without downloading assets for other scale factors.
Running on Devices Back in MainPage.xaml, the UI is taking shape. To run the app, you can select the target in the Visual Studio device target dropdown. Notice that it includes the Windows Simulator (for touch testing), Local Machine, Remote Machine (for testing ARM) and Device (real phone hardware). The phone emulators are in the same list. Choose and run on Local Machine and afterward on one of the Phone emulators to see your Windows app run on different devices without any special compilations.
You might have noticed that running a Windows app on the Local Machine, in other words on the desktop of your PC, is a windowed experience and not the full-screen experience of Windows 8. This is because you’re running your app on the desktop SKU of Windows 10. The mobile SKU of Windows 10 still launches Windows apps full screen to make touch navigation easier. But, the desktop SKU of Windows 10 will also launch Windows apps full screen if you choose the touch experience through the Continuum interface on a tablet or a convertible laptop.
Adaptive Interfaces Though the Windows app runs on both devices, upon closer inspection the UI isn’t great on the phone’s smaller screen. The header text is too big for the small screen and is truncated. This is the beginning of a longer journey to test and improve the UX on the variety of possible devices for this Windows app.
We’ll modify the layout of the header when we detect the narrower screen of the phone. It’s important, however, to recognize that it’s not the phone being detected; it’s the width of the screen. This allows for a narrow experience on both the desktop and the phone.
Note that there’s no API to detect a phone. However, should your design require one-handed operation specific to the phone and smaller tablets, you can test for the diagonal size of the physical device in a custom Visual State trigger (which isn’t discussed in this article).
Visual States are not new to XAML. The Visual State Manager allows developers and designers to define different Visual States (meaning different screen layouts) and to switch among them at runtime. Visual State Adaptive Triggers are new with the UAP. They do away with the programmatic approach to switching Visual States. Instead, you declare when a Visual State should be visible in XAML and the underlying platform does the rest.
Now, modify the XAML in MainPage.XAML, as shown in Figure 4.
Figure 4 XAML Now Supports Declaring Rules for Adapting an Interface
<Grid Background="{StaticResource EggshellBrush}">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="WindowStates">
<VisualState x:Name="NarrowState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="120"/>
<Setter Target="BannerText.(RelativePanel.Below)"
Value="BannerImage"/>
<Setter Target="BannerText.Width" Value="660"/>
<Setter Target="BannerText.Margin" Value="0,0,0,24"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="12"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="MediumState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="660"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="180" />
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="14"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="WideState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1000"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<RelativePanel...
In Figure 4, notice that there are three Visual States declared: NarrowState, WideState and MediumState. Each of these Visual States corresponds to different ranges of screen width. You’re free to create as many or as few Visual States as you need to support your targeted device families. The name you use for each Visual State isn’t significant.
The XAML also demonstrates Visual State Setters, which are new in the UAP and let you set a discrete property value without the overhead of a storyboard animation. Here, we’re using setters to change the relative position of the children in the RelativePanel by setting the RelativePanel attached property on the child elements, and we’re also changing the height of the BannerImage and the FontSize of the text elements. With the Visual States in place, the interface does a great job adapting to a narrower screen. Run it and see!
Figure 5 shows how the UI adapts to changes in screen width. In your Windows app, you can take advantage of Visual State triggers to adjust elements in any way that best serves your users.
.png "Adapting to Screen Width Changes")
Figure 5 Adapting to Screen Width Changes
The full version of this sample, which is included in the code download that accompanies this article, develops the UI further, and gives additional examples of using the RelativePanel and Visual State Triggers to implement an adaptive UI.
Adaptive Code The UI adapts to different screens, but device differences extend to more than screen size. For example, phones have hardware buttons such as Back and Camera, which might not be present on a different platform such as a PC. The default UAP has most of the API surface Windows apps need, but device-specific functionality is unlocked with Extension SDKs that you add to your projects just like external assemblies, as shown in Figure 6. They enable a broader set of device-specific functionality without invalidating the ability for your app to run on other types of devices.
.png "Adding an Extension Is as Simple as Adding a Project Reference")
Figure 6 Adding an Extension Is as Simple as Adding a Project Reference
The two most common platform Extension SDKs are the Desktop and Mobile extensions, which enable functionality unique to their respective Windows SKU. The Mobile extension, for example, enables the APIs necessary to use the hardware camera button.
The Windows Mobile SKU can run on phones and small tablets. However, not all tablets (not even all phones) have a hardware camera button. Extension SDKs enable button support, but don’t put buttons on the device. As a result, at run time, you must test for device capabilities before you invoke the capabilities in the Extension SDK.
Just as platform Extension SDKs like Mobile and Desktop unlock the capabilities of devices for Windows apps, custom Extension SDKs add support for additional components, like the Kinect for Windows or third-party hardware. These, too, don’t prevent your app from running on other types of devices.
How do you check for device capabilities? You leverage the methods in the Windows.Foundation.Metadata.ApiInformation class that return a simple Boolean if a type or method is supported on the current device. You can enable your Windows app to use the Camera button with code like this:
if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent(
"Windows.Phone.UI.Input.HardwareButtons"))
{
Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
HardwareButtons_CameraPressed;
}
Notice here how the Windows.Phone.UI.Input.HardwareButtons code is allowed to execute only if the Extension SDK is enabled on the device. Unlike with compilation conditionals, testing for capabilities doesn’t result in multiple binaries. This means you can light up or gracefully downgrade the UX according to the capabilities of the current device. This is a powerful approach to enable a single binary; it creates limitless variability, letting you make the most of your Windows apps on different device families.
Wrapping Up
If you’re comfortable with Windows 8 universal app development, then building Windows apps targeting the UAP should feel like home cooking. Windows apps don’t target Windows 10; the UAP is the target and it’s decoupled from the Windows SKU. UAP increments versions at a cadence apart from Windows. This means Windows apps won’t need to retarget every time the Windows OS revs. Windows apps target one or more UAP versions and test for those capabilities just as they test for device capabilities. This flexible approach gives you a nice, clean way to take advantage of future capabilities.
Building a Windows app means your app can run on any Windows device. This gift comes with a real-world caveat: The UAP can run your app, but only developers and designers can make the UI and the code adapt to deliver the best possible UX. If you want to build separate device-specific binaries, you can do that. But, should you choose to build a Windows app that supports multiple device types, all the tooling and infrastructure is in place and ready to make you successful.
Jerry Nixon is a developer evangelist for Microsoft from Colorado. Nixon teaches and speaks on Windows, phone and desktop development. His career launched with Microsoft SQL Server 6.5, delivering data-centric solutions while “database developer” was a novel term. He received a civilian Naval Commendation for security work, preceding his work for the startup that would become Microsoft CRM. For 15 years, Nixon built Microsoft-centric, mobile solutions. Today, he speaks on XAML and mobility at events, communities, and universities and the bulk of his free time is spent teaching his three daughters Star Trek character backstories and episode plots.
Andy Wigley is a developer evangelist for Microsoft from the United Kingdom. He joined Microsoft in 2012, and before that worked as a consultant and was a prominent member of the mobile app developers’ community. He was proud to be named a Microsoft Most Valuable Professional (MVP) for 10 consecutive years. Wigley is well-known for the popular Windows Phone JumpStart videos that are available on channel9.msdn.com and is happy to be working with Jerry Nixon on a follow-up video series on Windows app development.