Converting XAML-Based Applications to Windows 8

The big news about Windows 8 is its new mode based on the Metro design language and UI paradigm. Metro apps are based on the new WinRT (Windows Runtime) and can be built in two distinct ways. One utilizes HTML5 and JavaScript, while the other uses XAML for the user interface definition and C#, Visual Basic, or native C++ as the language behind the scenes. Not surprisingly, the later has often been compared to other XAML-based setups, in particular Silverlight, but also WPF. After all, “XAML is XAML,” the reasoning goes, so it should not be difficult to move both WPF/Silverlight skills as well as actual applications into the new world of WinRT. But is that really so?

To find out, I decided to take a small, yet real-world application and move it from Silverlight to WinRT. Silverlight should theoretically be a close match for WinRT’s XAML, since the paradigms match relatively closely. Both environments are client-side environments that rely heavily on services to retrieve data. Both have limited access to local resources. WPF, on the other hand, follows a different model in allowing developers full-trust on the local machine, which means the entire .NET Framework (potentially even server-side components) could be used directly in WPF applications. This doesn’t mean that WPF’s XAML concepts should not map to WinRT, but Silverlight seemed to be a more promising first step. (I will, however, explore WPF to WinRT conversions further down below as well.)

Theoretic Compatibility

Before I dive into a concrete conversion example, let me spend a bit of time exploring what XAML compatibility really means. I find that a lot of people are confused by the fact that the XAML-label is attached to different technologies. XAML is used for WPF (its original use), but it is also used for Silverlight, Silverlight for Windows Phone, now WinRT, and even non-UI environments such as the Windows Workflow Foundation. Clearly, it is not possible to simply take something written in XAML and just move it from one environment to another and just expect it to work. For instance, if one was to take a random WPF window defined in XAML and try to run it as part of a Windows Phone application, the experiment is doomed to fail for certain (Windows Phone doesn’t use the concept of “windows”), despite the fact that both environments use XAML. Nevertheless, people - especially managers and decision makers with little exposure to the “nitty gritty” - are often lured into ill-advised decisions by an incorrectly conceived belief that “since it is XAML is must be pretty close.” I have even seen people getting confused by the wide range of XAML capabilities within a single environment. Once company I worked with had graphics designers use XAML to define vector images that looked like user interfaces thinking they were building something that would result in working applications. It proved to be a very expensive mistake.

So what is XAML really? Many people would be surprised to learn that XAML is NOT a user interface definition language. XAML is simply an object instantiation language that happens to be very useful for user interfaces. Consider the following simple XAML example:

This is a relatively trivial XAML example that defines a WPF window with textbox and button controls. Anyone familiar with WPF would have little difficulty identifying this code segment as a XAML snippet and the individual XML tags as valid “XAML tags.” But what does that mean exactly? Does XAML really understand what a <Window> tag or a <Button> tag means? The answer is “no!” XAML, in fact, has no clue what these specific tags mean. XAML only knows that these tags refer to class names that have to exist in the utilized UI framework (WPF in this case). These class names are part of the WPF namespaces in the .NET Framework. This is identified by the definition of the root namespace:

This “magic” namespace tells the XAML compiler that we intend to use a list of .NET Framework namespaces that are known to make up the WPF sub-system of the framework. (Note that the namespace even refers to WinFX, which was what Microsoft originally called components in the .NET Framework that were going to make up WPF and other things that were intended to be shipped with Windows Vista only but also ended up on Windows XP later. Some may find an interesting parallel here with what is now happening with WinRT.)

While the default namespace declaration was originally intended to map to a set of WPF namespaces in the .NET Framework, the same namespace URI was later also used in Silverlight XAML UIs as well as WinRT XAML, even though Silverlight and WinRT actually use different framework namespaces in their respective UI frameworks. Somehow, as a result of all of this, the WinFX moniker has thus made it into all kinds of XAML dialects. This may be slightly odd, but it helps compatibility somewhat, as XAML files aren’t automatically invalid in other XAML environments, just due to the namespace declaration (although they might be for lots of other reasons).

You can also introduce your own namespaces here. For instance, if you were to create a namespace called “Test” and added a special sub-class of a button object called MyButton, you could use it like so:

Again, XAML has no idea what <test:MyButton> really is, but it knows that it is supposed to be a class name which can be found based on the “test” namespace declaration. XAML can thus go out and try to find that class, and if it indeed finds it, create an instance of it and put it into your user interface.

This even works for non-UI elements. For instance, it would be perfectly fine to instantiate a “Customer” business object using the following XAML:

This may not be a code example most XAML developers would recognize but it is still perfectly fine XAML. In fact, this XAML snippet doesn’t use any of the WPF (or Silverlight) classes, so the definition of the standard namespace is completely superficial here. You can eliminate it entirely and instead use your own namespace as the default namespace and thus re-write this example in the following fashion:

We have now arrived at a point where most people would probably fail to identify this code snippet as XAML, but it in fact still is.

So why am I telling you all of this? Because it makes an important point: Whether something is written in XAML or not is relatively meaningless for compatibility. The fact that WPF, Silverlight, Silverlight for Windows Phone, and WinRT all use XAML doesn’t tell you anything at all about whether or not you’ll be able to achieve any degree of reuse. Instead, it is all about class and framework compatibility. You shouldn’t ask whether different systems all use XAML, but you should ask whether they use the same classes and whether those classes are compatible and if so to what degree.

Will my original code snippet with the window, textbox, and button run in Silverlight or on the Windows Phone or in WinRT? It depends on whether or not these controls are available on those systems. (Hint: Some of them are not.) Will my customer object just work out of the box on WinRT? Well, certainly not unless I program such as an object for that environment.

By: Markus Egger

Markus is the founder and publisher of CODE Magazine and EPS' President and Chief Software Architect. He is also a Microsoft RD (Regional Director) and the one of the longest (if not THE longest) running Microsoft MVPs (Most Valuable Professionals). Markus is also a renowned speaker and author.

Markus' spends most of his time writing production code. The projects Markus has worked on include efforts for some of the world's largest companies including many Fortune 500 companies. Markus has also worked as a contractor for Microsoft (including the Visual Studio team). Markus has presented at many industry events, ranging from local user groups to major events such as MS TechEd. Markus' written work has been published extensively and in magazine ranging from MSDN Magazine, to Visual Studio Magazine, and of course in Markus' own CODE Magazine and much more. Markus is a supporter of communities in North America, Europe, and sometimes even beyond.

Markus currently focuses on development in .NET (Windows, Web, Windows Phone, and WinRT) as well as Android and iOS. He is passionate about overall application architecture, SOA, user interfaces and general development productivity and building maintainable and reusable systems.

In his spare time, Markus is an avid windsurfer, scuba diver, ice hockey player and world traveler. On a rainy day, he is known to enjoy a good game on his PC or Xbox.

megger@eps-software.com

Supporting the WinRT Paradigm

Creating applications (or apps) for WinRT in Windows 8 is more involved than simply making your code work and run properly. One of the biggest changes is in supporting WinRT-specific paradigms. For instance, Windows 8 supports charms such as a charm for sharing information or a Search charm. This means that rather than implementing a search feature natively in an application, the app’s search feature should integrate directly with OS-level search. Another example is the use of toolbars, which should instead be replaced by an app-bar. You should probably also support Live Tiles that are more than just a static link to your application.