Improve the performance of your apps with Compiled Bindings.

There are many ways to write an app and many patterns to follow. Some are very useful, others a bit less but there is one that you should always use MVVM, Model View View Model. It allows you to separate your apps in three main parts or layers:

Model: Your data

View: Your UI

View Model: Your logic

This pattern is brilliant so you should really use it. In it, your View knows nothing about the logic of your app and your ViewModel knows nothing about the UI, but they communicate through a mechanism called Data Binding.

<Label Text="{Binding MyTitle}"/>

In this quick example we have associated the text property of our Label to the property “MyTitle” in our ViewModel. Easy, isn’t it?


The problem

MVVM is great (and you should really use it) BUT the data binding has two big problems:

  • Because they are resolved at run-time, you have no validation at compile-time. It means that if in the previous example, instead of MyTitle you write MyTile, you code will compile fine and you will be able to run your app BUT you will not see the text in your label.
  • As we said, they are resolved at run-time through a mechanism called reflection. Reflection is cool but it has an high overhead cost, so every time you load a page with some bindings, your app will consume time.

The solution

Luckily there is a solution to enjoy MVVM and Data Binding, without having to worry about performances and the solution is Compiled Bindings.

To enable the Compiled Binding you have to do two quick steps:

  • Enable XAML compilation.
  • Set the correct x:DataType attributes.

It’s incredibly easy to do it an it’s easier to do that to explain so I’m going to show you how to do it with an example.


If you are starting a new Xamarin.Forms project, the template already has the XAML compilation enabled, but if you need to enable it you can add this attribute:

[XamlCompilation(XamlCompilationOptions.Compile)]

to your page class in your XAML code behind. So the class of your page will be similatr to this:

[XamlCompilation (XamlCompilationOptions.Compile)]
public class HomePage : ContentPage
{
    //Add your content here...
}

Very easy. Now let’s see how to set the correct x:DataType.

First of all, let’s say that our View is called MyExamplePage and our ViewModel is called MyExampleViewModel and that our page has a label with a binding:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:viewModels="clr-namespace:XamarinExpert.ViewModels;assembly=XamarinExpert"
             x:Class="XamarinExpert.Views.MyExamplePage">
    <ContentPage.BindingContext>
        <viewModels:MyExampleViewModel />
    </ContentPage.BindingContext>
    <ContentPage.Content>
        <StackLayout>
            <Label Text="{Binding MyTitle}"
                VerticalOptions="CenterAndExpand" 
                HorizontalOptions="CenterAndExpand" />
        </StackLayout>
    </ContentPage.Content>
</ContentPage>

This is a perfectly correct XAML and if we build and start it, it will run. If the property MyTitle exists in MyExampleViewModel, then we will be able to see the text.

Now let’s add the x:DataType  to enable the Compiled Data Binding. The code will be:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:viewModels="clr-namespace:XamarinExpert.ViewModels;assembly=XamarinExpert"
             x:DataType="viewModels:MyExampleViewModel"
             x:Class="XamarinExpert.Views.MyExamplePage">
    <ContentPage.BindingContext>
        <viewModels:MyExampleViewModel />
    </ContentPage.BindingContext>
    <ContentPage.Content>
        <StackLayout>
            <Label Text="{Binding MyTitle}"
                VerticalOptions="CenterAndExpand" 
                HorizontalOptions="CenterAndExpand" />
        </StackLayout>
    </ContentPage.Content>
</ContentPage>

the only thing we have added is:

x:DataType="viewModels:MyExampleViewModel"

I told you that it was easy.

Now we have obtained two great things:

  • Our code will be faster as we don’t have to use reflection anymore.
  • When we compile the code, the compiler will check if our properties (MyTitle in this case) are actually present in our ViewModel. If not, the compiler will inform you of the error and you will be able to quickly fix it.

Performances

I haven’t done any precise test but I’ve actually seen that enabling the Compiled Binding, made my app UI faster and smoother. So they work. Anywaythere are some numbers, According to Microsoft and Xamarin:

  • A  compiled binding with property-change notification is resolved approximately 8 times quicker than a classic binding.
  • A compiled binding without property-change notification is resolved approximately 20 times quicker than a classic binding.
  • Setting the BindingContext on a compiled binding that uses property change notification is approximately 5 times quicker than setting the BindingContext on a classic binding.
  • Setting the BindingContext on a compiled binding that doesn’t use property change notification is approximately 7 times quicker than setting the BindingContext on a classic binding.

Few Tips

  • Always use the Compiled Bindings
  • If possible, set the x:DataType attribute at the same level in the view hierarchy as the BindingContext is set. (When you set the BindingContext, set the x:DataType too)
  • The x:DataType attribute can be re-defined at any point in a view hierarchy. For example you can set the x:DataType at the ContentPage level (like we did before) and then set it again on a label or on a CollectionView (Really you should use them as I wrote here).
  • If for some reason in your view you need to disable the Compiled Bindings, you can set the x:DataType to null, for example:
<StackLayout x:DataType="{x:Null}">
    <Label Text="{Binding MyTitle}" />
</StackLayout>

Conclusion

Compiled Bindings are extremely useful for two main reasons, they are faster and they discover a lot of problems at compile-time. You should really always use them.

As usual, if you like the article or you have questions, leave a comment down here.