I finally managed to wrap-up my AU material over the weekend. Here’s the first part of the handout for my Windows 8-related session (if you log in with your AU account, you’ll be able to access the accompanying presentation and sample project).
This is an “intermediate” class (rather than “advanced”), so at times it may seem fairly high-level. That said, if anyone sees issues with the material – especially important topics that have been glossed over – please do let me know: I’d be happy to make corrections (especially in advance of the class being delivered :-).
Introduction
Windows 8 has recently been released to a great deal of interest around the globe. It has been branded – and this is in some ways backed up by the $1.5+ billion marketing spend around the launch – as the most ambitious release of Windows ever. It certainly presents a very different UI paradigm to its users – something for which Microsoft has been both praised and criticized, inevitably – while also maintaining a strong focus on running legacy (now termed “desktop”) applications
Let’s start by taking a look at the Windows 8 Start screen:
The screen contains colourful – and actually very informative – tiles that are clearly targeted at touch-centric, mobile devices.
Devices that specifically target the Windows RT sub-system will run on both traditional Windows 8 machines (with Intel processors, which means they can run WinRT apps as well as traditional desktop apps such as AutoCAD) and on the new ARM-based devices such as the Microsoft Surface tablet and Windows Phone 8 handsets.
In this class, we’re going to spend some time looking at Windows 8 – and specifically WinRT – as well as the development challenges and opportunities it presents.
Windows Runtime – The New Sandbox on the Block
Windows Runtime – which as we’ve already seen is commonly abbreviated to WinRT – is Microsoft’s answer to Android and iOS: two application sandboxes that have had explosive growth over the last few years. Windows has its own, highly popular application execution environment – the .NET Framework – but it seems the belief within at least some divisions at Redmond was that this was not the appropriate model for working with next-generation mobile devices. Attempts have been made in the past to use a subset (which typically means a separate, streamlined version) of the .NET Framework in this way (such as the .NET Compact Framework and Microsoft Silverlight), but for better or worse WinRT is Microsoft’s latest attempt at addressing this particular market need.
WinRT is a complete layer on top of the core services belonging to the Windows OS. While with .NET it has often been needed to use the Platform Invoke capability to call through to the underlying Win32 API, with WinRT this is no longer needed or even allowed (at least not if you want to make your application available via the Windows Store).
So what does it mean, this idea of a sandbox? It’s basically a controlled execution environment for software: one that only provides a restricted subset of OS capabilities to applications. By not providing “risky” capabilities, sandboxes allow untrusted code to be executed in a controlled way: the ability to access certain resources – such as a user’s documents – must be specifically requested by the app, which get transferred to privileges that must be granted specifically by the user.
Aside from providing a much more secure and trustworthy environment for applications to execute, WinRT also provides the ability for code to be written in a variety of languages. We’ll look at that in more detail shortly.
WinRT – How it looks different
The first thing that strikes you when you see Windows 8 is that it looks very different. As mentioned earlier, the Start screen presents some highly colourful tiles to the user, some of which are “live” and present information deemed important by the apps to whom they belong.
The original name for the design language used for Windows 8 – as well as Zune, Xbox and Windows Phone – was Metro. In fact that’s the reason this class is named as it is. A few months ago, however, Microsoft stated the name had actually been a codename and went through a significant re-branding exercise (as despite being a codename, the Metro moniker had proved popular and was used fairly pervasively to describe the design language and the apps that make use of it). It’s believed this change of approach was driven by legal action from Metro AG, but that’s not really important for us to focus on.
Microsoft adopted the term “modern UI style apps” before finally settling – fairly recently – on the term “Windows Store” apps. Whenever you see the title of this class – which has clearly now been set in fairly strong concrete – please translate it automatically to “Developing a simple Windows Store application for Windows 8”.
Windows Store apps are full-screen, chromeless and are clearly targeted at touch-centric devices (although it’s always possible to use them on devices that are not touch-capable).
There were various influences that drove the look of what was formerly known as “Metro”. While not a core part of this class, it’s interest to note them:
- Bauhaus: http://en.wikipedia.org/wiki/Bauhaus
- Swiss typography: http://en.wikipedia.org/wiki/International_Typographic_Style
- Motion design: http://en.wikipedia.org/wiki/Motion_graphic_design
In addition to these inspirations, the “Metro” design language is founded on some core principles:
- Pride in craftsmanship
- Fast and fluid
- Authentically digital
- Do more with less
- Win as one
One point that’s worth calling out specifically is “authentically digital”: while iOS has (at least until now) taken a firm position in favour of skeuomorphism (in this context the act of imitating the real world in the digital one), Microsoft has chosen another path, avoiding the temptation of making digital imitations of real-world objects such as bookshelves. The message here is: don’t be afraid of digital versions being different, as those differences are also what make them valuable.
For more detailed information on these topics, I recommend these two presentations (the second of which was the source of the included images, many thanks to Laurent Bugnion).
WinRT – How it is different
The programming model and the tools you need to use to make use of it are – on the one hand – familiar to .NET developers, but there are significant differences. There’s a lot to learn with WinRT.
Here are four main areas of difference, that we’ll cover in some detail:
- Different object model for OS capabilities
- Asynchronous operation enforced for anything but “instant” responses
- Strict control over disk access
- Application interop only via contracts or file associations
The WinRT Object Model
When you first start working with WinRT from C#, there’s a great deal that’s familiar (especially if you’ve been working either with WPF or with Silverlight). There is a relationship with .NET, but it’s not actually the central mechanism that’s used to connect with the core OS layer. This happens to be COM – somewhat curiously for those of us that have been happy to distance ourselves from using this technology over the .NET years – but that’s really an implementation detail: you’re unlikely to have to get down and dirty with IUnknown (unless you really want to, of course).
WinRT and the CLR have distinct type systems that are effectively merged by the WinRT metadata adapter. At times it will seem a little strange to be working with the different types in the same application: for instance, some events are exposed via the CLR while others come from WinRT. You may notice the difference from the names (and types) of the arguments that are assigned automatically, but mostly these differences don’t get in the way at all.
When using C# or VB – and, inevitably, XAML for the UI – you’ll be targeting a particular .NET Framework profile (the .NETCore implementation). This provides access to the approved subset of the CLR for use with WinRT. At runtime, the full CLR is actually loaded and theoretically available to applications but the reality is that an application won’t be able to make use of it: while it’s possible for developers to hack their way beyond this approved subset of the Windows API, the Windows Store vetting process will exclude any apps submitted for posting that use techniques such as Platform Invoke or network loopback to play outside of the sandbox.
Asynchronous operations are now the norm
.NET developers have been playing with the async capabilities released in .NET 4.5 for some time, but with WinRT this mechanism takes on a whole new significance: any operations that could in theory take more than 50ms to complete are only made available via asynchronous API calls.
The intention is clearly to stop long-running API calls from blocking the UI thread and resulting in apps “whiting out”. Asynchronous calls help keep the Windows 8 UI responsive and fluid.
And the good news is that the async and await keywords make this really easy to deal with from your code, for instance:
var file =
await KnownFolders.DocumentsLibrary.GetFileAsync("file.txt");
In this situation, the await keyword tells the compiler to create an event that gets fired to continue execution of the application’s code once the results of the GetFileAsync() call are returned. The pain previously associated with performing operations asynchronously is now thankfully abstracted away by the compiler.
Restricted access to the file system
Applications making use of the WinRT object model no longer have arbitrary access to the file system. This is clearly intended to make applications more easily trusted by their users.
There are a relatively small number of locations that applications can request access to – they need to do so by modifying the Package.appmanifest to add “Capabilities”. Applications can – for instance – use this mechanism to request read/write access to the current user’s Documents, Pictures, Videos and to Removable Storage devices.
In addition to asking for access to files in this very restricted set of locations, applications also need to register themselves as associated with the types of the files they wish to access.
All these permissions get presented to the user when installing the app – and via the application’s Settings information – to make it very clear the type of information the app intends to access.
When an app asks the user to select a particular file from the system more freedom is granted to the app: it is effectively implied by the selection that the app is being granted permission to work with a particular file.
Application interop
Applications have very limited abilities to interoperate in the WinRT world: even if the system’s underpinnings are COM – a mechanism that was intended to facilitate the passing of information between software components – WinRT has been deliberately limited in this very important respect. This imposes good behavior on app developers, but many will find it restrictive: there will certainly be times when apps want to pass information between each other without it being a user-initiated operation. But for the good of the user experience, this is the choice that has been made by the implementers of WinRT.
As mentioned previously, access to the file system has been deliberately limited, but it is still possible to use it to share data at a user level. The Registry, on the other hand, is not accessible from WinRT apps, and so can no longer be used to pass information between applications.
There was a brief reference to “network loopback” in a previous section: this is the act of hosting a lightweight internet server on the local host (127.0.0.1) and using that from another WinRT app to exchange information. This is a fairly common interop technique, but this capability has been at least partially blocked for apps. And those that do manage to implement this technique will not make it through the Windows Store vetting process.
So what options do apps have for sharing information?
There’s one very specific “contract” (which is basically a protocol that needs to be implemented and registered with the framework) that apps can implement in order to share information at the request of the user (the user can choose to pass data from one application to another via the Share charm). It’s in this way that apps can have user-initiated interop – such as a user choosing to share a photo with the Mail app.
It’s also possible for WinRT apps to launch a desktop app that has been associated with a particular file-type. We’ll see this later on, where we choose to launch AutoCAD from our companion app to load a particular DWG file.
Some additional points about WinRT apps
The WinRT sub-system – while it runs on a traditional Windows 8 PC – is really intended for lightweight, touch-centric apps that will be run on a mobile device of some kind. WinRT apps are 32-bit only and are also not expected to consume significant quantities of memory: any that do will be jumped on by the WinRT runtime.
In fact the runtime is being left to manage application memory on a fairly general basis: apps typically don’t have explicit close or exit buttons (although you could, of course, choose to implement one) as the runtime is expected to terminate and resurrect apps as it needs to. It is possible to close applications via the task manager – or to get the app list on the left, which in recent versions of the OS provides a close option for each – but the expectation is that most users will not want to prune the list of running apps manually.
It’s generally not anticipated that software products such as AutoCAD will get ported to the WinRT sub-system: Microsoft doesn’t expect that heavyweight apps will get ported to WinRT. That’s not to say that it’ll never happen – or that AutoCAD components such as RealDWG will never be made available for WinRT – but there are significant architectural questions to resolve beforehand. For instance, with restricted file system access, how would AutoCAD handle accessing and loading support files or external references?
So it’s clear that we’re not going to be talking about writing an AutoCAD-hosted WinRT app in this session – because without WinRT-based AutoCAD, there is no WinRT API for it. Let’s then take a look at what application possibilities there might be, especially considering that application interop is so limited between WinRT and desktop apps.
In the next part, we’ll take a look at the opportunities for Windows Store apps to complement desktop software such as AutoCAD.
Update:
I found this article an interesting read, today: it ties the vision around WinRT together with the subject of my other AU session, moving desktop functionality to the cloud via Windows Azure.
