Posts in Category "Flex"

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.

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.

Fade to Gray Modal Window Flex Effect

I’ve always liked the effect Windows XP gives you when you select Shut Down… and it then gives you the Shut Down, Restart, Log Off etc options in a modal window. If you leave that window in place for a second or so, your desktop slowly fades to gray while your modal window stays full color. I’ve been wondering for a while whether that effect was possible in Flex.

So, the simple answer is yes. Wait for this example to load, hit the Launch Popup button and watch the background image (you’ll need Flash Player 9).

So, how does it work? Flex 2′s PopUpManager class has an undocumented internal property called modalWindowClass. By setting that property to a class definition of your choosing, an instance of your class is created when you create a modal popup window. This instance sits “behind” your modal popup, affecting the appearance of the application. These windows are often called popup blockers.

I’ve created a popup blocker class (SaturationFadePopUpBlocker) that uses a new SaturationFade effect I’ve also written. The SaturationFade effect changes the color saturation level of component that is the target of the effect using an instance of the Flash Player’s ColorMatrixFilter.

To add the popup blocker to a Flex 2 application is very simple. The following is the single line of code that is required add the above popup blocker effect (alongside the need to import the necessary classes).

PopUpManager.mx_internal::modalWindowClass = SaturationFadePopUpBlocker;

The SaturationFadePopUpBlocker and SaturationFade effect classes can be downloaded as a Compiled SWC (inside this zip) or as a Flex Builder Library Project. The Library Project includes the compiled SWC and all the source code.

Although this example fades the background to gray, the SatuationFade effect I have written lets you change the color saturation of a component to any level, including making it brighter. The start and end saturation levels, along with the duration of the saturation fade, are all customisable in the Saturation effect and SaturationFadePopUpBlocker classes.

The SaturationFade effect class can also be used as a standalone effect, in place of any of the existing Flex framework effect classes. In this example, the SaturationFade effect plays when you hold your mouse down over the image, with the color saturation level fading from 1 to 0. The saturation level animates back to 1 when you let the mouse go:

The code for the above example is:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:eff="com.adobe.effects.*" >
<mx:Script>
<![CDATA[
import com.adobe.effects.SaturationFade;
]]>
</mx:Script>
<eff:SaturationFade id="fadeToGray" duration="500"
saturationFrom="1" saturationTo="0"  />
<eff:SaturationFade id="fadeBack" duration="500"
saturationFrom="0" saturationTo="1" />
<mx:Image mouseDownEffect="fadeToGray" mouseUpEffect="fadeBack"
source="sunset.jpg"  />
</mx:Application>

I won’t go into detail about the implementation of the classes for now. The SaturationFadePopUpBlocker class is very small and should be fairly self-explanatory to most people. If there’s a demand, I’ll do a future post about creating effects using the Flex effects framework and, in particular, how the SaturationFade effect works.