Developer's Blog

I usually don’t write reviews, but this website deserves all the attention a Flex developer has. I have to say that I’m not writing this because of an agreement with the authors or that my analysis is exact in any manner. Most of guesses I’m doing here can only be confirmed by the authors – if they feel like doing so.

Now, the motivation of writing comes from the calculus I’ve made trying to rate this product on a scale from 1 to 10 – which in this case is very very close to ten. My best guess is that excellency comes in three flavors : user experience on the final product, applied cutting edge technologies and clarity of written code – which should assure both the scalability of the product while bug fixing / adding features would be quite easy. This website has it all!

OMGPOP.COM – formerly known as I’minlikewithyou or IILWY  – is build with Flex! You wouldn’t guess it on your first sight, mostly because of the slick graphics the website have. Even better, under the hood relies on Cairngorm, in a clear and beautiful manner which should encourage you to use Cairngorm – obviously, after playing with the website to make an idea about how helpful that was for the coders.

More than two hundred Commands are registered by the Controllers only in the core (no, I wasn’t looking for exploits – I’m not that kind of person). It has multiple Controllers, each of them having a clear role inside the application. Since I’ve mentioned the word “core”, you have already guessed that it is a modular application.

Now, about the server side, after doing a bit of research (google-ing after some author’s name) I’m guessing that is a Jabber server (the longest-running XMPP service on the Internet). From their website you can deduct that they are using Ruby on Rails for voice chat (by the way – if you’re looking for a job check them out), but I haven’t had access to analyze that.

Just a word about the components of the user interface : they are not based on the Flex UIComponent – the solution is based on extending Sprite and create a custom UIComponent like. Reason? My guess is it would have made the website too slow for it’s purpose.

In the end, I recommend to you to play at least one of their games : Balloono , Ballracer , Blockles , Dinglepop , Draw My Thing , Gemmers , Hit Machine , Hover Kart , Jigsawce , Letterblox , Putt Putt Penguin and drop me a line here about what you think. I’m convinced that you – as a developer – will acknowledge the power which lies within design patterns by taking a good look at OMGPOP and try to detect how they solved different problems.

Great job OMGPOP creators !

P.S. I’ve found somewhere on the web, that the creator of Balloono (a game which eats up time like there’s no tomorrow) is a well known author of book Actionscript 3 Bible.

To put together the last part of the Cairngorm series, I’ve started doing a little research about the Cairngorm architecture and got myself into trouble : I got lost into debates! All over the place there are voices which express a “this architecture versus that one“, who points out the pro and con for each and every single principle applied there. I don’t like debates, at least not in the sense of “mine is bigger than yours“, so, I feel that it is my duty to remind you the following:

• if you are reading this series of articles, then you got here looking for tutorials, right? You are looking for a way to discipline / educate yourself, to get started with the design patterns terms (in a practical sense) and to make your first mistakes – from which you will surely learn;
• do not get discouraged by those voices I’ve mentioned : criticism is good as long as you take what you need from it (and I’ll give you an example later regarding Singleton debates). To consider a bad thing that Cairngorm relies too much on the binding seems stupid to me, since points out another debate about how good is binding and why you shouldn’t use it. Another issue which is considered to be very important is monolithic classes : nobody forces you to get there, but you just might run into this problem. The solution ? Refactor your classes grouping by functionality and roles – as the basic Cairngorm principle says;
• take a good look at Universal Mind Cairngorm Extensions before starting to play with Cairngorm;
• Cairngorm 3 is quite recent – so Cairngorm is not (yet) deprecated, even if the alternatives seems better (by alternatives I mean pureMVC, Mate, Parsley, etc);
• if you haven’t done so until now, you should take a look to the official article which introduces you into Cairngorm.

Since I’ve mentioned the debate over Singleton, I’m inviting you to read this and then this. I’m not going to take sides over this debate (too) – I’m so in love with Singleton and so far from puristic approach to design pattern. As long as you are carefully about excessive use of Singletons and you strive to respect the loose coupling between classes, you will be fine – and the day when Singletons will disappear from your code is not that far.

Now, there are two things that you will need in order to complete your Cairngorm terms : one is the Mediator. Shortly said a mediator is a class two other classes, so those two won’t couple themselves. You can find a way (and the explanation) to do it here.

Also, you will need some sort of substitute for the Observer pattern. The closest class to that is the following (the code is not my creation – I took it from somewhere, but I cannot remember where – my apologize to the author):

public class Observe extends Observer {
		private var _handler : Function;
		private var _source : Object;
		override public function get handler() : Function {
			return _handler;
		}
		public function set handler( value : Function ) : void {
			_handler = value;
			if( value != null ) {
				isHandlerInitialized = true;
				if( isHandlerInitialized && isSourceInitialized ) {
					callHandler();
				}
			}
		}
		override public function get source() : Object {
			return _source;
		}
		public function set source( value : Object ) : void {
			_source = value;
			isSourceInitialized = true;
			if( isHandlerInitialized && isSourceInitialized ) {
				callHandler();
			}
		}
	}
 
public class Observer {
 
		protected var isHandlerInitialized : Boolean = false;
		protected var isSourceInitialized : Boolean = false;
 
		public function get handler() : Function {
			return null;
		}
 
		public function get source() : Object {
			return null;
		}
 
		public function execute( method : Function, ...params : Array ) : Object {
			var returnValue : Object;
			try {
				returnValue = method.apply( null, params );
			}
			catch( e : Error ) {
				trace( e.message );
			}
			return returnValue;
		}
 
		protected function callHandler() : void {
			try {
				handler.call( null, source );
			}
			catch( e : Error ) {
				trace( e.message );
			}
		}
	}

