I am now a writer for the SilverlightShow website! The announcement can be found by following the link below:
http://www.silverlightshow.net/news/Welcome-Chris.aspx
I will be continuing my series of articles as detailed by that post, and part 2 is now published. You can check it out here:
http://www.silverlightshow.net/items/Building-a-Silverlight-Line-Of-Business-Application-Part-2.aspx
For my Silverlight Line-Of-Business framework I wanted a wait indicator much like there is in Firefox or when starting a Youtube video, which could indicate when the application is going off to the server to retrieve some data (or sending some back). If you don’t know it, the style I’m talking about is eight dots in a circle that light up one after the other around the circle (see the screenshot below). Funnily enough I couldn’t find any controls out there for this purpose, so initially I just used a text block to notify the user something was happening. Now that I have a little more time I decided to revisit this and develop my own. In fact I ended up developing three (that look identical but are implemented differently) in order to familiarise myself with animation in Silverlight, and compare the different approaches.
A bit of an overview of Silverlight animation first (as it pertains to this control with changing the colours of framework elements). A storyboard is added to to the resources of the user control, and defines the animation per element (ie. each object to be animated – in this case each dot in the circle). For each element you specify a number of key frames, which essentially consist of a time and the colour the fill of the element should have at that time. In this case I am changing the alpha value of the fill colour to a specific value and specifying these values in 0.15 second intervals. In between these 0.15 second intervals the Silverlight rendering engine continues to render the animation, interpolating the value of the previous key frame with that of the next key frame to gradually blend the previous key frame’s colour with that of the next key frame.
I first looked at implementing the animation directly in the XAML using a storyboard with a number of key frames. I found this approach quite tedious (especially when I ran it and discovered it was animating in reverse – I had to rearrange 64 key frames manually to fix it). It also blew out the size of my XAML file. When I started building this control I wrapped the storyboard in an Event Trigger (when the canvas loaded) so that it would automatically start when the control was displayed. One concern I had was whether the control would continue to animate even when it wasn’t visible (I’m not sure of the answer to this question as yet), and another was raised when in my research I came across this topic in the MSDN documentation that noted (in the remarks) that this approach was discouraged, and to instead put the storyboard in the UserControl.Resources section instead (and manually trigger the start of the animation):
http://msdn.microsoft.com/en-us/library/system.windows.eventtrigger(VS.95).aspx
So now I trigger the animation by including public methods on the control to start and stop the animation.
Note that each dot in the circle is actually white, but we are just adjusting the alpha levels of each dot (blending in with whatever is behind) to give the impression of a moving dot with a trail. By only altering the alpha value, this means is that you don’t have to use this control on a black background – any backdrop (including graphics) will work and look good.
Now to compare the three approaches. The animation defined in XAML was painful to implement (it may be easier to do in Expression Blend but I was developing the XAML directly in the Visual Studio editor), whilst it was quite easy programatically (both methods). Defining the storyboard in both the XAML page and code of course gave exactly the same look and speed as each other. However manually handling the updating of each “frame” in code produces a slightly slower result (see the sample application to compare) which I found intriguing, despite the same key frame rate – it would be interesting to monitor this difference on a more intensive animation. Of course I could increase the key frame rate (which is the duration of the animation in this implementation, so essentially reducing the duration) to match but I’m not particularly concerned in this scenario. The other difference between the storyboard implementation and the programmatic animation is that they actually look different (as you may note from the screenshot below):
Notice when we are programmatically handling the updates that the “lead dot” is the brightest, whilst when the animation is handled by a storyboard the brightest dot isn’t the “lead dot”, but the second dot in the “bright dots” instead (if that makes sense). This goes back to how the Silverlight rendering engine interpolates the values of the previous and the next key frame – this dot is supposed to be the dullest dot but it knows it is to be the brightest dot at the point of the next key frame so it’s “gearing up for it” by getting brighter as the next key frame approaches. However in our programmatic updates we are changing the values “discretely” once every 0.15 seconds with no interpolation, thus the lead dot is always the brightest.
Another interesting aspect to compare was the size difference in the class libraries for each implementation. As compiled DLLs, the XAML version came in at 14,848 bytes, defining the storyboard programmatically came in at 9,216 bytes, whilst the programmatic animation version came in at just 7,680 bytes. My assumption here is that (and from inspecting each DLL in Reflector) that the XAML file is not compressed when added as a resource to the DLL, while the code in the programmatic version is “compiled” into a relatively compact intermediate language (MSIL) with the comments removed. Of course this is not the whole story with Silverlight as the DLLs are packed into the .xap file in the main Silverlight project (which is compressed in the zip format). So to compare this I zipped each DLL and compared the size of each zip file. The result here was much closer – 3,185 bytes for the XAML version and 2,962 bytes for the programmatic animation – a difference of just 223 bytes, but programmatically defining the storyboard was the largest at 3,863 bytes. So for this example at least you could say that the impact of each version on your XAML file is negligible.
I would welcome feedback on what approach you think is best and could be considered a “best practise” for implementing animation in Silverlight. Whereas it was tedious to define the animation in XAML, it’s likely to be more easily modified in Expression Blend later, whilst the programmatic versions will have to always be altered via code. You have 3 different versions of the control so you can choose your favourite, but until feedback tells me otherwise I will incorporate the version where the animation is defined in the XAML page in my LOB framework.
To use the control in your own projects (whichever version you choose) you could leave it in it’s own DLL (as it is currently) and just reference it from your project, or alternatively just include the .xaml and .cs files in your project. I recommend changing the namespace (you’ll need to do this in both the .xaml file and the .cs file) as the current namespace name is really designed just for the sample application where the three different versions were running along side each other. Then reference the namespace in the user control you want it to appear in with a prefix, and then reference and position the control in your xaml layout (remember to include a name for the control using the x:name attribute). Then in your code behind you can call the Start() and Stop() methods on the control to start and stop the animation. When the animation is stopped the circle of dots will be hidden, only appearing when the animation is running.
Note that there appears to be a bug in the RC0 version of Silverlight – when you use this control on a surface you won’t see a preview of it in the Visual Studio designer as I collapse the canvas until the animation has been started unless it is being hosted in the designer, using the following code:
System.ComponentModel.DesignerProperties.GetIsInDesignMode(this)
which doesn’t appear to pick up the fact that it is in design mode in the Visual Studio designer, so the canvas is collapsed anyway.
As a footnote, after writing the control I was browsing some Silverlight articles about the RC0 release and realised that the new progress bar control could potentially be used as a wait indicator animation also. This control has a property called IsIndeterminate which if set to True does not render a standard progress bar but displays a moving gradient animation, so I have included this in the sample application for completeness. I think my wait indicator control looks a whole lot better though (no doubt I’m biased however).
I hope you find this control useful!
An update to the source code accompanying my article has been added to work with the new Silverlight 2 RC0 release (note it needs to get through moderation, but you’ll know it’s updated when you see a red message at the top of the article). A few changes needed to be made (primarily to do with control styles) which were throwing exceptions when building/running under the new release. Thanks go to the guys from the Blacklight project (which I use in the dashboard page) for updating their project to work under RC0 too, so that update has been incorporated into this update. The main issue I had to solve when updating was the fact that I couldn’t move around or maximise the dashboard panels anymore. I discovered this was due to the fact that I had put a text block in the “caption” of each panel – whereas previously the mouse down event went straight through my text block to be captured by the panel caption undernearth (to initiate a drag or click), under RC0 the text block was capturing the mouse event and not passing it through. Adding the attribute IsHitTestable with a value of False resolved this issue.
RC0 brings some new styles and controls with it – the DataGrid now looks a lot prettier so I’ve removed my own styling from the grid in this release. It still appears you can’t style the selected cell border (well according to the comment above it when I look at the style in the Data DLL in Reflector). Also with the new styles the line between the rows doesn’t extend across the whole grid width (just to the end of the last column, and some don’t make it all this way either). I guess that would be OK if you showed the vertical grid lines but I have chosen to hide these to achieve the look I want (or as close as I can get).
On a more positive note, the new rendering such that straight lines are aligned to the nearest pixel creates a much nicer and cleaner look. You’ll note that on the login screen I now use the new PasswordBox control for the password, and I use the new MessageBox command to notify when an incorrect password has been entered.
View the article here:
I’ve been playing a lot with Silverlight over the last few weeks, getting up to speed and developing some backend software for my business Peer Placements. From that project I’ve extracted code that will form a part of a reusable framework for helping development of Line Of Business applications, and I’ve built a sample application using it and the AdventureWorks sample database from Microsoft as an example implementation. The framework is still under development and the sample application is not yet complete, but I have released a preliminary build of my sample application as part of an article I wrote for the Silverlight: Write and Win! competition on the silverlightshow.net website, titled Building a Framework For Silverlight Line-Of-Business Applications. Voting is now underway and will complete at the end of the week. If you’re feeling in a generous mood please help me out by visiting the website and voting for my article (the last in the list) – if you think it worthy of course. There are some nice prizes for the first 3 places which would be great to add to my toolbox :). I was doing well in the voting earlier today, but recently some other articles have shot ahead so I could do with all the help I can get! Any feedback for the framework is more than welcome, and even if I don’t win a prize in the competition I hope you find it useful as a basis for getting your own Silverlight applications up and running.
My aim is to release this framework when complete as a Visual Studio project template (probably around the time of the Silverlight 2 RTM release), so that developers undertaking new Silverlight LOB applications can get up and running easily. I’ve experienced a lot of pain and quite a learning curve in the past few weeks, so if I can save others the same pain then I’ve done my job well :). I’m open sourcing this framework as I’ve gained a lot from open source projects in the past and hopefully this can be my way of contributing back to the community. Hopefully this project will also turn into a presentation that I can present at a .NET user group meeting sometime in the near future.
In other Silverlight related news, Silverlight 2 RC0 was released on Friday, and from reports I’ve read it’s looking like it will RTM towards in early October (or at least according to zdnet). RC0 has broken my application from beta 2, and I’ve spotted one bug that doesn’t appear to be fixed (in regards to initial focus of text boxes after the application has loaded) after patching it up and porting across to the new release – hopefully a fix will be included in the final release. Apart from this, there are some nice additions in this new release (controls, styles, and better handling of aliasing situations for lines and text that previously came out fuzzy – aligning these to pixel boundaries has created cleaner lines for a more attractive user interface). Will comment further when I have examined it in greater detail.
Chris Anderson 