tl;dw Build 2015 – Data Binding: Boost Your Apps’ Performance Through New Enhancements to XAML Data Binding

My too long; did not watch summary of a really interesting Build 2015 session about Data Binding: Boost Your Apps’ Performance Through New Enhancements to XAML Data Binding

Windows 10 Universal Apps support new compiled bindings that use {x:Bind} syntax – it’s possible to replace in some scenarios classic DataBindings, that are resolved in runtime using reflection, with new compiled bindings, that are created in compile time against specific DataContext type:

  • Declarative bindings are converted into generated code behind
  • Eliminates need for slow runtime “reflection” operations
  • Code can be inspected and debugged

x:Bind bindings are validated at build time

Performance improvements are clearly visible in lot of benchmarks shown in the session. Both faster page loading and smaller memory footprint.

Obrázek1

How to use it – Replace {Binding …} with {x:Bind …}. x:Bind is strongly typed. Mode=OneTime is the default.

Usage in Data Templates:

Capture

 

Resource dictionaries with bindings: Need to have a class, Need to have a code behind, Need to be loaded using their type. Too complicated for tl;dw, better check the session 🙂

x:Phase – progressive rendering for list items.

Capture

Another great feature – Binding for Events (finally!)

<Button Click="{x:Bind Model.ManagerProp.Reports[0].Poke}" Content="Poke Employee"/>

 

Signature needs to:

  • Have no parameters – void Poke() {…}
  • Or match the event parameters – void Poke(object sender, RoutedEventArgs e) {…}
  • Or match event parameters with base types – void Poke(object sender, object e) {…}
  • Overloading is not supported

Usable on all events, can replace usage of ICommand & EventToCommand behavior. Note does not cover command parameter, or ICommand.CanExecute scenarios

Binding Lifecycle & Performance

Binding initialization done during Loading event

  • Bindings.Initialize() will initialize bindings
  • Can call Bindings.Update() for async data
  • Bindings.StopTracking() to pause tracking, Update() will resume

OneTime binding is cheaper than OneWay

  • Bindings.Update() can be used to update OneTime bindings
  • For lists – consider INCC update of item rather than INPC for property

Not all binding path nodes need to support change notifications

How do I handle:

  • RelativeSource = Self, ElementName = … => x:Bind uses the page/user control as the context, so can use the element name
  • RelativeSource = TemplatedParent => x:Bind is not supported in a control template. Most scenarios should use TemplateBinding instead which is already optimized
  • Source / DataContext => Binding context for {x:Bind} is fixed, and can’t be changed for sub elements unless it’s a template. Options: Use a longer path to get to the data, Add a field/property to page and bind to that

When to use classic binding

  • Duck Typing – same property name on different objects => Text=“{Binding Age}” works for both Person & Wine objects. x:Bind Mitigation: use a base class / interface
  • Dictionary graphs => {Binding} can work with JSON or other dictionary of untyped objects. {x:Bind} doesn’t work without typing information
  • Programmatic binding creation => {x:Bind} doesn’t have the ability to add / remove bindings at runtime
  • Use in a style => {x:Bind} can’t be used in a style for setters etc. It can be used in a DataTemplate defined in the style

Summary