Jump to: navigation, search

Changes


XAML Best practices

1,639 bytes added, 12 June
#331 Continued - Performance (WIP)
== Performance ==
A basic rule is that '''more code = more to compile''', and this can decrease the performance of your whole application. To counter that, always attempt to reduce the amount of xaml customizing, especially if you find yourself repeating specific controls and attributes.
=== Understanding Templating in UBIK ===
Templates for the entire default UI are already present in the client’s core. Customizing templates allow modification of specific areas of the UI by overwriting the parts of the default UI with the same name. Therefore, only add the specific xamls that need to be customized. This is recommended for many reasons;
 
* Custom xamls will ‘undo’ improvements to the UI coming from newer versions of the client, when they are based on xaml files from an older version of UBIK. For custom UIs there is no way around it, but this is why '''uncustomized copies of xamls should never be added to the project folder'''. To remove a customizing, simply delete that file (there is no need to replace it with an uncustomized version from the default folder).
* Less xaml files to parse means better performance.
* More xamls also makes it more difficult for others to read and understand the customizing. This makes it much more difficult to find and diagnose errors when requesting support. It also generally increases the effort required to maintain the xamls.
 
Furthermore, remember to always deploy a new Default folder when updating your client version, to ensure that the latest UI version is the foundation for your customizing.
 
For more information on templating, check out our article [[UBIK_Templates]].
487
edits