2007 / December 28^th/ An Overview of XAML

A little while ago I talked about how I was starting to get into Windows Presentation Framework (WPF) development. It’s now been a couple of months diving head first into WPF and I feel like I’ve got a good view of technology — so I thought I might weigh in on the fundemental building blocks of WPF: XAML.

WPF Recap

Windows Presentation Framework is Microsoft’s answer to developing Windows applications. It’s Microsoft scrapping everything it once knew about Windows application (front-end) development and creating a whole new set of tools, languages, and paradigms for creating interfaces.

Overview

The most heavily boasted feature of WPF has been its use of XAML (eXtensible Application Markup Language) for creating interfaces. XAML is a declarative XML language for instantiating interface objects. XAML is extremely reminiscent of HTML, although it is much, much, much more powerful. Here is a sample XAML file and the resulting application:

<Window x:Class="OfferBrowser.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="OfferBrowser" Height="300" Width="300"
    >
    <StackPanel HorizontalAlignment="Center" VerticalAlignment="Center">
        <TextBlock Text="Building applications in WPF is suprisingly simple now." HorizontalAlignment="Center" />
        <Button>Sure is!</Button>
    </StackPanel>
</Window>

XAML is immediately relevant for three reasons:

1. XAML at once makes advanced OO concepts accessible to web developers through an XML-flavored language that they can understand.
2. XAML makes for much faster application interface development.
3. XAML makes for drastically more readable code: you can look at a XAML document and have an understanding for the look-and-feel of the application.

More than interface: Vectors

In addition to laying out interface elements like <Button />s, XAML can be used to describe complex vector objects. Let’s say you wanted to lay out a nice vector star in XAML. You might have a piece of code that looks like this:

<Path
    Height="14.682"
    Width="15.437"
    Stretch="Fill"
    Data="M 61.3431396484375,0 C61.3431396484375,0 80.2991943359375,38.40919494628906 80.2991943359375,38.40919494628906 80.2991943359375,38.40919494628906 122.686279296875,44.56840515136719 122.686279296875,44.56840515136719 122.686279296875,44.56840515136719 92.01470947265625,74.46580505371094 92.01470947265625,74.46580505371094 92.01470947265625,74.46580505371094 99.25527954101562,116.68159484863281 99.25527954101562,116.68159484863281 99.25527954101562,116.68159484863281 61.3431396484375,96.75 61.3431396484375,96.75 61.3431396484375,96.75 23.430999755859375,116.68159484863281 23.430999755859375,116.68159484863281 23.430999755859375,116.68159484863281 30.67156982421875,74.46580505371094 30.67156982421875,74.46580505371094 30.67156982421875,74.46580505371094 0,44.56840515136719 0,44.56840515136719 0,44.56840515136719 42.3870849609375,38.40919494628906 42.3870849609375,38.40919494628906 42.3870849609375,38.40919494628906 61.3431396484375,0 61.3431396484375,0 z"
    Fill="#FFFFFFFF" Stroke="#FF000000" />

The numbers in the Data attribute are nonsense upon first glance: but you shouldn’t ever have to deal with that particular aspect. There are XAML exporters for nearly every professional vector graphics tool: Adobe Illustrator, Adobe Fireworks, Microsoft Expression Design, etc. The huge win here is that you can interact with design elements as you would interface elements. Instead of going through hoops to make a button display like a vector drawing, you can simply export the exact vector object and use it inside of a <Button>.

In fact, if we take the above <Path /> object and substitute it for the “Sure is!” text inside the <Button /> above, we get the following result:

This interface element will scale without any work since it is a vector object. If you increase the size of the Path or the Button, your star will scale along with it. This is a pretty big concept since integrating your design elements with your interface elements effectively destroys the barrier to resolution-independent application development.

More than interface: 3D Objects

In addition to supporting 2D vector objects, XAML has the capability to represent 3D models in XAML. We’re talking full-blown 3D models extracted from your favorite 3D modeling application.

Fairytales of separation of functionality from interface

In Microsoft’s fairytale land, XAML is the answer to this thing that started with the whole codebehind concept so many years ago: the separation of functionality from interface. To web developers who are used to this strict separation with XHTML, CSS, and Javascript: the concept is at once understood. The idea is that the interface can be developed independently of the functionality of an application. Designers can write XAML to their heart’s content while programmers work on the back-end files.

