In this chapter we will talk {{UnderConstructionStart}}<br>This article recommends approaches to customizing and troubleshooting your UBIK custom UIs. To learn about formatting the fundamentals of XAML code, issues regarding performance and naming conventions. This section can and will be expanded as further knowledge will be collectedcheck out our article [[XAML_Basics]].
== Formatting Conventions ==* x: Name or x: Key should always come firstConventions are ‘rules’ that make our xamls collectively readable and shareable. <br>* Every Attribute should be stacked over another for readability, except maybe for By aiming to construct our xaml files in a similar onesstyle, but this is not obligatorywe reduce the effort required by others to read and understand our work. E.g.: HorizontalAlignment – VerticalAlignment or Width – Height <br>* Adding comments. <br>This is one of the most important things section includes guidelines on how to write clear code. With the support of these comments you can save up time on searching name controls, and asking around. Try how to describe as best as possible the place, function, purpose of this object. <br>* Remove unnecessary code pieces. <br>Not only makes it the code clearer & more understandable, you are also improving the performance when not loading unneeded elementsinternally organize your xaml files.
=== Naming Conventions ===
<Button x:Name="SubmitFormButton" ... />
== Naming Conventions ==* The x:Name is used to give a unique name for an object, this attribute is valid throughout the whole XAML code with one exception, it’s within a xaml file. It’s not valid in a ResourceDirectory(such as a style, template, etc, either defined within a xaml file, or in UBIKThemes), which requires using x:Key instead. But ** Likewise there is also the attribute a difference when referencing {{#tip-text: x:Name | UWP: ElementName=SubmitFormButtonXamarin: Source={x:Reference SubmitFormButton} and {{#tip-text: x:Key which is mainly relevant | Both: {StaticResource SubmitFormButtonStyle} elements.* Use explicit language when naming styles, brushes giving a name or templates key, for example: “PropStkpnl” is not easily readable, but “PropertiesStackPanel” is. * Furthermore, “FailureCodeExpression” does not describe the purpose of the expression, whereas “FailureCode_HasUnfilledFields” does. ** Naming it according to its purpose also makes it easier to use in xaml, such as when combining the result with a ResourceDirectory converter for an intended outcome (eg. An warning symbol visible when FailureCode_HasUnfilledFields is true). * You '''do not''' have to name every object in your code, only if it is referred to by another element. However, sometimes adding names to controls helps a reader understand their intended function. === Formatting === Formatting xamls properly is critical to others being able to quickly read and understand a customizing. {{Hint|If you struggle to maintain nice formatting while writing your xaml code, you can find formatters that is automatically such as Notepad++’s “Pretty Print” or VS Code’s “XAML Styler” plugins.}} The most important points are marked with a 🏆 * x: Name or x: Key should come first.* A control with up to 2 Attributes can be added in our case one line. If it has more than 2, they should be stacked over another for readability. ** Avoid using a formatter where the UBIKThemes indentation matches the name of the control[[File:Formatting_Indentation.jpg]] * Add controls in a Top-to-Bottom order in the xaml file. Additionally, this attribute is only valid within this try to add them in a Left-to-Right order.** Controls in Grid.Row/Column 0 should be higher up in your xaml filethan controls placed in other rows and columns. * Respect indentation of nested controls.** Opening and closing tags should always begin in the same column. ** Controls nested inside them should begin exactly one column to the right. ** When pasting code snippets into your work, be sure to correct the differences in indentations. * Use explicit language when naming for example: NOT stkpnlProperties more like StackPanelProperties! Linebreaks mindfully.** It could force you is difficult to rethink about describe rules for how linebreaks should be used, but the structure of general idea is to use them to group elements in your object when placing xaml file, and to show which controls are nested (no linebreaks) and which controls are 'siblings' (divided by linebreaks).** ✔️Put linebreaks in between large sections of a UI definition (eg. between Grids or major elements of the true page, or between content set on different Rows/Columns).** ❌ Avoid linebreaks in the middle of smaller elements (eg. a stackpanel with 2 texts inside). * 🏆 Add comments.** This is one of the most critical features of clear code, saving the reader from wasting time struggling to read the code, or even having to search and ask around. ** Use comments to describe the position, purpose , and function of every control.** When maintain xamls according to a ticket, put the ticket number in a comment so a reader has access to background information on the change.[[File:Formatting_Comments.jpg]]. * Remove unnecessary code. Ensure everything included in your xaml has a purpose. This includes large sections of commented out code.** This both makes the xaml clearer, but also improves performance by avoiding unnecessary loading and rendering effort.** This is especially true when copying from other’s work. ** If you’re not sure if something is necessary, comment it out and see if your xaml still fulfils its function. If it works, remove it.** Described more in the name next section. * 🏆 Empty out your UBIKThemes for a new customizing.** When working in order Xamarin, it is recommended to minimize empty out your element countUBIKThemes file (ie. delete everything between the <ResourceDictionary> tags) and only add what you intend to customize. You DON’T have ** Unfortunately, this approach is currently not 100% possible in UWP xamls, as we noticed that custom styles are not utilized on controls unless the controls are also in UBIKThemes, shown instead using the standard grey/orange. However, diligent customizers are still welcome to name every object clear out their UWP UBIKThemes anyway and add styles back when required * Organize UBIKThemes in your codesections. ** For example, just standard UBIKThemes defines resources grouped into; Color resource / Size resources / Text styles / Button styles / etc** In Xamarin, keep Item Templates at the ones with eend of UBIKThemes.g** Either way, it is recommended to keep your UBIKThemes file as lean as possible (read the next point), as well as maintaining a grouping strategy. an important featureUse the tags <nowiki><!--#region Example--></nowiki> and <nowiki><!--#endregion--></nowiki> to define groups of content, for example <nowiki><!--#region Text Styles-->, <!--#region DataTemplates-->, or <!--#region Item Templates--></nowiki>. {{UnderConstructionEnd}}
== Performance ==
For an in-depth explanation, and guidance on how to implement such functionality safely, please refer to this page [[Object_hierarchy_in_XAML:_NextLevel,_ParentLevel,_LinkedLevel]].
[[Category:XAML|XAML Best practices]]
== 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.
[[Category:XAML|XAML Best practices]]
