Author Archive: Alistair McLeod

Cairngorm 2.2 – Front Controller Weak References

In a continuation on my series of posts covering the recent Cairngorm 2.2 release, today I’ll give the motivation behind another one of the changes that we made in the MVC micro-architecture for Flex: weak references in the front controller.

In Cairngorm 2.1, the base FrontController class added itself as a listener onto the CairngormEventDispatcher as follows:

CairngormEventDispatcher.getInstance().addEventListener( commandName, executeCommand );

meaning that, when Cairngorm events are dispatched at various places throughout the Flex application, the controller would be notified, and the executeCommand() method called. However, the line of code above added the controller to the CairngormEventDispatcher as a hard reference, meaning that the controller would never be eligible for garbage collection while the CairngormEventDispatcher was still in memory.

Fast forward to the release of Flex 2.0.1 and the addition of Module support to the Flex framework. This feature gives us the ability to load and unload parts of our application, dynamically, at runtime. With Cairngorm 2.1, if someone wanted to create a Cairngorm application as a module, even if that module is unloaded, the controller would never be eligible for garbage collection because the CairngormEventDispatcher (which is a singleton, and therefore global) still has a hard reference onto it.

So, in Cairngorm 2.2, we have made, by default, the addition of the controller to the CairngormEventDispatcher as a weak reference. Holding objects as weak references means that the object will be eligible for garbage collection if the only references to it are weak.

Now, when the FrontController is unloaded, and assuming that all other hard references to it have also been removed, the controller will be eligible for garbage collection, because the CairngormEventDispatcher only has a weak reference onto it.

You can still decided to add the controller as a hard reference to the CairngormEventDispatcher, via a parameter of the addCommand() method of FrontController, but I see little need for that.

There is one final point to add here. The ASDoc for the addCommand() method of FrontController states that the command is added as a weak reference to the controller. That is just plain wrong and I hold my hand up to that – the comments were added in a rush just before I did the final build, instead of when I did the code change. The docs will be fixed in the next release.

Cairngorm 2.2 – Self Dispatching Events

Cairngorm 2.2, the latest version of the Flex micro-architecture, released on Friday, was a fairly minor release with just a few new features and minor fixes.

However, I thought it would be worthwhile for me to document the motivation behind some of the changes.

Today, I’ll give a quick overview of self-dispatching events, which were added to the 2.2 release.

With Cairngorm versions up to and including 2.1, to dispatch an event that would be handled by your controller, you had to do the something like this:

var loginEvent : LoginEvent = new LoginEvent( username, password );
CairngormEventDispatcher.getInstance().dispatchEvent( loginEvent );

If you had many events in your application, this became a pretty long-winded way of doing something as simple as dispatching an event.

With Cairngorm 2.2, we’ve added a helper method to CairngormEvent, which all your controller events should extend. Now, you can do the following:

var loginEvent : LoginEvent = new LoginEvent( username, password );
loginEvent.dispatch();

Or even:

new LoginEvent( username, password ).dispatch();

Its a matter of personal style on which of these two you prefer, but they both give much more clarity to your code and (more importantly for some) need less typing.

Cairngorm 2.2 Released

The beta version of Cairngorm 2.2 for Flex has been kicking around for some time now, and, on Friday, I eventually got around to getting the release version up on Adobe Labs. You can read the release notes here.

The main change in this release is the externalisation of dependencies on the Flex Data Services library (fds.swc) to a separate set of downloads called Cairngorm Enterprise.

The full list of changes in this release are as follows:

  • Removed dependency on Flex Data Services (fds.swc) – externalised to Cairngorm Enterprise
  • Flex SDK SWCs are no longer linked into Cairngorm.swc (produces a smaller Cairngorm.swc)
  • Added support for setting remote credentials
  • Fixed bug with Web services not loading the WSDL (no need to call loadWSDL() explicitly)
  • ModelLocator interface has been deprecated. Added com.adobe.cairngorm.model.IModelLocator
  • Added deprecation metadata for compiler support
  • Added dispatch() helper method to CairngormEvent class
  • Commands are now added to base Controller with weak references
  • Added removeCommand to FrontController
  • Made commands instance variable protected in FrontController (was private)

If you want a more general overview on what Cairngorm is, and what it can do for you, visit the Cairngorm page on Adobe Labs.

I’ll give the motivation behind many of these changes in future blog posts.

FlexCoders Posting Volumes – Latest Figures

Back in September 2006, I posted a graph which showed the meteoric rise in the number of posts to the Flex maling list, FlexCoders.

A few months on, I thought it was time to post an updated graph. Here it is:

You can see that July 2006 was a particularly strong month for growth, and that although there are expected variances (eg, over the festive period), there is still a feverish amount of activity surrounding Flex.

I’ll post another update in a few months time.

Flex Automation (My Max Talk)

Its been brought to my attention that I never got around to posting the presentation slides from my Max talk in Las Vegas last year. The talk was on Flex Automation, and covered, amongst other things, Automatic Build Systems, the Automation of Flex Unit Testing and Flex Functional Testing with Mercury Quick Test Pro and the Flex QTP Plugin (which was then in beta, but has since been released as part of Flex 2.0.1).

