This is part 1 of 2 in a series. The next post will focus on how to implement compiled data binding in Xamarin Forms. Before we get there, let’s take a look at the history of compiled data bindings and why we should use it.
When Windows 10 was being developed, the Windows team was developing some of the major UI components of Windows 10 using XAML. These include the start menu, action center, calendar, settings dialog, and even the UI that hosts the web renderer in Edge. This is just a few of the UI components in Windows 10 that use XAML. Now the Windows team does things a little differently than the typical XAML developer, they use C++ and performance is a very high priority.
Traditional data binding is expensive. It uses reflection and there are heavy demands on the CPU and on memory. The Windows team found that the overhead of data binding was not acceptable. They went back to the UWP team and expressed their concerns. At first, the UWP team recommended just skipping data binding and wiring everything up in code. Then they came up with a new idea, compiled data binding. Instead of putting the burden on the runtime engine, why not do as much as possible at compile time, remove all of the reflection overhead, and get some other benefits along the way.
x:Bind in UWP
If you are developing UWP apps, I highly recommend you look at compiled bindings using the x:Bind markup extension. You can find a lot of information online, here is one article about it: https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/x-bind-markup-extension
Let’s look at some of the problems with traditional data binding and how compiled bindings solve them.
Problem 1: Reflection overhead
Traditional data binding uses reflection. This means at run time, the UI framework needs to look up property names, invoke property getters to get the value, and more. This is a lot of extra work. With compiled bindings, code is generated at compile time to avoid all of this, and provide performance similar to if you wired up all of the UI population and updates in code yourself.
Problem 2: Debugging issues
Since traditional binding all happens at run time, you lose all of the compile time checks you are used to with other .NET development. If you spell the name of a property wrong, or if your data context is wrong, the application still runs, but the data doesn’t show up in the UI. It can be tricky to troubleshoot these issues since there sometimes isn’t an easy way to set a break point to see what’s going on. This means adding debug console writes, or to put in a dummy value converter so that you can add a break point. With compiled bindings you get a compile time error if the matching property name isn’t found.
Problem 3: Data binding requires public properties
Because traditional data binding uses reflection, it can’t deal with fields and event handlers. It can only deal with public properties. This forces us to write extra code to create command handlers and properties just to satisfy the needs of data binding. With compiled data bindings in UWP we can access public fields and can even call into an event handler instead of creating an ICommand interface.
In conclusion, performance is the main reason to use compiled bindings in XAML, but you get other benefits and if compiled bindings are available in whatever flavor of XAML you are using, I highly recommend you take advantage of them. In the next article we will look at compiled bindings in Xamarin Forms, how to use them, and how they differ from the UWP implementation.