Intro to Metro

Ten years after the release of the .NET Framework, Microsoft is stirring the pot again with a new development platform that set’s to focus your talents on what everyone is betting is the next big thing, mobile devices; specifically in this case, tablets. The Windows Runtime, or WinRT, is the foundation for the development of applications designed to target Windows 8-driven touch-enabled devices, but what does that mean for .NET developers and their existing skill sets?

The move from VB6, which was from where many of us came, to .NET, was pretty significant. For the first time, Microsoft-centric, non C++ developers saw true object orientation, and many other new concepts and features. Even IDE-related programming characteristics shifted considerably: code files independent of classes, many new project templates, and language independence (of course that started a whole new war, didn’t it). The move to WinRT and Metro applications will not be that drastic. Your skills as .NET developers, whether you’re a VB or C# programmer, will be far more leveraged than was the case a decade ago.

What Is Metro and WinRT?

WinRT is short for the Windows Runtime and it is the new generation runtime that will replace Win32. Metro is Microsoft’s new UX style for applications. For the most part, Metro is for a touch-enabled device such as a tablet or a phone. But this does not necessarily rule out the ability for a desktop app to be designed with Metro in mind. Metro apps are designed to be content-centric. This means that they are immersive and chromeless. The best definition I read once for an “immersive application” was an application that has the complete attention of the user. This means an application that is intuitive, attractive and requires very little or even no training in order to use quickly. The Metro UI achieves this through its concentration on content and easy navigation through the use of tiles as well as the lack of chrome. Chrome is all the additional UI doohickeys that go around your content or embedded within it. Chromeless is essentially the antithesis of the kinds of applications we’ve been designing for many years.

That is not to say that chrome made our older applications bad or ugly. Metro apps with their lack of window border, group frames, ribbons, toolbars, and conventional menus are merely different, and the user interface that they represent fits nicely into the hardware that they target. I’ve worked with and designed applications with ribbons, dockable tool windows, and MDI tabs that looked beautiful and were very intuitive. The style that many are calling legacy now, served very well for many years and will more than likely still have a place going forward for some time. Take any of the Office apps for example; the non-Metro look and feel works perfectly for them. In fact, I can’t honestly imagine how a Metro version of Word or Excel would look or behave.

I’m saying this because it is too often that I see developers embrace something new and automatically label the previous technology, design, or platform as bad and wrong. That is not the case with Metro apps and the next version of the .NET Framework (4.5) will keep and enforce the technologies we use today. And as you’ll soon learn, .NET is alive and well in Metro style apps themselves. Also, please note that Metro and Visual Studio 11 are still not in full release and we may still see changes down the line in both the style of the UI and the development environment.

The Metro Style Apps Development Environment

Developing Metro style apps will require Visual Studio 11 and Windows 8. As of the time of this writing, Microsoft has just released the Windows 8 Consumer Preview (Beta) as well as the Visual Studio 11 Beta.

Visual Studio 11’s New Project dialog is broken up into languages, similar to Visual Studio 2010, and under Visual Basic and Visual C# is a new project type called Windows Metro App. I will focus my attention on this project type in this article. Selecting “Windows Metro App” under either of these two languages will let you build a Metro style app using C# or VB in conjunction with the .NET API for Metro Apps. This API contains a set of managed types used for building Metro apps with XAML. So for you WPF or Silverlight developers (such as myself), your skills are far from lost and will be crucial going forward down this particular path. The .NET API for Metro style apps can be considered a subset of the whole .NET Framework but in fact, it’s a bit different. There are several differences in the API with that of the one exposed in the larger .NET Framework, particularly in the area of reflection. The .NET API for Metro style apps also serves as the abstraction layer between your code and the Windows Runtime (WinRT).

A new language node in the New Project dialog of Visual Studio 11 is JavaScript. You can also create Metro style apps using HTML5/CSS and JavaScript/jQuery. In this case you would be using the Windows Library for JavaScript. This is a JavaScript API that serves as the abstraction layer to WinRT. I won’t be covering this platform any further in this article.

I’ll select “Windows Metro Style” from the C# node in the New Project dialog. I’m now presented with the five new project types under this category (see Figure 1). The “Grid” and “Split” applications are there to help you get started on some of the more commonly used navigation styles of a Metro application. This will be more important than you might think because if your goal is to eventually place your application in the Windows Marketplace, it will undergo a scrutiny phase and adhering to certain common navigation and display styles will be crucial. Keep in mind, at the time of this writing, the marketplace is for tablet Metro apps, but soon it will be expanded to include apps for Windows Phone 8 as well.

The Class Library project is the typical assembly library that you would use to develop your components and down-level tiers in a Metro application. That’s not to say that you cannot interoperate with a conventional .NET 4.5 (or older) assembly. Referencing a non-Metro assembly is perfectly possible but you’ll have to use compiler directives to prohibit incompatible code-areas from compiling. I’ll make that the topic of another article; in this article I will stick to Metro-only projects to get you going quickly. For .NET developers like us, using the WinRT API will be nearly a no-brainer thanks to the way it integrates with .NET. In fact, thanks to the .NET APIs for WinRT, you probably will not even have an indication that you’re calling into WinRT.

For this article I’ll use the Blank Application project which will allow me to start from scratch and not be aided by any pre-built views.

By: Miguel Castro

Miguel is an architect with IDesign who specializes in architecture consulting and building .NET solutions. He is a Microsoft MVP and INETA speaker and has been a software developer for over 22 years. With a Microsoft background that goes all the way back to VB 1.0 (and QuickBasic in fact), Miguel jumped on .NET as soon as the first public Beta was released and has provided .NET solutions for clients around the country in a variety of industries. He considers himself to be a .NET Developer and Architect and has equal love for both VB and C#, and no tolerance for language bigotry. He’s spoken at numerous user groups around the country as well as developer conferences.

He’s the author of the CodeBreeze code-generator, which among things can be found on his Web site:

www.steelbluesolutions.com

Miguel currently lives in Lincoln Park, NJ with his wife Elena and his daughter Victoria.

subscriptions@infotekcg.com