XAML Best practices - Revision history

ARU at 10:36, 4 December 2025

2025-12-04T10:36:43Z

ARU: /* Performance analysis (Mobile only) {{Version/MobileSince|5.0}} */

2025-12-03T13:06:59Z

‎Performance analysis (Mobile only) {{Version/MobileSince|5.0}}

CWI: /* Performance analysis (MAUI only) */

2025-09-23T08:55:56Z

‎Performance analysis (MAUI only)

CWI at 10:54, 22 September 2025

2025-09-22T10:54:09Z

Show changes

CWI at 12:06, 18 September 2025

2025-09-18T12:06:38Z

REP: /* Context Switching And Templates */ restructured and added UWP example

2025-08-18T12:14:25Z

‎Context Switching And Templates: restructured and added UWP example

LGE: /* Performance analysis (MAUI only) */

2025-07-15T12:35:47Z

‎Performance analysis (MAUI only)

LGE: /* Performance */

2025-07-15T10:41:43Z

‎Performance

REP: /* How to select the right Control */

2025-06-30T14:13:50Z

‎How to select the right Control

KGR: /* Improving performance on complex List item templates */

2025-03-24T09:08:44Z

‎Improving performance on complex List item templates

@@ Line 1: / Line 1: @@
 This article recommends approaches to customizing and troubleshooting your UBIK custom UIs.
 To learn about the fundamentals of XAML, check out our article [[XAML_Basics]].
@@ Line 266: / Line 264: @@
 <pre>2025.12.03 13:39:35:4747 | Grid 'UBIKChildITEM_RootGrid' rendered in 28.3865 ms</pre>
-[[Category:Mobile|XAML Best practices]]
-[[Category:Pages with broken file links|XAML Best practices]]
-[[Category:XAML|XAML Best practices]]
 == Templating ==
@@ Line 430: / Line 428: @@
 {{Attention|Remember that Styling in Xaml is type-based, so you cannot use the same template with controls:ContentControl (ContentTemplate attribute) and ContentView (ControlTemplate attribute), as DataTemplate and ControlTemplate are technically different types.}}
 == Performance ==
@@ Line 455: / Line 448: @@
 == Testing of UI ==
 XAML can be sometimes very weird, there are dependencies or default values that you don’t see immediately. So, a good way to prevent millions of fixes for the customer, because the environment, different device or even a different windows version destroys your UI, is to write a test plan where you test your implementation. It’s important to see exactly your controls in action on their own and acting with each other, so you can prevent doing lots of ‘easy’ fixes.
 == Improving performance on complex List item templates ==
@@ Line 572: / Line 563: @@
 '''Why This Change?'''
 * '''Avoids Additional Binding Errors''': Using this workaround seems to prevent binding errors.
 [[Category:Mobile|XAML Best practices]]
 [[Category:Pages with broken file links|XAML Best practices]]
 [[Category:XAML|XAML Best practices]]