This is nice in theory: but breaks down during implementation. During the project I was working on, the XAML file I was working on with one other engineer encountered ten subversion conflicts in a total of 11 checkins over the course of one day. That is proof enough to me that the format and syntax of the XAML files is inherently tied to the codebehind partial class, and any supporting libraries it may depend on.

Insult is added to injury from the fact that if an application will not build, you cannot see the interface. The previewing functionality in Visual Studio and Expression Blend is amateur at best, and when there is any error in any supporting library, you simply can’t launch the application. This means all interface development comes to a halt until the back-end programmers are given time to fix it. This makes complete sense from an application development standpoint, but zero sense to interface designers.

Conclusion

XAML is a huge step forward in application development. XML-based declarative languages like XAML and MXML are clearly the way that rich interface development is heading. Soon enough, anyone who chooses to tout themselves as a front-end developer will need to become with this method of programming (it is a new paradigm to understand). It’s fair to note that XAML is the same language used for Microsoft’s Silverlight platform as well. While there are still clearly some pain points between separation of functionality and structure, all in all: XAML is a good first-stab that solves many problems: resolution independent applications, integrating artwork, cleaning up code bases, and making application interface accessible to a broad range of developers.

1. 

   Colin Devroe

   December 28^th | #

   Nice overview. Sometimes it is good to see some development notes from “the other side of the fence” that I jumped over so long ago now.

   Thanks.

2. 

   Kyle

   December 29^th | #

   Well, in many ways I’ve jumped over as well :) But what fills the bank account…

   In any case, even for non-windows developers I really do think that XAML/WPF is very relevant. It’s my hope that Cocoa adopts a similar technology and makes interface design as accessible as windows has. If not for how bad Vista was, I really do think WPF could have turned around windows app development…. oh well.

3. 

   Michael

   December 31^st | #

   I may be missing some critical point here, or I may just be ignorant of windows development (even though I studied it in college), but does windows dev really need to be “turned around” and is this really going to be a stepping stone for it?

   Again, I may just be speaking out of ignorance here, but isn’t it easy enough to start laying out your app in Visual Studio and then position things programatically for precision as needed? How is writing an xml-style file for appearance going to help much when so many programmers are proficient enough without it? I can understand the idea of abstracting the design from the logic a bit, but as you stated yourself it’s more academic in windows dev than practical at this point.

   I and a lot of other developers find app layout a menial task at best that can be suitably done visually. I know that this is a far cry from web dev where we do all layouts manually to get the best results, but why bother in windows dev?

   Just a few thoughts… :)

4. 

   Kyle

   January 1^st | #

   Michael: Saying that you can just “lay out your app in Visual Studio” is akin to saying that all websites could just be laid out in Dreamweaver WYSIWYG view and be done with it. Visual studio is fine for maybe a dialog box, or a form page that’s ugly as sin.

   But we’re talking about a whole new breed of apps. Check out some of the samples from Thirteen23 to get a small taste of the flexibility WPF offers. WPF/XAML more or less opens up windows dev to designers.

   Opening up a dev technology to designers is huge.

5. 

   Hüseyin

   January 9^th | #

   You haven’t mentioned about the performance of WPF apps, what about that one? I have seen comments that WPF doesn’t work well on old machines and this can prevent it being mainstream. What are your opinions?

6. 

   Kyle

   January 9^th | #

   Hüseyin: From my experience, I would suggest you only develop WPF apps for Vista-forward machines if for no other reason than they require .NET 3.0, which is around 200MB download if I recall. Performance isn’t so much of an issue as the aesthetics (default button styles for example), and frameworks needed.

7. 

   Jeff Yamada

   January 20 | #

   I’m curious about comparing this with Flex2/3. I’ve dabbled momentarily with Blend but haven’t had the time to really dig in. I’m curious if you have an opinion on this comparison. One thing I noticed last I was looking into WPF and Blend was the lack of cross platform support. Has this changed? Can WPF really compete without this vital feature?

8. 

   Jeff Yamada

   January 20 | #

   Oops, neglected to read the comments directly above. Still, can WPF compete w/ Flex in this respect?

Name

Email (will not be published)

Website (optional)