Some Best Practices for Silverlight Application Development (XAML)



I was working with WPF/Silverlight since March 2008 and learnt lots of things. I wrote lots of Articles on Silverlight and published in my Blog. Today I decided to share you some of the best practices you should follow while doing development in WPF/Silverlight. Hope, this will help you guys while writing XAML codes. Read and try to strict with the guidelines whenever you are modifying your XAML.

 

Feedbacks are always appreciated. Hence, don’t forget to leave your comments at the end. If you have any more points, please share it here. I will review them and add those here.

 

Update [08-Aug-2010]: On popular demand, I updated this post with some explanation on “Why?”.

 

Some of the XAML coding best practices mentioned below:

  • Don’t use unnecessary “xmlns” namespaces in the XAML file. This overburdens the load time of the Silverlight page (If you are using Resharper, you can do this very easily as it will change the color of the unnecessary items to Grey).
  • Don’t add same namespaces multiple times in a single XAML page. It screws up the XAML code at the time of maintenance and also loads the assembly namespace multiple times causing various memory issues at runtime.
  • Use proper name for your “xmlns” namespace prefix. For example: xmlns:commonControls is more meaningful than xmlns:cctrl. This avoids multiple declarations of namespaces in future.
  • Try avoiding “xmlns” namespace prefix name as “local”. Instead use “localControls” or “localConverters” etc. as per your namespace name. Using “local” will not give you proper meaning. In the same assembly there may be two or more namespaces (e.g. Controls, Converters etc.). In such case, it will be helpful for you to use proper prefix name to distinguish between them in proper way.
  • When adding a control that has no elements inside it, better to close it by self-closing tag “/>” instead of the hard closing tag (</TAG>). This gives more cleaner XAML code. 
  • Remove all unnecessary resource keys if they are not in use. These increases the memory uses and you may sometime encounter some animation issues due to this. If you need it at later point of time, you are always welcome to add it.
  • Don’t use extra panels (e.g. Grid, StackPanel, Canvas etc.) unless it is required.
  • Always try to use Grid as your panel first and if you require other panels, use them. Grid has the flexible UI layout and thus resizing your application will have a great effect.
  • Never try to give a name to all of your controls inside your Silverlight page as it takes unnecessary object creation at the time of load. Name only those elements which you want to use from your code behind and/or from your xaml. If you are using MVVM pattern, you can remove the naming of your controls in almost all the cases.
  • Use the Visibility property of the controls instead of the Opacity property to hide the content. Opacity to zero makes the control to hide but takes space in both memory and the UI. Other side, the Visibility property collapses the control from the UI, thus making spaces for the other controls in the same place.
  • Use proper formatting of your XAML code. This gives better look of code and also easy to maintain in future.
  • Use comments in XAML whenever require. This is useful when you revisit the code after a long time or some other person comes to work with your XAML file.
  • Try to use StaticResource instead of DynamicResource as it increases the performance and also it throws exceptions at development time. Hence, easier to identify the root cause.
  • Remove unnecessary styles & storyboard animations if they are not require at all.
  • Try to add your styles in a separate file if you want to share them across your application. If they are specific to a single page then add them in the page resource.

