Developer's Blog

I’m happy to hear that AIR 2 beta 2 is out. You can get it here and read about it here. Some of the newest features are sampled here and you can see a video about the new printing features here.

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.