The presentation can be downloaded from here. I hope someone finds it useful.

Some of what is covered in the presentation has been augmented by the work Peter Martin from the EMEA Consulting group has done on his blog. In particular, if you want to keep up to date with the work we’re doing on testing and continuous integration, keep an eye on his blog.

Don’t Live With Broken Windows

I’ve been doing a fair bit of air travel recently, for both internal meetings and for client engagements, and, over time, the experience gets rather repetitive. Invariably, flights get delayed, queues start forming and people get stressed out.

The queues are one thing I have gotten used to, particularly in these days of heightened security, and I usually find my eyes wandering to the area around me. My mind usually follows.

On one such occasion recently, I was in (yet another) queue in Heathrow airport. It was at security this time and, being Heathrow at the busiest time of the day, there was the minimal number of staff requried to man the X-Ray machines.

As I contemplated life, my eye was drawn to pillar holding up the ceiling. Now, the pillar wasn’t particularly interesting (though it was a handy distraction from the tedium of queuing), but what was noticable was the pile of rubbish on the floor around it – coke cans, candy bar wrappers, empty sandwich packets. All kinds of rubbish, just left there, doing nothing (except somehow causing me to write this, I suppose).

Anyway, there was seemingly no logic as to why people had decided to place rubbish there – there were plenty of places prior to that point where people could dispose of items they couldn’t take through security.

So, why was the pile of trash there? I beleive the answer lies in a book called The Pragmatic Programmer, in the section entitled Don’t Live with Broken Windows.

Consider a building with a broken window. If the window is not repaired quickly, the tendency is for vandals to break a few more windows, over time. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or even do much more damage.

The area I saw in Heathrow airport was the litter equivalent of a Broken Window. On uncaring soul had left one piece of litter by the pillar. Someone else came along and did the same. After a while, the pile of trash started sending out the message: “It’s okay to leave your unwanted rubbish here”.

The experience made me think about how we develop software; do we do enough to ensure that our software doesn’t have any Broken Windows? It’s been 5 or 6 years now since I read the book, but I’ve added it to my list to read again; it is a very good read and contains many good tips that software engineers should always keep at the back of their minds.

So, next time you write some software, either from scratch or make some changes existing code, always be on the lookout for broken windows. Sometime’s they’re so obvious that you see right through them.

Flex Scheduling Framework – Available on Labs

With everything going on at Max, others have already beaten me to the announce that the Flex Scheduling Framework is available on Adobe Labs, but for people coming back to my blog to check on progress, I thought it best to announce here too.

So, go check it out and let us know what you think.

Flex Scheduling Framework – Adobe Labs Release

A couple of months ago, I announced the creation of an Open Source Calendar Component for Flex 2.

Despite saying at the time that it’d be ready when its ready, I’ve been pretty much inundated with requests asking whether its ready, when it would be ready, why it wasn’t ready or could an early version be made ready. I nearly added the word ready to my email spam filter.

However, during the intervening time, something else happened; my thinking around what ready meant actually changed – I realised that it wasn’t just a Calendar Component we were building, but a fully fledged Scheduling Framework. I also realised that saying whether it was ready or not was not really my decision.

You see, a framework like this cannot just be built with no regards to how it will be used. We’ve built some samples which we’ll be releasing alongside the framework, but it’ll be the real-life applications that will truly test-drive the APIs, the scalability and the performance of the framework.

So, I’ve decided the framework won’t be released when its ready after all; it’ll be released when its nearly ready. And nearly is within the next couple of weeks, hopefully by the time I’m presenting at Max 2006.

It has also been decided that this early-release version of the framework will be released on Adobe Labs.

So, keep an eye on my blog and I’ll let you know more soon. In the meantime, here’s another screenshot of the Scheduling Framework in use.

calendar.gif

Flex 2 and Automation – My Max Talk

Max 2006, the Adobe Conference, starts in a little over two weeks and I’ve been putting the finishing touches to my talk.

This year, I’ll be talking on Flex 2 and Automation.

Some of you may be asking what Automation is. Without pre-empting my talk, automation is the automatic control of software, be that building, running or testing.

A large part of my talk will center around automation and testing. In particular, I’ll talk about and show a demonostration of Mercury Quick Test Professional being used to control a Flex application, as a means to functional testing.

I am seriously impressed with what the Flex product team has done in their efforts to make Flex applications testable in this manner and I’d urge enterprise development teams to consider its use.

If you haven’t already signed up to go to Max, you’d better hurry up. Did I mention that it’s in Las Vegas – what better excuse do you need? Who knows, you might even bump into Elvis…

Flexcoders – Message Volume Flex Graph

I was doing some administration on the FlexCoders mailing list today, when I noticed the statistics showing the number of posts per month. Now, this isn’t new information, but I wondered what it would look like in a Flex graph. So, here it is:

As well as graphing the number of posts per month, I also added a moving average series in there too – just because I could ;)

Apart from a few downward spikes during the holiday seasons, there has been unrelenting growth in the number of posts to the group since iteration::two started it two and a half years. However, the main point of note is that the growth since Flex 2 beta was released is quite phenominal, with the number of posts per month almost three times what it was in that time.

I’ll revisit this in a few months time, to see if the Flex community continues to grow at this pace.