Over a million developers have joined DZone.

Understanding XAML Syntax

DZone's Guide to

Understanding XAML Syntax

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

In yesterday’s blog post I was taking a first closer look at XAML. I’d like to continue at exactly the same point.

XAML is a programming language that is created in such a way that it is focused on defining the design or the layout for a Silverlight application. It is characterized by a series of opening and closing tags.

XAML-files are hierarchically structured.

Depending on their order, one or more elements can influence the layout and behavior of the interface. Each element has only one parent, but can have an unlimited number of children. Only for a few elements the amount of children is limited, e.g. the Scrollbar does not have a child. Typically in XAML applications the root object is a Panel, that is responsible for positioning and rendering. A Panel can contain other Panels.

Anything that is created or implemented in XAML can be expressed using a more traditional .NET language, such as C# or VisualBasic.NET. However, a key aspect of the technology is the reduced complexity needed for tools to process XAML, because it is based on XML. And because of that developers and designers are able to share and edit content freely amongst themselves without requiring compilation.

The key idea is that you want to use XAML to build the interface of your Silverlight Windows Phone 7 applications.

XAML is not exclusive to Silverlight, not even to defining a user interface. It can be used in other products as well.

If you’re a designer and you want to build a user interface for a Silverlight application you might want to use a different tool instead of Visual Studio to help you define the user interface, for example Expression Blend for Windows Phone 7. It contains additional XAML generating tools that are more focused on the user interface and the user experience than Visual Studio 2010 Express. This creates a nice separation between the work that a designer does and the work a developer will do.

So, let’s have a look at XAML. I’ve created a new project and dragged a button to my main form. I’ll have a look at what an empty XAML document looks like before I add any controls more than that one button:


        mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"
        FontFamily="{StaticResource PhoneFontFamilyNormal}"
        FontSize="{StaticResource PhoneFontSizeNormal}"
        Foreground="{StaticResource PhoneForegroundBrush}"
        SupportedOrientations="Portrait" Orientation="Portrait"

This is the beginning tag, and when I scroll down to the end, I see the ending tag:


Everything else will be contained within this PhoneApplicationPage. I can see “phone:” right in the beginning. That means, my PhoneApplicationPage belongs to a namespace that’s been aliased by this “phone:” If I look through the code I see that in line 5 it’ll be defined what that namespace shortcut really is. The xml namespace “phone” is really from the clr-namespace Microsoft.Phone.Controls and is contained within a file, an assembly, called the Microsoft.Phone.dll.

So in XAML, whenever there is a word followed by a colon, that’s defining namespaces. Quite similar to how namespaces are defined in a using statement in C#.

Next in my XAML I have my layout defined:

<!–LayoutRoot is the root grid where all page content is placed–>
<Grid x:Name="LayoutRoot" Background="Transparent">
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="*"/>
    <!–TitlePanel contains the name of the application and page title–>
    <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
        <TextBlock x:Name="ApplicationTitle" Text="MY APPLICATION" Style="{StaticResource PhoneTextNormalStyle}"/>
        <TextBlock x:Name="PageTitle" Text="page name" Margin="9,-7,0,0" Style="{StaticResource PhoneTextTitle1Style}"/>
    <!–ContentPanel – place additional content here–>
    <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
        <Button Content="Button"
                Width="160" />

Using Grids and Panels is the main technique for positioning controls and text on a Windows Phone 7 Silverlight application.

This block  contains the layout definition, the StackPanel (which is another layout control) and controls, in my case just the button.

This root Grid contains a StackPanel, but also a ContentPanel.

This particular StackPanel contains the application name and the page name in textblocks. I could change the names directly in that block of XAML code instead of changing the content in the properties window.

The ContentPanel is basically where the body of an application lives.

Below that there is a big commented out section:

    <!–Sample code showing usage of ApplicationBar–>
        <shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">
            <shell:ApplicationBarIconButton IconUri="/Images/appbar_button1.png" Text="Button 1"/>
            <shell:ApplicationBarIconButton IconUri="/Images/appbar_button2.png" Text="Button 2"/>
                <shell:ApplicationBarMenuItem Text="MenuItem 1"/>
                <shell:ApplicationBarMenuItem Text="MenuItem 2"/>

This gives a nice little template for adding an ApplicationBar. Of course I can use my own icons, write my own code.

For now there’s only one thing left to mention. Both the MainPage.xaml file and the MainPage.xaml.cs file are two parts of a whole. In other words, the work I do in the XAML file and the work I do In the C# file are compiled. They are built by the compiler into a single class that defines both the appearance and the behavior of the MainPage in my application.

One more look to my C# file:

    public partial class MainPage : PhoneApplicationPage

“partial” means, that part of this class is defined in C#, and part of it in XAML.


To be continued…

Source:  http://andreahaubner.blog.com/2011/02/19/understanding-the-xaml-syntax/

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}