In a previous post, we learnt how the {x:Static} markup extension could help us remove magic strings and numbers in XAML. This was a great first step in avoiding code duplication. However the resulting XAML was still very verbose and redundant. As a reminder, we ended up with the following markup in our page:

<ContentPage ...xmlns:local="clr-namespace:MyApp;assembly=MyApp" ...>
    <StackLayout> 
        <Label TextColor="{x:Static local:AppConstants.BackColor}" FontSize="{x:Static local:AppConstants.FontSize}" ... />
        <Button BackgroundColor="{x:Static local:AppConstants.BackColor}" FontSize="{x:Static local:AppConstants.FontSize}"... /> 
        <Button BackgroundColor="{x:Static local:AppConstants.BackColor}" FontSize="{x:Static local:AppConstants.FontSize}" ... />
        ...
    </StackLayout>
</ContentPage>    

We can improve that XAML code significantly by using two fundamental concepts in XAML UI design: Resources and Styles.

Resources

Here is how the Resources can be defined in our page.

    
<ContentPage>
    <ContentPage.Resources>
      <ResourceDictionary>
        <Color x:Key="backColor">red</Color>
        <x:Double x:Key="fontSize">12</x:Double>
      </ResourceDictionary>
    </ContentPage.Resources>
    ...
</ContentPage>

For each UI property that we want to share in our page, we define a new entry in the ResouceDictionary. These entries can then be referenced by key in the markup using the StaticReource markup extension.

    
<ContentPage>
    ...
    <StackLayout> 
        <Label TextColor="{StaticResource backColor}" FontSize="{StaticResource fontSize}" ... />
        <Button BackgroundColor="{StaticResource backColor}" FontSize="{StaticResource fontSize}"... /> 
        <Button BackgroundColor="{StaticResource backColor}" FontSize="{StaticResource fontSize}" ... />
        ...
    </StackLayout>
</ContentPage>    

A few remarks on StaticResource:

An alternative to the StaticResource markup extension is to use the DynamicResource markup extension which:

There is not much evidence as to performance gain when using StaticResources vs DynamicResources. If you do not expect the resource to change at run time, simply use StaticResources.

Back to our XAML. It’s debatable at that stage whether the code has improved compared to our previous version:

  1. We now have our magic strings and constant back in XAML. There is no way (that I know of) to reference a static property from the ResourceDictionary in XAML. This could be done via code however, if the ResouceDictionary was created programmatically. The problem with this latter approach is that we would lose intellisense and refactoring support.
  2. The code is slightly shorter than before. But code duplication is still present as we need to set each property (BackgroundColor, FontSize) individually on each view.

In our next post, we’ll see how the usage of Styles, combines with Resources creates the perfect solution in our quest to simplify XAML and avoid code duplication.

Stay tuned!