I have been developing a new Silverlight framework for the last two months.  Well, really just the last month since it took my about a month to actually ramp up to a point where I felt comfortable writing a Silverlight framework.  The reason I am writing a Silverlight framework in the first place is that we intend on using Silverlight to enhance some of the advanced features of our our existing web apps, and perhaps to develop a new web app.  Our stuff is written in ASP.Net, so it made sense to go with other .Net-based tech.

I decided that we needed to write  a framework around the time we first decided to start looking into Silverlight.  There are a lot of custom things we do in our existing ASP.Net framework, and some of that would need to be replicated for Silverlight.  When I started down this road I did not imagine I would have as much work to do as I have done.  I was actually counting on a lot of stuff in Silvelight to be extensible that is actually not extensible.  I am learning that Silverlight acts more like an API than a Framework.

Consider the Timeline class.  This is the class on which multiple animations classes are based.  Storyboard, DoubleAnimation and ColorAnimation are three common classes that derive from Timeline.  Since .Net (in general) is a framework and not an API (although it contains numerous APIs) I figured I would be able to derive from Timeline to create my own, custom animation classes.  This is a common task in normal .Net land.  Many core-framework classes are written to be extensible.  Boy was I stupid for thinking such a thing about Silverlight’s Timeline class!  As it turns out extending Timeline gets you nowhere.  The Timeline class, and the classes that derive from it in Silverlight, do not contain any actual animation logic.  They are really just command objects that describe some values about a particular type of animation, and the animation itself is run deep in the Silverlight runtime.

This really doesn’t do me any good for a couple of the tasks I would like to accomplish.  The recommendations online are either to use a timer or use a thread to drive a “game loop” to do custom animations.  Really?

So this morning I set out to write a custom animation framework.  I had been thinking of this for a while, so perhaps I should admit that I started the thought experiment of “How do I write a custom animation framework in Silverlight?” a couple of weeks ago.  Still, I wrote my first line of code this morning shortly after 9:00 AM CST.  At around 4:30 PM CST I had checked in an abstract classes similar in purpose to Timeline, except it actually drives the animation.  I had further derived an abstract child for animations that target object properties for animations (most cases), a class to extend said object that animates doubles (think DoubleAnimation), a concrete child that groups animations (think Storyboard), and a class that allows the programmer to write a custom logic that is fired for every frame render.  My core logic is based on the DispatchTimer class (in System.Windows.Threading), which I chose because it does the cross-thread invocation for me.

I am still missing some of the functionality that is represented in the Silverlight counterparts, and am missing several types of animations.  Additional animations should be easy to implement now that I have the base stuff written.  It should be really easy to replicate those classes found in the Silvelight version of .Net as most of those are really just numeric range animations.  I also need to implement some functionality like AutoReverse, and looping logic for my own Storyboard object (which is called GroupStory).  What does it do when all of its animations are complete?  Repeat?  And the framed animations are also a task to get to in the near future.

I did all this work, it is tested and checked in, in one day.  I wrote a framework to replace an API.  As much as I like Silverlight 2.0, I wish they have waited just a little longer to get some more of these “framework vs API” things resolved.  Animation is just one of the examples of where Microsoft should have been thinking about how all of us software engineer types in the real world would be extending their functionality.  But its a big example, especially considering their target audience.  I am not kidding myself here.  I prolly have bugs waiting for me in that code.  But I can leverage it to do so many interesting things now.  It may take me the rest of the week to really work through the other animations and fix bugs.  Maybe I will still be working on it next week.  But I am just one guy, and I can accomplish this much in such a short period of time?

I am also not kidding myself about the talent at MS.  IMO, .Net is Microsoft’s nicest product.  They have done a stellar job with it.  C# is my favorite language.  And really, Silverlight is a wonderful run-time.  I have no doubt that those developers and managers at MS responsible for it are hard working and talented people.  I just hope that the next version of Silverlight they produce is more like a framework that the current version.

• Previous Entry: Custom Visual States in Silverlight
• Next Entry: Software Bugs