18 comments

  1. Perhaps you could formalize your rules by using FxCop for XAML support in XamlToolkit CTP?
    -Rob Relyea, Silverlight/WPF Team
    http://robrelyea.com/blog | @rrelyea

    ReplyDelete
  2. This is my first visit to your blog, found it via Dzone. I like your Template will have to check it out, I use Prosumer on my site but like this one better.

    Anyway, nice article. I'm on the bench now and coming from PowerBuilder so am trying to learn Microsoft and Java technologies as fast as possible so that I can decide which one I enjoy the best.

    Every time I dig into Java technologies it seems cool at first but ends with me pulling my hair out so today I'm leaning Microsoft.

    Regards,
    Rich

    ReplyDelete
  3. The one item that surprised me the most was not to name all your XAML items. I guess it makes sense there would be a little overhead in providing explicit names.

    Good stuff. Thanks.
    Rich

    ReplyDelete
  4. Hi Rich Bianco,

    Welcome to my blog. Glad to hear that, you started working on the Microsoft Technology specially WPF/Silverlight. So, keep learning... :)

    Regarding your second query "The one item that surprised me the most was not to name all your XAML items. I guess it makes sense there would be a little overhead in providing explicit names."

    My answer here is "NO". Because, if you name your all controls it will create those control instance separately by using the FindName() method and that will be responsible for unnecessary delay loading your page. For more information visit Pete Browns blog where he mentioned why x:Naming is bad for all controls. Read it here: http://10rem.net/blog/2010/07/02/silverlight-wpf-dont-name-elements-unless-you-have-to-why-xnaming-everything-is-bad

    Keep learning & work with fun. Have any question, please let me know. I will try to help you by answering your query as soon as possible.

    Regards,
    Kunal

    ReplyDelete
  5. The "Don't name all your controls" is a genuinely good tip!..
    Thanks!
    Cennest

    ReplyDelete
  6. Hello, great post. It's good to know best practices. But lot of practices you mentioned miss explanation why to do it that way...

    To be concrete:
    - Try avoiding “xmlns” namespace prefix name as “local”. Instead use “localControls” or “localConverters” etc.
    Why?

    - When adding a control that has no elements inside it, better to close it by self-closing tag “/>” instead of the hard closing tag ().
    Why?

    - Always try to use Grid as your panel first and if you require other panels, use them.
    Why?

    - Use the Visibility property of the controls instead of the Opacity property to hide the content.
    Why?

    - Try to add your styles in a separate file if you want to share them across your application. If they are specific to a single page then add them in the page resource.
    Why?


    I don't mean I disagree with any of this. In most cases I am already coding according to this. But it is always good to know the reason.
    (And I think I could guess most of the reasons but I'm not sure)

    Thanks

    ReplyDelete
  7. While I like the idea of removing x:Names from elements in XAML, there are a number of occasions where you need to have them:
    * Element-Element binding (useful)
    * Visual States (very useful)
    * Animations (usefulness varies)

    In our recent projects, we've been trying to get the designers to be able to do as much as possible without code. Behaviours help this quite a bit.

    While you could have a pure MVVM implementation without x:Names present, I don't think you could have one that looks nice (FWIW I'm a developer, not a designer - my colleagues make our apps look so good/usable)

    Cheers,
    NotAHelpDesk

    ReplyDelete
  8. Kunal,

    Nice post. It's nice to run across some/more not so obvious guidelines for putting together a performant control, and one that's eaiser to maintain.

    Thanks.

    John

    ReplyDelete
  9. Kunal,

    Nice write up. A suggestion would be to explain the "why" in some of your tips. For example,

    "When adding a control that has no elements inside it, better to close it by self-closing tag “/>” instead of the hard closing tag ()"

    So my question would by, "why is this better"? Do you think that it is cleaner? Or does it help with load time performance? What about this tip is worth making changes in our existing XAML?

    I think you might want to consider adding why's to many of your tips to help less educated readers out.

    Thanks again!

    ReplyDelete
  10. Hi Petr,

    I will update it with the answer for your "Why" once I get time in this weekend. Thank you for your suggestion.

    Regards,
    Kunal

    ReplyDelete
  11. Hello notahelpdesk,

    Thanks for your feedback.
    If you read it properly, I mentioned there: "Never try to give a name to all of your controls inside your Silverlight page as it takes unnecessary object creation at the time of load. Name only those elements which you want to use from your code behind and/or from your xaml."

    So, if you want some specific controls which you want to access from your code behind, element-2-element binding, animation etc. then you are welcome to add the names. Not recommended for all the panels & controls if you are not using them anywhere.

    ReplyDelete
  12. Hi folks,

    I just updated this post with some explanation on "Why?". This update is on popular demand.

    Thank you so much for your feedbacks.

    ReplyDelete
  13. Hello Sir,

    Can you post some best coding practices for c#? I found so many urls over net but quite confusing some times. It is always better to read something new & special.

    ReplyDelete
  14. Nice Post!!!

    The points you have given is useful. If you van give some more information for the reason of doing this that would be better.

    Like...

    Don’t use extra panels (e.g. Grid, StackPanel, Canvas etc.) unless it is required.

    Whats is the reason behind it?

    ReplyDelete
  15. Hi Anilal,

    This is simple to understand. Why should you use something if that is not require at all. If you can do something with StackPanel, why to use ScrollViewer and Grid to implement the same functionality. Unnecessary use of controls will hamper your application performance too.

    ReplyDelete
  16. Hi,

    Thanks in advance for the good tips, but i have a question for you. What is the best pratices to create big project? Is better small projects or just some bigs projects?

    I have some problems now because my projects create a big .xap, 3Mb , and my application open a lot of windows, so, they take a long time to load .xap everytime.

    What is your opnion for that?

    Thanks

    ReplyDelete
  17. Hi JMagalha,

    It is always better to split your big project into smaller ones and load them on demand. This way you can reduce the loading time of the application and give better experience through out the whole application.

    3MB XAP size is pretty big. I will suggest to split them and download on demand.

    Regards,
    ~Kunal

    ReplyDelete


 
© 2008-2014 Kunal-Chowdhury.com | Designed by Kunal Chowdhury
Back to top