Boost Performance with Compiled Bindings in Xamarin.Forms

Avatar

James

Data binding is at the core of just about every Xamarin.Forms application. It enabled developers to easily bridge their user interface with their code behind form a simple markup. Data binding also simplifies user interactions and updates to the user interface automatigical! With all this awesome comes with some trade-offs. Xamarin.Forms has to analyze and resolve each binding, which can take precious CPU cycles. This is where compiled bindings come in and help boost performance when using data binding.

What are Compiled Bindings?

A compiled binding is a way of telling Xamarin.Forms at compile time of the type of data the binding is going to be using. This is means that Xamarin.Forms will not have to use any reflection at runtime to resolve the data binding. By using the special x:DataType attribute on any VisualElement you can enable a compiled binding.

Benefits

Using these bindings offer a few major benefits for you and your app:

  1. Compile-time validation for all binding expressions.
  2. Performance improvements as bindings are resolved at compile time.

Enabling XAML Compilation

A pre-requisite to use these bindings is that your app must turn on XAML Compilation. This is the default in all new apps and greatly improves performance in apps when using XAML. You can enable it by adding an assembly flag in your shared code:

Using Compiled Bindings

Let's use an example of a page that displays a list of Monkeys in a ListView. This means we have a Monkey with properties on it about the monkey, a MonkeysViewModel that has data objects to bind to for the list, and a MonkeysPage that is our user interface in XAML.

Here is what the user interface looks like to display a list of monkeys and the current count:

Notice that we are binding from the MonkeysViewModel to MonkeyCount and Monkeys and additionally to the Image, Name, and Location of each monkey inside of the ItemTemplate.

To enable these bindings for the MonkeysViewModels we will bring in the namespace that it is in:

Then on the ContentPage node we can add the x:DataType property:

That is all it takes to start! Now, if for some reason we have a spelling mistake in our bindings when we compile the library we will get an error as the bindings will now be validated.

Compiled Binding Error Checks for XAML

If you are using any control that has a DataTemplate you must also setup the compiled binding on it. In this app, we have a ListView that is data bound to anObservableCollection<Monkey>. We can bring in the Monkey's namespace just like we did for the MonkeysViewModel.

Then on the DataTemplate, we can specify the x:DataType like we did before:

And just like that we have enabled this on our entire page and it only took a few seconds.

Learn More

There are a lot more ways to use compiled bindings in your Xamarin.Forms apps, so be sure to read through the comprehensive documentation. You can find a sample used in this blog on GitHub.

Avatar
James Montemagno

Principal Program Manager, Mobile Developers Tools

Follow James   

13 comments

  • Avatar
    Alessandro Caliaro

    Hi James.

    I am using a CollectionView with this ItemSource

    ItemsSource=”{Binding Immaginis.UrlImmaginiPiccole}”
    UrlImmaginiPiccole is List<string>
    What should I use for x:DataType? 
    Something like
    x:DataType=”string” ???

  • Avatar
    Charles Roddie

    > Data binding is at the core of every Xamarin.Forms application.
    This is a huge exaggeration. They are common but you can use Xamarin.Forms without them. There are very good reasons not to use them:
    1. They are badly implemented, without generics and type safety. ‘object’ and ‘string’ types everywhere. WPF had a weak excuse for that, since generics were new then, and Xamarin copied WPF’s mistake 10 years later. This post about reflection is a workaround for a small part of this problem.
    2. They are programming but tied to a language (XAML) which expresses programming badly. As a result even doing something as simple as defining a function is very hacky.
    There are much better reactive approaches than binding in WPF/Xamarin.

  • Avatar
    Pete Story

    Good feature, but (to reinforce what Håvard says) … if the data type of the view model is declared, why do I not see the view model properties in the intellisense when I am setting up a {Binding }. I really miss this contra XAML and WPF. 

  • Avatar
    John Tasler

    Why, oh why, can’t you and the rest of the XAML flavors get onto the same track? UWP XAML has had {x:Bind} for quite a while. Now, both flavors support compiled bindings, but in different syntactical ways. Aren’t you One Microsoft? How about One Xaml? Please, design your XAML features together!!!

  • Avatar
    pierre-louis deschamps

    Hello,
    Because I want to improve my knowledge and my code, I did the work to some of my pages. Mostly it works, but for my SightPage.xaml, I met here:

    public SightPage (Sight currentSight)
    {
    InitializeComponent ();
    BindingContext = new SightPageViewModel(currentSight, Navigation); //System.MethodAccessException
    }

    that exception:
    System.MethodAccessException: ‘Attempt by method ‘AlmicantaratXF.Views.SightPage.typedBindingsM__13(AlmicantaratXF.ViewModels.SightPageViewModel, System.Collections.Generic.IList`1)’ to access method ‘AlmicantaratXF.ViewModels.SightPageViewModel.set_Limb

    • Avatar
      pierre-louis deschamps

      So I removed the x:DataType in the ContentPage declaration.
      Then I did a mistake : My EntryAltitude is bound to the SightPageViewModel but I declared a DataType from the model:Sight:

      <StackLayout Orientation="Horizontal"
      x:DataType="models:Sight">
      <Entry x:Name="EntryAltitude"
      Text="{Binding Altitude}"
      </Entry>

      there is a float Altitude Property in Sight, so the compiler didn’t detect any mistake. Of course it did not work at runtime.
      The right declaration was:

      <StackLayout Orientation="Horizontal"
      x:DataType="viewModels:SightViewModel">

      The compiler should check the DataType type (float instead of string).
      Regards,
      Pierre

Leave a comment