This post is part of a series about creating Windows Store-apps with XAML and C#. Find the Content of the series here:
Windows Store-apps with XAML and C# blog-series
Last weekend I’ve finished the XAML-chapter of my upcoming book about developing Windows Store-apps with XAML and C#. I want to share the things that you should know about the WinRT XAML – the way I call it here - if you’re familiar with Silverlight or WPF.
The WinRT XAML is much like the XAML we know from Silverlight. But there are some differences in WinRT XAML:
- the way you use your custom namespaces is different
- there are some missing things (TypeConverters, Custom MarkupExtensions)
Let’s look at the two parts
Use custom namespaces
There are two ways in XAML to use a namespace:
- 1:1-Namespace-Mapping
- 1:n-Namespace-Mapping
Read the difference for both in Silverlight- and WinRT-XAML below.
The 1:1-Namespace-Mapping
Let’s assume you’ve the following class:
namespace UIRocker.Special
{
public class WindowsEight
{
public bool IsGreat { get; set; }
}
}
To use this class in
Silverlight-XAML, you’ve to add an Namespace-Mapping like this
xmlns:rocker="clr-namespace:UIRocker.Special"
or like this if the CLR-Namespace is in another assembly than the XAML-file containing the Namespace-Mapping below:
xmlns:rocker="clr-namespace:UIRocker.Special; assembly=UIRockerLib"
With the Namespace-Mapping the classes from that Namespaces can be used with the chosen alias. The alias is “rocker” in the snippets above, so the
WindowsEight-class can be used as below:
<rocker:WindowsEight IsGreat="True"/>
In
WinRT-XAML you’re using the class in the same way as above, but the way of creating the Namespace-Mapping is different. Instead of using the syntax with “clr-namespace…” you use:
xmlns:rocker="using:UIRocker.Special"
You don’t care if the Namespace
UIRocker.Special is in another assembly as the XAML-file or not. This works exactly the same way as the using-directive in C#, where you also don’t care if the Namespace is in another assembly than the .cs-File or not. So, great improvement, but creates a little incompability with Silverlight-XAML.
The 1:n-Namespace-Mapping with XmlnsDefinition-Attribute
The Namespace-Mappings above have been 1:1-Mappings. One XML-Namespace was mapped to one Silverlight/WinRT-Namespace.
In
Silverlight-XAML you can create a 1:n-Namespace-Mapping by placing the
XmlnsDefinitionAttribute (Namespace:
System.Windows.Markup) on your assemblies like this:
[assembly: XmlnsDefinition(
"http://thomasclaudiushuber.com/","UIRocker.Special")]
[assembly: XmlnsDefinition(
"http://thomasclaudiushuber.com/", "UIRocker.Mvvm")]
Classes out of the Namespaces
UIRocker.Special and
UIRocker.Mvvm can be used in XAML with one alias by making a 1:n-Namespace-Mapping like this:
xmlns:rocker="http://thomasclaudiushuber.com/"
Unfortunately in
WinRT-XAML there is no possibility for a 1:n-Mapping. The Namespace
Windows.UI.Xaml.Markup contains a
XmlnsDefinition, but it’s not an attribute, it’s a struct and therefore not usable.
Especially when you create a library with many Namespaces in it, it’s great to use just one alias for the library in XAML. Maybe the next Version of WinRT will contain such a mapping. By the way, first versions of Silverlight also didn’t support 1:n-Namespace-Mappings.
Missing things in WinRT-XAML
There are a few other things that are not in WinRT-XAML or behave differently. Let’s take a look at them.
Typeconverters
As XAML is XML, every Attribute contains a string-value. This string-value needs to be converted into the value of the property-type the attribute represents. For primitive types like double, float, int, bool, char etc., the conversion automatically is done by the XAML-Parser (Silverlight and WinRT). Also for Properties of type enum, the XAML-Parser tries to convert the specified string-value into the enum-type of the property. There is also a conversion for some central types hardcoded in the XAML-Parser of Silverlight and WinRT, e.g. the Brush-Type. This conversion allows you to assign a string in XAML where a Brush-Instance is required:
<ListBox Background="Red">
The XAML-Parser takes the “Red”-string, creates a
SolidColorBrush with the
Color Red and assigns it to the
Background-property of the
ListBox.
(Excourse to WPF-XAML: In WPF-XAML this conversion is not done by the XAML-Parser, it is done by the
BrushConverter-class)
Now if you have properties that are of your own type, let’s look at this works in Silverlight and WinRT. Let’s assume we have the classes below:
public class Person
{
public Address Address { get; set; }
}
public class Address
{
public string City { get; set; }
public string Country { get; set; }
}
In
Silverlight-XAML, it is possible to create a
Person-instance as below if a TypeConverter for the
Address-type exists:
<local:Person Address="Müllheim Germany"/>
The corresponding typeconverter could look like this:
public class AddressConverter : TypeConverter
{
public override bool CanConvertFrom(...Type sourceType)
{
if (sourceType == typeof(string))
return true;
return base.CanConvertFrom(context, sourceType);
}
public override object ConvertFrom(...object value)
{
if (value != null && value is string)
{
var array = value.ToString().Split(' ');
if (array.Length != 2)
throw new ArgumentOutOfRangeException(
"Invalid format for address");
return new Address
{
City = array[0],
Country = array[0]
};
}
return base.ConvertFrom(value);
}
}
The only thing that is additionally required is to tell the XAML-Parser where to find the
AddressConverter. You do this by specifying the
TypeConverterAttribute either on the
Address-Property in the
Person-class or on the
Address-class itself. Below an example that specifies it on the
Address-class.
public class Person
{
public Address Address { get; set; }
}
[TypeConverter(typeof(AddressConverter))]
public class Address
{
public string City { get; set; }
public string Country { get; set; }
}
So far to Silverlight-XAML, now let’s look at
WinRT-XAML. As mentioned above, WinRT-XAML also supports conversion for
- primitive Types like bool, char, double, int, float,…
- enumeration-values
- central types like e.g. the Brush-type.
If you’ve custom types like the Address-class, currently there’s no support. There’s no TypeConverter in WinRT. Dot.
Markup-Extensions
In Silverlight-XAML it’s possible to create custom subclasses from MarkupExtension and use them in XAML with curly braces. WinRT doesn’t support custom Markup-Extensions. Dot.
Did you find out other bigger differences about XAML?
See you next week with the next post about WinRT and Windows Store-apps.
Thomas
)