How you will use it ? Simple : let’s say you need to observe some property of a instance child. You’ll use binding to set the Observe source property and declare a handler for that (e.g. :  < mx: Observe source = ” { someChild.someProp } ” handler = ” onChildPropChanged () ” / > ). As you can see, this is not a design pattern, but a trick to achieve as close as possible the same effect.

Last but not least, you’ll have to know about you might bump into while using Cairngorm:

• you will not be happy about not being able to notify events to the view. Dispatching events from commands and listening them in the view seems like a good idea – but after a degree of complexity this will surely get in your way. Writing a Singleton which can cover the register-me-for-event the way FrontController is doing it might be a much clearer solution – of course, keeping them separately so you can easily locate them.
• you will be angry with the number of small classes containing commands and events. There are workarounds for this one that you can google. My technique is to declare all the event names in a static manner and use only the CairngormEvent, without creating more classes – you’ll get annoyed by the type casting anyway. Another thing that you can quick to is to extend the CairngormEvent to add a class property so the getter of data will type cast itself (as I’ve said in part II).
• on large applications, use case handling and reacting to state becomes overwhelming for the number of views you have to cover – very hard when you have to debug. Making one big view could help you with that – also you might want to introduce new design patterns for this, e.g. State Machine.

Of course, this is not everything that might get into troubles, just what I could recommend you right now – but I would like to hear from you if you need my help with something.

Before ending this post, I’m recommending you to read an article about PureMVC – of course, once you’ve absorbed all there is to know from Cairngorm.

No, let’s continue our discussion about principles, Cairngorm principles. As a general advice for studying somebody’s else code, you should always start with looking at the events. But first, let’s discuss the package names (which will be the same for your application skeleton) : business – contains service classes , commands - contains the application commands , control - contains the events , event dispatcher and the application controller , model - contains the application’s data, view - will get filled with GUI components , vo – will be filled with value objects for the business engine.

Let’s open the CairngormEvent.as to take a look inside : as I’ve said in the previous post, a CairngormEvent has the ability to dispatch itself – the public method dispatch calls for the CairngormEventDispatcher (which is Singleton) and do it – between us, doing so assures that the event in not a volatile object, eaten away by the Garbage Collection (I’ve seen some nasty bugs related to this). There is something even more interesting (for those of you who never thought that you can do so) in the CairngormEvent class – the public property data, which allows you to pass the reference to an object with the event – the data passed can be used by other listeners, but there is a catch : the listeners will have to know that object’s type.

So, we can make some corrections to this class, in order to make it more OOP principles compliant : first, we could add to the constructor another parameter (by default null) to declare the carried object. Secondly, we could use a setter getter for the data property – thus respecting the encapsulation. We can also define a cast property, making the data getter return data as cast (the lazy way to avoid writing every time this inside some other class).

Paying a visit to the CairngormEventDispatcher.as will bring to our attention the following : first, it is a Singleton which makes use of an instance of EventDispatcher (through it’s interface IEventDispatcher) which will do all the dispatcher work. You can notice that this class could declare it’s implementation to IEventDispatcher, since all the required methods are declared.

FrontController is the class which you will need to extend to create your application controller – it will basically associate an event to a command – when that event occurs (usually as a result as a user interaction with a GUI component) the associated command will get triggered – which will affect either the model, either will create a delegate which will make a service call and return the result to that command (which will modify the model, of course).

Using a Dictionary of commands, the FrontController doesn’t need to iterate through an array when it needs to execute that command. Adding a command (registering it) creates a dictionary entry with the name of the event associated with the reference to the command class which is associated to it – looking first for the uniqueness of that event name. I’m advising you to take a good look of this technique – you might find it very useful and applicable somewhere else, for example a large collection of value objects which has the constrain to identify unique objects very fast.

The above classes represents the main event engine behind Cairngorm – simple, yet very efficient.

The Command class will get extended for each and every command your application needs – as previously explained. As you saw inside the FrontController, every event will create a new instance of the associated command and a call to the execute method will be made. The SequenceCommand class will be extended when you need to execute a chain of commands as a consequence of a single event – which is pretty useful when your application needs to load or alter relational data.

There is not much to say at this moment about ModelLocator and its interface IModelLocator , because you will organize your application’s model after its needs – the most important principle is that the GUI elements will bind to the declared properties (and don’t be afraid to use complex properties like extensions of ArrayCollections – but never ever dispatch events as seen in many applications). The ValueObject class is deprecated since version 2.1 of Cairngorm – so don’t bother to look at it. If you need to improve your code readability you can use the interface IValueObject – meaning that you can point out a generic value object where needed (assuming that that value object will evolve and you don’t need each and every single property of it).

Getting to the view related classes, ViewLocator will be used to register GUI components since ViewHelper is deprecated. As you can see, the same technique is used for registering GUIs to this Singleton class as in FrontController’s case. Commands which will interfere with the GUIs does not need to know the name of it, but it will use the ViewLocator which will return the instance of that class – so it will can manipulate it. You will see in some other MVC frameworks like pureMVC that a mediator is used to control a GUI element, but Cairngorm has no notion of it.

After you’ll get some experience in getting yourself organized after the Cairngorm principles, I’m convinced that you will find your way of adding more patterns to it – in order to become your pattern. For now, it is important that you, as a “young padawan” to concentrate over respecting basic principles, to make use of data binding and change watchers (knowing exactly what you do – recommended reading is about propertyChange events dispatched). Don’t listen to people which says “data binding is bad” and be careful what you learn – think how easy it is to learn something the wrong way, but how hard it is to forget it afterward.With patience and a strong will for experimenting (let’s say you will decide to refactor one of your projects to Cairngorm) you will get to the point where you’ll have a lot of alternatives and solutions by your side.

I will continue “the Way I See It” series with the last part of Cairngorm, trying to point out some of the improvements that other developers created for it.