Development model. Part 5 of 9. Microsoft Build 2011 - Windows 8

Developing for Windows 8 is going to fall into two camps: the Metro apps and the desktop apps. The chart below breaks things down quite nicely.

On the desktop, it’s mostly business as usual. There’s a new version of .net that has some great new tricks, as well as all of the existing models and languages that we’ve used for years. In the Metro world though, things start to look different. The Windows Runtime (or WinRT) APIs are new native C++ libraries that surface access to the operating system resources. What’s interesting about these is that even though they’re native code (which means that they’re tuned for high performance), they project into C++, managed languages, and javascript, which means that all three language options are being treated as first class citizens. The APIs (from what I’ve seen so far anyway) have also had the luxury of being new, so calls are simpler than the comparable Win32 might have been.

Another interesting piece of this map is that XAML is the interface language of choice for everything but Javascript, which marks the first time that native developers have been able to create advanced UI with XAML. Note that this XAML is not necessarily WPF or Silverlight, but a new XAML parser that is extremely close to the Silverlight one. In fact, a great deal of Silverlight markup will supposedly make the upgrade to Metro smoothly, however the application that was demoed in the keynote was reasonably simple, so it will be interesting to try a more complicated one to see how the porting process goes. Another large question mark is the degree of .net support that exists in Metro. Leading up to Build, there was a lot of “.net is dead” speculation (along with “Silverlight is dead”, “COM is dead”, and “Win32 is dead”), which turned out to be largely untrue. .net 4.5 on the desktop is a new version of the framework that we’ve come to rely on, but in the Metro world several references were made to a “limited set” of .net being available. Without more research, it’s not immediately clear how limited this set is though-will it be the same as the .net 4 client profile, more inclusive, or less inclusive?

What we do know though is that .net 4.5 (in both the desktop and Metro) will be getting some fantastic new asynchronous programming features that, while they don’t really do anything that you couldn’t do before, make code a lot more readable. As an example, consider this method that calls a WCF service asynchronously:

This code works, and even uses a lambda expression to hook up the completion event to make the code slightly more readable. It’s actually worth noting that this example has a flaw in it where the event handler is never unhooked from the event, so calling this method a second time will call the completion code twice etc. It’s good enough for illustrating that the code gets complicated though, since it’s not immediately evident what the execution path is. Stepping through this, the first thing that gets run is actually the GetSessionUserAsync method, and then once that completes the lambda runs. Inside the lambda, the data we care about is wrapped in event arguments, which may also contain an invocation exception on the ea.Error property. This means multiple checks for return codes, plus any other cases where an exception could be thrown. Now compare this to the new .net 4.5 model:

Here, everything is wrapped in one try/catch block, and the code is readable from top to bottom, but the code will do exactly the same thing as the first sample. The method will still return immediately, but the C# compiler will automatically split the code following the await keyword into a new delegate. It also saves having to create new custom delegate and event argument types for every asynchronous method, and helps APIs make more sense by returning actual types. Another benefit of this scheme: the code after the await method runs on the UI thread, which also saves having to do an invoke on UI updates from background threads, which is another boilerplate code complication that becomes necessary in asynchronous GUI applications. Once you start extending this scheme with multiple await keywords, or with statements like awaitAll, it really starts to show its usefulness. Unfortunately, this feature isn’t available outside of the .net 4.5 preview, so today’s software still needs to do things the old way, but it’s a great feature to look forward to. Of course, this isn’t the only new .net 4.5 feature, but it’s probably the biggest impact change, and something that will prove essential for building both metro and desktop applications.

For more information on how development in Windows 8 works though, there are hundreds of session recordings on the build website to view and download, covering dozens of different topics.

Share

About the Author

Chris is the Chief Software Architect at ComputerTalk Technology, and has been writing code in one form or another since the mid 80s. He’s been working with Lync since it was called Live Communciations Server (back in 2004), and he’s been working with .NET since 2002. He’s a big fan of UCMA, WCF, and XAML, and knows enough about most of the Microsoft development technologies to be dangerous. He also collects pinball machines.

This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

About our blog

We are firm believers in Lync Unified Communications and the benefits it brings to the business communication world. We are excited to share some of the things we’ve learned about Lync development, custom Lync applications, and Lync issue resolutions.

The Blog Team consists of employees from different departments, so you will get different perspectives on various topics that are relevant in the Telecommunications industry.

Keep following us on FB, Twitter, LinkedIn, for on-the-go updates and keep sending us feedback and blog post suggestions.