@@ Line 239: / Line 239: @@
 In the Mobile app, {{UBIK}} provides customizers a possibility to analyze the performance of specific UI elements by measuring the time it takes to render them. This can help customizers find performance weak spots in the entire UI and also serve as a benchmarking tool to verify the result of any improvement attempts.
 The measurement is achieved through the use of the MeasurePerformanceBehavior. The concept of it is very similar to other behaviors, namely you attach it to any UI element in the XAML code (as long as it's a derivate of the [https://learn.microsoft.com/en-us/dotnet/api/microsoft.maui.controls.visualelement?view=net-maui-9.0 VisualElement], which should cover the vast majority of all UI element types).
-* The behavior measures the time to render the UI element (which it attaches to) as well as its child elements (recursively if any).
+* The behavior measures the time to render the UI element (which it attaches to).
 * You can attach multiple behaviors to multiple UI elements at the same time, one to each, in order to get the measurements of the different elements.
-* The measurements are logged in the UBIKDebug.log file under the app's Logs folder.
+* The measurements are logged in the UBIKUIRenderingPerformance.log file under the app's Logs folder.
 * You can and should assign a unique name to the Label property of the behavior, so that it's easy to identify the render time of the target element.
@@ Line 263: / Line 264: @@
 With this, you should see log entries such as the following, one for every child item that you see when opening a content page.
-<pre>2025.07.15 12:12:18:1030 Debug   Sender: MeasurePerformanceBehavior  Message:'Rendering Microsoft.Maui.Controls.Grid UBIKChildItemRootGrid took 8.4889 ms'</pre>
+<pre>2025.12.03 13:39:35:4747 | Grid 'UBIKChildITEM_RootGrid' rendered in 28.3865 ms</pre>
 [[Category:Mobile|XAML Best practices]]

@@ Line 236: / Line 236: @@
-=== Performance analysis (MAUI only) ===
+=== Performance analysis (Mobile only) {{Version/MobileSince|5.0}} ===
-In the MAUI app, {{UBIK}} provides customizers a possibility to analyze the performance of specific UI elements by measuring the time it takes to render them. This can help customizers find performance weak spots in the entire UI and also serve as a benchmarking tool to verify the result of any improvement attempts.
+In the Mobile app, {{UBIK}} provides customizers a possibility to analyze the performance of specific UI elements by measuring the time it takes to render them. This can help customizers find performance weak spots in the entire UI and also serve as a benchmarking tool to verify the result of any improvement attempts.
 The measurement is achieved through the use of the MeasurePerformanceBehavior. The concept of it is very similar to other behaviors, namely you attach it to any UI element in the XAML code (as long as it's a derivate of the [https://learn.microsoft.com/en-us/dotnet/api/microsoft.maui.controls.visualelement?view=net-maui-9.0 VisualElement], which should cover the vast majority of all UI element types).
 * The behavior measures the time to render the UI element (which it attaches to) as well as its child elements (recursively if any).
@@ Line 247: / Line 247: @@
 <tabs>
-<tab name="Mobile(Maui)">
+<tab name="Mobile">
 <br/>
 Namespace referenced in the code: <code>xmlns:behaviors="clr-namespace:UBIK.MAUI.Behaviors;assembly=UBIK.MAUI"</code>
@@ Line 265: / Line 265: @@
 <pre>2025.07.15 12:12:18:1030 Debug   Sender: MeasurePerformanceBehavior  Message:'Rendering Microsoft.Maui.Controls.Grid UBIKChildItemRootGrid took 8.4889 ms'</pre>
+[[Category:Mobile|XAML Best practices]]
+[[Category:Pages with broken file links|XAML Best practices]]
 == Templating ==

@@ Line 265: / Line 265: @@
 <pre>2025.07.15 12:12:18:1030 Debug   Sender: MeasurePerformanceBehavior  Message:'Rendering Microsoft.Maui.Controls.Grid UBIKChildItemRootGrid took 8.4889 ms'</pre>
-[[Category:Pages with broken file links|XAML Best practices]]
-[[Category:XAML|XAML Best practices]]
 == Templating ==
@@ Line 431: / Line 431: @@
 {{UnderConstructionEnd}}
-[[Category:Pages with broken file links|XAML Best practices]]
-[[Category:XAML|XAML Best practices]]
 == Performance ==
@@ Line 576: / Line 576: @@
 [[Category:Pages with broken file links|XAML Best practices]]
 [[Category:XAML|XAML Best practices]]

@@ Line 378: / Line 378: @@
 ==== Context Switching And Templates ====
-<tabs>
-<tab name="DataTemplate (Xamarin only)">
+===== '''DataTemplate''' =====
 As described in the previous section, DataTemplates are designed to be used as templates for data contexts, therefore the content control used to render them, controls:ContentControl, has the TemplateContext property which allows you to set the binding context '''for the template'''. The important difference to note is that the controls:ContentControl itself will not use the TemplateContext, but rather the inherited context from its hosting xaml.
 Because they are independent of each other, it allows more sophisticated usage of binding contexts, for example, when ''Object A'' has ''Status B'', show ''Property C''.
 <source lang = "xml">
 <controls:ContentControl (displayed on child area of Object A)
      IsVisible="{Binding Values[STATUS], Converter={StaticResource EqualityToBool}, ConverterParameter=B}"
@@ Line 391: / Line 402: @@
 </source>
 </tab>
-<tab name="ControlTemplate (Xamarin)">
-On the other hand, since the ControlTemplate is not designed to be used this way, it has no inherent binding context attribute that can be assigned to it's content only. To use it this way would therefore require a context switch on the ContentView used to render it, with the related adjustments required to bindings placed on the ContentView itself;
+===== '''ControlTemplate''' =====
 <source lang = "xml">
 <ContentView (displayed on child area of Object A)
      BindingContext="{Binding PropertyItems[PROPERTYC]}"
@@ Line 401: / Line 422: @@
      ControlTemplate="{StaticResource MyOtherPropertyTemplate}" />
 </source>
 </tab>
 </tabs>
-{{UnderConstructionEnd}}
+{{Attention|Remember that Styling in Xaml is type-based, so you cannot use the same template with controls:ContentControl (ContentTemplate attribute) and ContentView (ControlTemplate attribute), as DataTemplate and ControlTemplate are technically different types.}}
-−
 == Performance ==

@@ Line 248: / Line 248: @@
 <tabs>
 <tab name="MAUI">
 <source lang = "xml">
-<Grid xmlns:behaviors="clr-namespace:UBIK.MAUI.Behaviors;assembly=UBIK.MAUI">
+<Grid>
      <Grid.Behaviors>
          <behaviors:MeasurePerformanceBehavior Label="UBIKChildItemRootGrid" />

@@ Line 92: / Line 92: @@
 === How to select the right Control ===
-Controls often have similar functionality, making it difficult to decide which to use, making the question of which control to use highly ambiguous.
+Controls often have similar functionality, making the question of which control to use highly ambiguous.
 For clarity, a 'Control' refers to a single xaml object that can be added to your visual tree. These range in scope and purpose, from layouting (such as a Grid or StackPanel), to interactivity (such as a Button or TextBox), and everything in between (such as a ListView).
@@ Line 118: / Line 118: @@
 ** 🏆 '''Alternatives to the optimized ListViews should be used with extreme caution.''' Controls such as CollectionView or BindableLayout are not optimized for good performance in UBIK.
+[[Category:Pages with broken file links|XAML Best practices]]
 === Using Styles and Templates ===

@@ Line 411: / Line 411: @@
 === Overview ===
 Performance issues in XAML-based UI development often stem from unnecessary UI rendering and binding errors. Hidden elements remain in the UI tree, impacting performance, while premature bindings cause background errors. To optimize complex list item templates, UI content can be loaded only when needed, and binding errors can be reduced by applying view models at the control level. These improvements enhance efficiency, reduce log clutter, and improve maintainability.
 === Technique 1: Loading UI content on demand ===
@@ Line 473: / Line 470: @@
 <br>
-[[Category:Pages with broken file links|XAML Best practices]]
-[[Category:XAML|XAML Best practices]]
 === Technique 2: Reducing background Binding errors ===