Blogging from FlexSeminar, NY

Well, here I am, or rather have been for the last 5 hours, at the Roosevelt hotel, attending the Real World Flex Seminar.. Whats it been like? demos….loooots of demos. And thats exactly what I came for. Seeing some of the apps that adobe has developed has been pretty interesting. Some interesting apps I have seen are a complete CMS system (ShadoCMS) and a ColdFusion Framework for writing Flex apps based on CF backends. Not that many other application vendors although there are a bunch of consulting houses out here.

Got a few doubts cleared for FlexAmp v2 ;).

Links for the day:

Loading skins at Runtime

Static methods vs. Singletons

For the last 2 years, I have been working on a number of very intense projects that involved a truckload of AS2 code (I cant imagine ever doing it in AS1). As of today, the framework is pretty extensive with enough functionality to make the day-to-day stuff a breeze. However, there is always room for improvement so I keep flipping things around trying to make the most agile and adaptable system I can.

Some of the designs I recieved for an upcoming project looked like they could benefit from a little reorganization on the framework end. The situation was this: The designs for the user-controls (scrollbars, buttons, text inputs, etc) seemed to reuse the same drawing elements. For example the input areas for checkboxes, text inputs, etc looked exactly the same. So I figured, it would be neat if the controls in the framework could instantiate an application level graphics toolkit and pass MovieClips to it. The toolkit would then draw on the MovieClip to conform to the look and feel of the application. This made the controls in the framework fairly agnostic to the application look and feel.

The system works perfectly only if all the application-level graphics toolkits implement the same methods. For example, all toolkits would need a method to draw a text-input background or a button state etc. The whole idea of polymorphism fits wonderfully here: define an interface and let each implementation implement the functions that you mandate. Unfortunately in my case there was a snag: The simplest way I implemented the first toolkit was by making it have a series of static functions. So, for example, my text-input control code looks like:

class TextInput extends BaseControl{
private var _toolkit:IUIToolkit;
private var background:MovieClip;

/* init code */

public function set toolkit(t:String{
this._toolkit = eval(t);
}

public function build():Void{
if(this._toolkit==undefined){
throw new ToolkitUndefinedError();
return;
}
_toolkit.drawTextInputBg(this.background);
}
}

A point to note above is that toolkit name is being sent in as a string. This ensures that you are not compiling any application level toolkit when you compile the framework. When you do the eval, the class name sent is evaluated and a class object is returned. This is the Flash equivalent of Java’s Class.forName().

Unfortunately, since all the functions in the toolkit class were static methods and Interfaces cannot define static methods, there was no way for me to ensure application toolkits would define the methods mentioned. The only solution was to have a singleton implementation for the toolkit so that you always instantiate ONE instance of a toolkit and use that.

Although that does seem like the best scenario, I am still not completely convinced especially in light of the AS3’s discontinuation of private constructors (sigh !). Anyways lets see how this works out.

I can always refactor later ;).

p.s : I found a rather interesting discussion on singletons here

The Fan: Flash Forward Finalist

FYI: The Fan has been nominated for Flash Forward as a finalist in the video category. Its pretty gratifying when you see something you have worked on for so long be appreciated by the online community. Check it out here and do show your appreciation by voting for us here. Oh, and while you are at Comcast Labs, check out the other cool stuff thats coming soon.