Introduction to UWP - Universal Windows Platform Application Development

Editor's Notes

• #3: Microsoft has been working to converge its client operating system and developer platforms for a long time. In Windows Phone 7, the operating system was based on Windows CE, a great operating system for small, handheld devices, but different from the OS on ‘big’ Windows. When Windows Phone 8 was launched, we swapped out Windows CE and base it on the Windows NT kernel instead, same as our PCs. We did a similar thing with Xbox One. But it wasn’t until Windows 8.1/Windows Phone 8.1 that we really delivered on a converged developer platform. You can build universal 8.1 apps that share a very high percentage of code and where you program against the same APIs. With Windows 10, we’ve taken that even further and for the first time allow developers to create a single app that can run across all devices running Windows 10. Windows 10 brings developers a unified core OS across all devices and a single app platform.
• #4: Windows 10 runs on a wide variety of devices, from phones with a 4.5” screen, through phablets, tablets, PCs, laptops, convertibles such as the Surface, on desktops and All-in-ones, to the Xbox in your living room and right up to giant 84” screens such as our team collaboration device, the Surface Hub. And it also takes in very tiny cheap computers such as the Raspberry Pi 2, and innovative hardware such as the Hololens.
• #5: We’ve divided this broad range of hardware into different device families – as developers you will likely build apps that target one or more device families. <click> We have small devices and IoT, phones and small tablets are in the Mobile device family, large tablets and PCs in the PC (or as we more usually call it, Desktop) family, the Xbox, Surface Hub (or ‘Team’) and finally the Hololens <click> And all of these device families run the same developer platform – the Universal Windows Platform. You can build a single app that can run across all these device families using a single SDK and distribute apps through a single store. Of course, with this diversity of devices, what we are *not* saying is that you should create one app that kind of works adequately across all these devices. No, we want you to create apps that shine on each device family, so we’ve added APIs, controls and tools to help you build an adaptive UI.
• #6: So let’s take a look at the different ways you can build apps for Windows 10. <click> First of all there are the ‘traditional’ ways of building apps for Windows desktop, using tools such as WPF, MFC and full .NET. These are what we term ‘CWA’ (Classic Windows Apps) and are still a great way of building apps for Windows desktop. Although, note that we are working on some tools, called Project ‘Centennial’ that will allow CWAs to be packaged for distribution through the Windows Store – more on that later. <click> Then, we’ve got the new UWP, which is based on the Windows Runtime APIs that we used for building Windows Store apps in Windows 8.x and Windows Phone 8.1. Here you can use HTML and JavaScript to create universal Windows apps, or XAML and C#/VB or C++, or you can use DirectX and one of the many popular middleware packages to create games. And these all build upon the UWP APIs and can run across all Windows 10 devices. <click> Finally, we’ve got a number of bridging technologies. We want to enable developers to use whichever technologies they are comfortable with, and help them to create Windows apps. So we’ve got eh Windows Bridge for iOS, the Windows Bridge for Android, hosted Web Apps to help web sites to be discoverable through the Windows Store and to call UWP APIs, and a Bridge for classical Windows Apps. More on all of those soon.
• #7: So, what is the Universal Windows Platform? It’s a single API surface that is consistent across all Windows 10 devices. This guaranteed API surface is what enables developers to build a single app that can run across all devices. What we’ve done is taken the Windows Runtime APIs that we first launched with Windows 8, massively expanded it and we’ve also componentized it, dividing it into a number of ‘contracts’. Why ‘contract’? – Because these components provide a contract between the platform and you, the developer, that a certain major version of a contract will offer a guaranteed API surface and behaviors, even through many minor revisions. It allows us to innovate and enhance the platform by releasing updated components exposing new capabilities and allows you to develop apps against a versioned API.
• #8: And it’s a big API! Here’s just a sample of some of the feature areas that UWP APIs cover. As you build apps against the UWP, you will find that the vast majority of the things you want to enable can be achieved by APIs that are in the UWP – and therefore available across all Windows 10 devices. We do have a way of calling device family-specific APIs, and we’ll come onto that shortly. But most of what you need can be found in the UWP.
• #9: And this is a subtle change in your thinking as an app developer: you’re not building apps against an OS – Windows 10 – you’re building apps against the Universal Windows Platform, which is serviced and is updated independently of the OS.
• #10: In your application’s Package Manifest, you will have a declaration such as this. What this says is that this app was built against UWP version 10.0.10240.0 (the first version that went on GA - General Availability). When you create your first UWP apps, the MaxVersionTested will also be set to 10.0.10240.0, but imagine a time in the future, when newer versions of the UWP have been released to install side by side with earlier versions. If you the developer have tested this app on UWP version 10.5.0.0, you can declare this in the manifest. What this then says is that this app package will run just great on 10.5.0.0. It doesn’t mean it cannot run on later versions, just that if it does, then the runtime should enforce version 10.5.0.0 behaviors. The Windows Store uses this information to ensure the best available version of an app package gets deployed to target machines.
• #11: The old days of 3 year OS engineering cycles, at the end of which we release a big new version of Windows, or a major Service Pack – those days are gone. Instead, Windows 10 is more of OS platform that is ‘Windows as a Service’ – a continuously serviced, continuously improved, continuously enhanced operating system. And the UWP is the guaranteed API surface that you build apps against. It too is continuously enhanced and new versions will be released at regular intervals, but it has its own update cadence that is independent of the OS.
• #12: So, on top of the UWP, you build your universal Windows app. Unlike in Windows 8.1, where a universal 8.1 app creates separate binaries for PC and for Phone, with UWP it truly is a single app package that can run on any UWP device. The runtime on each device family is able to run UWP apps whatever the device.
• #13: See demo notes on github
• #14: Windows 10 offers an unprecedented opportunity for developers: the same core operating system across all Windows 10 devices, a common app platform, a single dev center where the developer can manage their app submissions for all Windows 10 devices, and a single Windows Store for app deployment, including special access for Businesses and Education.
• #15: Let’s take a look again at the device families. As we said before, we are dividing Windows 10 into broad groupings of similar devices, called device families. And while all these device families offer a distinctive user experience to the end user, they all run the same app platform so you can create apps that run across a broad range of these device families. This commonality is a strength – but what we are *not* saying is that you have to create some kind of ‘lowest common denominator’ app that works adequately across devices. We want you to create apps that shine on each device and offer the best possible user experience to end-users of your app.
• #16: If you think about the primary user interface of each device family – the Windows shell – each device family offers its own user experience that is appropriate for that device. Each device family also has its own distinctive features that create a great user experience for users of that device. There are also a small number of APIs specific to each device family that you can call to create differentiating experiences on each device – we’ll come onto that in a short while.
• #17: But before talking about the device family specific APIs, let’s talk about adaptive UI – how you can create a great UI for your app that adapts to whichever screen size and orientation it is running on.
• #18: When you are thinking of adaptive design, you want to build your page layouts using responsive design techniques – so no fixed widths, but instead having content that flows and can automatically adjust to relatively minor changes, such as the difference I screen size between a 4.5” screen and a 5” screen. Many of the built-in controls have basic responsiveness built in. So they know when the user is using mouse & keyboard, and when they are using touch, and modify their layout accordingly, displaying larger hit areas for touch. But you will also need to adjust your page layouts for big changes, such as the difference in screen size between a phone and a PC. Here, features such as Visual States can be a great help. And you may also want to employ tailored design techniques, where instead of retaining the same basic page content and adjusting layout for different screens, you create a tailored experience that is more appropriate to the device and the way the user is likely to want to interact with it.
• #19: Here is an example of responsive design: On the large screen on the right, we take full advantage of the size of the window the app is running in, we lay out the control buttons in a line, and we place the thumbnail of the people making the call off to the right. On the small phone screen, it’s essentially the same, but the image is cropped, and the large red End Call button has been placed underneath the other buttons, while the thumbnail moves up the page to just above the call control buttons.
• #20: Adaptive controls are great, and responsive layout will get you a long way, but we know there will be cases where the app designer wants to do something more custom or more tailored than the adaptive controls will allow. This desire might be motivated by hardware differences. For example, an app that will run on an Xbox might want to create some customizations for navigation using a game controller. Or it might be motivated by screen size and usability. A designer might want to position a menu at the bottom of a phone screen to make it more usable with a single hand. For these cases, we enable developers to create what we call a tailored user experience. In this case, the code is the same, but the developer creates custom XAML to deliver the desired design on the right device or in the right set of conditions. Tailored design goes beyond Adaptive UX Developers can create custom experiences for certain devices The code is the same, but custom XAML can deliver the experience a developer wants
• #22: Adapting the UI to different screens is the major part of creating an app that works across different device families, but you may also want to call device family-specific APIs to create unique experiences on different devices. You can do this using something we call ‘Adaptive code’.
• #23: Although the majority of the APIs you need for a UWP app are in the common API set, we also make available device family-specific APIs. We release these as Platform Extension SDKs. You can add a reference to these extension SDKsin exactly the same way as any other reference library. Like the UWP itself, these extension SDKs are versioned and may be released and updated independently of the UWP and the OS.
• #24: The most important thing to realize about extension SDKs is that when you reference the extension SDK for a particular device family, you are not limiting the app to now be able to run only on that device family. When you package the app and distribute it, it can still run across a broad range of device families. There are ways of limiting distribution of your app during the app submission process to the Store, but adding a reference to an extension SDK is not a part of that process.
• #25: This diagram illustrates how it works: <Click> Each device family runs the same core OS <Click> Your app is built upon the UWP and that is common across all device families. <Click> When you add a reference to an extension SDK, you are making those APIs available to be called by your application code – but those APIs are only usable at runtime on the matching device family <Click> Although, when you add a reference to an extension SDK, the metadata for those APIs are loaded into your project, so the C# compiler and Visual Studio Intellisense works correctly when you reference those APIs during the app development process.
• #26: So, we’ve got these device family-specific APIs that your app code can use, but they are only usable at runtime on specific device families. How do we make sure these APIs are called only at the appropriate time? The answer is to ‘gate’ calls to any API in an extension SDK with runtime checks to verify that a particular API is available to use. You do this using methods of the Windows.Foundation.Metadata.ApiInformation API. The most common method to use is IsTypePresent() which is a runtime check that the named API is actually loaded and usable wherever the app happens to be running.
• #29: Visual Studio 2015 comes in a number of editions that serve the needs of different groups of developers. Visual Studio Enterprise with MSDN is an Enterprise grade solution with advanced capabilities for teams working on projects of any size or complexity, including advanced testing and DevOps. Visual Studio Professional with MSDN offers professional developer tools and services for individual developers or small teams. Visual Studio Community is a free, full-featured and extensible tool for developers building non-enterprise applications.
• #30: There is a different approach for development for Windows 10 devices. A developer license is no longer required for each device that you want to use to develop, install or test your app. You just enable a device once for these tasks from the settings for the device. That's it. No more renewing your developer licenses every 30 or 90 days! You can easily developer unlock any Windows 10 PC/laptop/tablet or Phone just by going to System Settings to allow you to deploy apps to the device directly from Visual Studio and carry out on-device debugging and testing, or just for sideloading apps that have not been certified by the Windows Store.
• #31: Where can you do development? Visual Studio 2015 and the Tools for Windows 10 can run on PCs running Windows 10, on PCs running Windows 8.1 and on Windows Server 2012 R2. To get the best developer experience including full availability of tooling features such as the visual designer, you should use a machine running Windows 10.
• #32: Finally, for any questions on how to build apps for Windows 10, and for access to the Dev Center, or to take part in the forums, go to our home on the web: dev.windows.com. Here you will find tutorials, samples, getting started guides and access to the full documentation. Everything you need to help you create great UWP apps for Windows 10!