• Uncategorized

Adventures in Windows 8: Writing WinRT Components

Earlier today, I opined the finer points of JavaScript/HTML development after earlier on the same day pointed out something that couldn’t be done in JavaScript and I added a WinRT component written in C#.

This is one of the best parts of Metro style app development: WinRT components.

Pay attention closely to this graph, it will come up again and again. In fact, you may want to save this image, print this out, and hang it up next to your computer.

It’s a great reminder of the versatility and ingenuity of the Windows 8 platform.

Plus, it’ll be handy to have when some chump tells you that “X is better than Y” for building Metro style apps or some such other nonsense.

The most importan Windows 8 poster ever!

I want you to notice a couple of this about this graph:

  1. There’s a dividing line between Metro style apps and Desktop Apps
  2. C, C++, C#, VB and JavaScript all have equal access to the underlying WinRT APIs
  3. XAML and HTML are both equal

There’s another important part of the equation here that’s not represented in the chart above: projection.

Projection (see below) has an almost magical way of letting WinRT components written in different languages talk to one another. You might even want to print out this chart, too.

Language projection

For another in-depth take on projection, read this blog post from DevExpress.

Creating a WinRT component is easy enough in Visual Studio 2012. From your Metro style app solution, just click on File > Add > New Project.


Then this dialog will come up. Be sure to click on Windows Metro Style under Visual C# (or whatever language you wish to work with), then click on Windows Runtime Component.

Name your component and then click OK.


The code I’m going to show here is the code I wrote to solve my little HTTP 302 redirect problem.

Some items are redacted to keep my super-secret project secret. 🙂

The first thing you’ll may notice is that the class is marked sealed.


Since I’m posting data to a web site and expecting a response, this means that I’ll need to use the new async model.

The new async model is epically awesome and deserves a post or two in its own right. If you can’t wait until I write out my own post on the subject, read this excellent post by the Windows team.

        public IAsyncOperation<string> GetAuthenticationHeader(string userName, string password)         {             return Task.Run<string>(async () =>             {                 var headerString = await SubmitLoginAsync(userName, password);                 return headerString;                          }).AsAsyncOperation();         } 

All the public methods in a WinRT component have to return common WinRT types. In this case, that means that Task<T> has to be cast or converted to IAsyncOperation<T>.

Fortunately, the AsAsyncOperation extension method does the conversion easily enough.

Private methods, unlike their public counterparts, can return and use any type they wish. It’s all running on a CLR (see above chart). Note, that I said “a” CLR, not “the” CLR.

Any method that uses the new await keyword has to mark the entire method with “async” and the return type has to be a Task<T>.

Here it’s Task<string>, since I’m returning a string.

        private async Task<string> SubmitLoginAsync(string userName, string password)         {             try             {                 var content = await DownloadPageAsync(userName, password);                  return content;             }             catch (HttpRequestException hre)             {                 return "error: " + hre.Message;             }             catch (Exception ex)             {                 return "error: " + ex.Message;             }          }

The await keyword will basically wait until the DownloadPageAsync returns with a value.

That means the “return content;” line will wait until the call to DownloadPageAsync call completes.

In the past, we’d have to write callbacks and delegate methods to do this sort of work asynchronously.

No matter how well you structure your code and stick to the principles of clean code, having more than two levels of callbacks made for messy code.

Now, writing asynchronous code is as easy and as readable as synchronous code.