Welcome to part 2 in this series on Windows 8 and the future of XAML. The goal of this series is to give you an overview of the Windows 8 platform and teach you how you will be building Metro style applications when Windows 8 will be released.
In the first of this series, we looked at the developer preview of Windows 8, mostly from an end-user perspective. While showing you the new version, along the way, I explained several concepts which are new in this upcoming version of Windows, such as tiles, Metro style apps, charms and many more. From this article onwards, I won’t be explaining these concepts, you can refer to the first part for an explanation (of course, when the concept wasn’t covered, we’ll look into it!).
More importantly, what will we be looking at in this part? In the first part, we saw that Metro style apps are built using the Windows Runtime (aka WinRT). One question that I had after watching the first sessions of the BUILD conference (www.buildwindows.com) was a very simple question: “What exactly is WinRT and how does it relate to .NET?”. On top of that, I wondered if I would have to learn a new language or be able to leverage my .NET/Silverlight knowledge. All valid questions that I reckon many people have today. In this (and the next) part of this series, I will dive into WinRT: we’ll start writing some code that will eventually lead us to writing our first Windows 8 Metro style app! Fasten your seatbelt; we are ready for take-off!
Hello World… sorry, WinRT
What exactly is Windows Runtime (WinRT)? Well, it can be described as a new programming model/framework that enables us to build Metro style apps using the language of our choice, be that a managed language (C# or VB.NET), C++ or JavaScript. It enables developers to build applications that heavily use functionality exposed by Windows, which was previously difficult to achieve. Below, you can once again see the Windows 8 diagram, shown at BUILD and discussed a lot since then. Note here that WinRT sits right on top of Windows as a thin layer, exposing functions of Windows. These functions can be used in Metro style apps from all languages. In this context, Microsoft speaks of a language projection, which makes it possible to use WinRT in a way that is native to the language. For .NET developers, using WinRT is very similar to writing .NET code. Concepts such as constructors, properties, async development and many more are exactly the same when writing Metro style apps based on WinRT. We’ll see that further in this article.
Note that XAML is the way to build up your UI when using either a managed language (C# or VB.NET) or C++. When choosing the JavaScript way, we can only use pure HTML/CSS, at this point, there’s no support for example to use something like Razor syntax.
WinRT exposes quite a lot of functions to Metro style apps. A lot of things that we are used to doing by writing some .NET code is now covered by WinRT. Things like IO, service access and even XAML itself has now become a part of WinRT. In quite a few places though, including in XAML, you won’t even notice that you aren’t writing .NET code (but again, more on this later in this articles). The following image shows the functions covered by WinRT (this image comes from slides shown at BUILD).
WinRT architecture
Take a look at the image below. This schema gives an overview of the architecture of WinRT; we explain the different parts next.
At the very base, we have Windows. Directly on top of Windows, we have the core building blocks of WinRT. As mentioned above, WinRT contains quite a few things we’ll discover later, such as XAML, pickers (FilePicker), IO and storage…
Windows Metadata
The Windows Metadata is depicted on the left in the picture above. Windows Metadata (aka WinMD) refers to metadata files, similar to metadata for assemblies we have in .NET (a self-describing assembly). In WinRT, WinMD is conceptually the same: it describes what a WinRT component can do. It’s different in that it’s a separate file (whereas in .NET, metadata is included in the assembly itself). WinMD files are present on every installation of Windows 8 and they form the base of IntelliSense when writing Metro style apps in Visual Studio.
To see the WinMD files, simply points your Windows Explorer to Windows –> System32 -> WinMetaData as shown below. Note that these *.winmd files only contain the metadata itself!
We can even open these files with ILDASM and browse the code inside. Below, I have opened the Windows.Storage.Pickers metadata file. We can see all the methods and much more supported by this component. As you can see, there’s a definite influence by .NET on the way WinRT was built.
The Windows namespace refers to the fact that all WinRT classes are under the Windows.* namespace.
Language projections
We have briefly touched already on the language projection. WinRT is written in native (C++) code. Being native, the WinRT APIs would normally have to be called using interop code (COM). Most developers don’t like to write COM code; luckily for us Microsoft understood this. They didn’t give us the native APIs to work with. No, instead, we get language projections. Basically such a projection enables us to use the native components in a way that’s natural and familiar for the language. Microsoft isn’t forcing us to learn a new language: they simply “project” WinRT in languages we already have and know today. We’ll see some code soon that proves this!
The Metro style apps we will write are built using WinRT components but using a managed language, C++ or JavaScript.
The runtime broker
Finally, the broker is responsible for checking if a Metro style app is declaring all its capabilities (such as accessing the Pictures library) and showing the user whether or not he/she permits this. We’ll see this broker further in this articles series again when we work with the webcam.
Being async
If you’ve watched some of the BUILD sessions online, you probably heard one of the speakers refer to the Windows 8 user experience being “Fast and Fluid”. Microsoft is clearly committed to performance with Windows 8. They want to user to have a responsive device, even on lower end devices. To achieve fast and fluid, we as developers need to break with a habit of the past: writing synchronous code and adopt the fact that we’ll have to focus on asynchronous code.
This “being async” is baked into the WinRT platform. Every call that takes longer than 50ms is by default now async. Previously in Silverlight, calls to a service were already asynchronous. That very concept is now applied on a much wider scale throughout Windows and WinRT. This results in writing async code when for example accessing the file system.
To anticipate on this, Microsoft introduced the “await” keyword in C#: this makes dealing with async calls in WinRT APIs much easier. Through the language projection, which makes WinRT feel familiar to the managed developer, we are able to use this keyword when writing Metro style apps. We’ll see in the code samples in the coming articles how this works.
What’s in WinRT
Now that we have a clearer understanding of WinRT, let’s take a look at what exactly there is available in WinRT. The following is a list of top-level namespaces in the WinRT API (developer preview):
- Windows.ApplicationModel
- Windows.Data
- Windows.Devices
- Windows.Foundation
- Windows.Globalization
- Windows.Graphics
- Windows.Management
- Windows.Media
- Windows.Networking
- Windows.Security
- Windows.Storage
- Windows.System
- Windows.UI[.Xaml]
- Windows.Web
A lot of things that were previously covered by .NET are now moved into WinRT. For these functionalities, you will be using WinRT APIs in your code. When writing XAML and you’re using a Button control, you are no longer using the System.Windows.Controls namespace and the Button class that’s part of it. Instead, you are using the Button class which is now living in the Windows.UI.Xaml namespace, courtesy of WinRT.
But what if you want to use something that’s part of .NET but isn’t covered in WinRT? Things like LINQ, threading… Aren’t they available anymore?
The answer is: probably yes. I say probably because of the following. Microsoft adds a so-called Windows 8 Tailored Profile of .NET. The following image tries to clarify this concept.
We have the huge .NET API. Silverlight’s API is a tailored profile. It’s basically a subset of .NET. The same goes for Windows Phone 7: it contains some APIs of the full .NET and some specific ones, not used in any other tailored profile.
For Windows 8, there’s also a tailored profile available.
In that tailored profile of Windows 8, the following APIs are available:
- System.Collections
- System.ComponentModel
- System.Diagnostics
- System.Dynamic
- System.Globalization
- System.IO
- System.Linq
- System.Net
- System.Numerics
- System.Reflection
- System.Resources
- System.Runtime
- System.Security
- System.ServiceModel
- System.Text
- System.Threading
- System.Xml
Although the list is quite long, the tailored profile is in fact quite small. It’s even smaller currently than the Windows Phone one. As Metro-style apps are focused on the consumer side of things, the enterprise level stuff is not covered. There’s no Console support, ASP.NET integration, Entity Framework support… Keep this in mind when thinking of your first Metro-style app!
Summary
In this article, we’ve now deeply covered technical concepts surrounding the development of WinRT, setting the stage for writing Metro-style apps. And that’s exactly what we’ll be doing in the next articles of this series. Stay tuned for part 3!
About Gill Cleeren
Gill Cleeren is Microsoft Regional Director (www.theregion.com), Silverlight MVP (former ASP.NET MVP) and Telerik MVP. He lives in Belgium where he works as .NET architect at Ordina (http://www.ordina.be/). Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium – Switzerland - Sweden, DevDays NL, NDC Oslo Norway, SQL Server Saturday Switserland, Spring Conference UK, Silverlight Roadshow in Sweden, Telerik RoadShow UK… He’s also the author of many articles in various developer magazines and for SilverlightShow.net and he organizes the yearly Community Day event in Belgium. He also leads Visug (www.visug.be), the largest .NET user group in Belgium. Gill recently published his first book: “Silverlight 4 Data and Services Cookbook” (Packt Publishing). His second book, Silverlight 5 Data and Services Cookbook will be released early 2012. You can find his blog at www.snowball.be.
Twitter: @gillcleeren