Changes

While working on Performance issues in XAML-based UI development, issues related to often stem from unnecessary UI rendering and binding errors and visibility conditions. These binding warnings were mostly harmless Hidden elements remain in terms of performance but cluttered the logs and could lead to confusionUI tree, impacting performance, while premature bindings cause background errors. To mitigate these issuesoptimize complex list item templates, we refined our XAML practices. This document details UI content can be loaded only when needed, and binding errors can be reduced by applying view models at the two primary lessons learned control level. These improvements enhance efficiency, reduce log clutter, and how we improved our implementationsimprove maintainability.

=== Lesson Technique 1: Loading UI content on demand ===It was discovered that UI controls hidden with '''IsVisible=False still maintain a presence ''' remain in the UI tree. To improve performance on highly complex item templates, like UBIKTaskItem, rendered repeatedly such as in ListViews, a workaround can be applied to only load the UI content when the '''visibility ''' binding condition is met.

Previously, we used '''IsVisible ''' directly with a binding condition. The approach looked like this:

To prevent unnecessary loading of UI elements when their '''visibility ''' is False, it is possible to replace the UI content with a content hosting-control, such as a '''ContentView ''' or '''ContentControl'''. The original content should instead be defined as a template in '''UBIKThemes''', as shown below.

The important part of the snippet above is the '''DataTrigger'''. Through this technique, the '''ControlTemplate ''' of the content-hosting control is only set once the visibility condition is met, preventing the UI content from being loaded until it is explicitly required.

  === Technique 2: Reducing background Binding errors === Complex item templates such as UBIKTaskItem were found to produce large numbers of '''errors ''' while rendering, likely as bindings are being resolved before the relevant '''viewmodels ''' can be loaded by the client. While these '''errors ''' are temporary and not visible to the user, the cumulative effect of numerous binding errors raised while rendering items can be felt when navigating to pages with large numbers of items.

{{Attention|Unfortunately, these bindings errors are not normally logged in the UBIKDebug.log. Therefore, the recommendation is to use the following technique when whenever using a ContentControl or controls:ContentControl.}}

One workaround that reduced the number of '''binding errors ''' encountered was to refer to '''viewmodels ''' indirectly in the bindings.

The previous example used an '''MROViewModel ''' binding directly in the '''TemplateContext ''' property of the '''<ctrls:ContentControl>.''' However, a workaround that seems to avoid triggering background binding errors is to apply the '''MROViewModel ''' to the '''<ctrls:ContentControl>''' itself via the '''BindingContext ''' property, and then request that '''BindingContext ''' using the x:Reference syntax seen in the '''TemplateContext ''' property.