Wednesday, December 17, 2008
Tuesday, December 16, 2008
anyway I got the code out and walked through it since actually I'm checking all the samples currenty for the final review so I had todo it. In any case I was suprised to find that it works, Yes granted the in the article and post a year ago didn't expressly bind the events but seeing as the audience is developers and this is a blog called 'hacking' silverlight so I'm assuming that most of the readers are trained developers and in fact many are probably smarter then me so I would think they would be able to figure out what it means to add the events. The only other issue I found with the code was in fact when I wrote the article the play and pause methods were abstracted in the original which again was a simple thing but anyway I found the remark mean. and here is the same code recompiled on RTM SL 2.0 and it seems to work:
Wednesday, December 10, 2008
Here is some more 'content' summary info from my Architectural Best Practices presentation at DevTeach.
As to performance best practices… use the following as a good starting place:
· Don’t stretch things including Images, videos, or paths. Stretching things is going to cause more processing. Create assets at the size that they will be used and life will be much easier.
· Don’t use ECMA Script or the Anti-Pattern Silverlight 1.0.
· Don’t use windowless mode.
· Remove event handlers and set them to null before removing the element from the visual tree.
· Set MediaElement sources to null before removing them from the tree.
· Don’t use opacity if you just need to make things disappear, instead use the visibility property.
· Do use ‘IsHitTest’ and set it to false when doing drag and drop do hit testing only happens on the elements that are drag targets. This also allows you to keep visual elements from interfering with role over related events such as Mouse Enter and Mouse Exit events.
· Don’t have 1000 thousand elements in the same Visual Tree…
· If something is going to take a while tell the user or show the user that we are waiting.
· Don’t use ‘findName’ if you don’t have too as this causes a walk through the visual tree.
At least following these rules for Architecture and Performance your application won’t fall on its face.
Tuesday, December 9, 2008
Underlying Silverlight architecture helps us abstracted UI from logic and we need to take into account this toolability story that Silverlight enables as this can provide more ROI and shorter time to market for application development if designers and developers can work at the same time without the whole ‘through it over the fence’ approach. From a design pattern standpoint I recommend pMVP or Proxy Model View Presenter as the ‘better’ design patterns I know of require more upfront development as Silverlight doesn’t support the underlying infrastructure for these patterns. pMVP keeps it simple and the simplest solution is usually the best.
For Architectural best practices lets bullet out our best practices:
· Design Pattern pMVP (Proxy Model View Presenter) which is a clean, simple design pattern to implement that gives better abstraction.
· Make use of designer developer workflow enabled by Xaml UI separation.
· Don’t impose artificial Xaml coding conventions on designers or yourself as this slows productivity. Just let Blend go with it.
· Agree on Naming conventions, coding conventions (maybe standard WPF conventions might be a good place to start) and the like as you like but be consistent so that it is easier to support and pick up again later. This improves readability and helps the whole designer developer interaction.
· For the most part doing event bindings in Xaml, the more in Xaml the better however use common sense. If the designers are using Photoshop and converting the Xaml maybe just do the bindings in code so that you can have the designer just do a new conversion to generate new Xaml if they might make changes.
· Build at lest the Presenter logic in a separate Silverlight library.
· Build generic custom controls in a library.
· Consider putting the presenter code in a separate library or at least its own folder.
· Build Views with Blendablity in mind. Break up complex user controls that build the View into its component parts so that the elements can be more easily worked with in Blend.
· Use Gobal Styles and Templates and other resources in the App.xaml only when they are truly global in the application. Don’t clutter up the global resources with elements that are not really global.
· Use best practices with other connected technologies such as WCF or SQL or IIS/ASP.NET. Best practices in Silverlight wont’ do you much good if everything else is a mess.
· IF you build controls that rely on the DOM bridge encapsulate the ECMA related resources either in a Xap or right into the control so the ‘user’ as the simplest method to use the control.
· Consider the install experience to encourage users to install Silverlight so they can use your Silverlight application. Just using the default badge is boring.
· Consider Search Engine Optimization if it is a public site, such as control element names and the HTML on the Silverlight page etc. event the names of Xaml elements as a lot of this will be in the Xap that will at some point be parsed by search engine spiders.
That gives us a nice list of best architectural best practices. Following these simple rules lets you approach Silverlight architecture and application design with ease. Now we didn’t go into a lot of the application ‘Design’ aspects of ‘Designing’ applications such as UML etc but the focus here is strictly on Silverlight.
Monday, December 8, 2008
Anyway ignoring that little episode it was great. Here are the links to session material and content (mosting slide decks and sample code and some talk track notes I used to memorize content)
sad for those guys but cool for Silverlight... hmm.. will the dow go up or down?