Alistair McLeod: Flex Archives

December 8, 2008

Max Presentation - Flex Development with Cairngorm

At Max Milan last week, I gave a presentation on Flex Development with Cairngorm. The presentation was based largely on the "Cairngorm: Tips and Tricks from the Experts" presentation my colleagues Peter Martin and Eric Garza gave at Max in San Francisco, but after seeing the number of hands raised when Peter asked who was using Cairngorm, I thought I'd change the emphasis (and the content) a bit for the Milan audience.

I wanted to answer a number of common questions surrounding Cairngorm:

* How do I get data from my Commands to my Model?
* How do I get data to my view?
* How can I be notified that new data has arrived on the view?
* How should Responders be implemented?
* How should I use the Model Locator?

So, the presentation is split into three main sections:

1) Cairngorm Overview

The first section is a back-to-basics introduction to Cairngorm, but with a twist. If you've been following some of the Adobe Consulting blogs recently, you'll have seen us talk about the Presentation Model pattern. Another of our consultants, Paul Williams, covered this in his well received series of Presentation Patterns and I show how the Presentation Model fits in with the standard Cairngorm Data Flow.

Cairngorm Data Flow

2) Cairngorm Best Practices

In the second section of the presentation, I provide some Adobe Consulting best practices for the use of Flex and Cairngorm, based on our many and varied engagements on mid to large scale enterprise applications.

The main topics covered are:

* Using the Presentation Model
* Using the Model Locator
* Events, Commands, Responders
* Updating Views with Data

During the talk, I went into detail on the Presentation Model in particular, and how it addresses many of the common questions we hear on handling data in Flex applications.

Presentation Model

I also touched on unit testing with Cairngorm, Cairngorm and Modules, and Cairngorm and Data Management Services (part of LiveCycle Data Services).

3) Cairngorm Myths and Anti-Patterns

The presentation also gave me the opportunity to challenge a number of the misconceptions and misunderstandings I have seen on blog posts and architecture face-off discussions at conferences. I also spoke about some of the recurring mistakes we see people make when using Flex and Cairngorm. I covered the following:

* Do I Always Need to use a Framework?
* Do I Need to use every Cairngorm Pattern?
* Business Logic in Cairngorm Classes
* Use of the ModelLocator
* Use of Commands and Responders
* Use of the Controller

I hope to find time to provide more details on these best practices and myths in future blog posts.

At Max San Francisco, Peter Martin also announced the launch of the Cairngorm Plugin for FlexBuilder to allow the quick creation of FrontControllers, Events and Commands. The presentation ends with some details of that, and some road-map details.

Cairngorm Plugin

My Max Milan presentation can be found on Adobe acrobat.com, here. You can download it via the Download link near the top-right of that page.

Posted by amcleod at 2:31 PM | Comments (4)

August 21, 2008

FlexUnit on Adobe Open Source

Following on from the news that Cairngorm has been moved to Adobe Open Source, it is my pleasure to announce that FlexUnit, the unit testing framework for Flex applications, now has a new home on Adobe Open Source.

FlexUnit started its life almost 5 years ago, when I first wrote AS2Unit; at that time, it home was the iteration::two website. FlexUnit was borne from that project, and was released shortly after Flex 1.0 in March 2004.

With the release of Flex 2, a team from Adobe Developer Relations migrated the framework to ActionScript 3 and gave it a new home on Adobe Labs. However, it was soon on its move again, and ended up on Google Code as a 0.85 release of as3flexunit.

Since that time, a number of bugs have been identified, and a number fixed, but there has been no real visibility of ownership; no-one has the responsibility to build and test and release new versions to the community and the 0.85 version is fast approaching 2 years old.

We see this move as bringing FlexUnit back to its Adobe home, where it can get the attention and care it deserves.

Adobe Open Source brings a number of benefits:

* Source available via a Source Control System (Subversion)
* Availability of a bugbase for bugs and enhancement requests (JIRA)
* Developer forums for the discussion of features and roadmap
* Ability to submit code patches

Alongside this move, we've also taken the opportunity to do some bug fixes and have also add some new features to FlexUnit. The codebase for this release is based on revision 20 from Google Code. We realize that there have been a few subsequent changes made to that codebase since we had to branch to make our own bug fixes and enhancements, and we look to the community to reintegrate any of these changes, as necessary. We have chosen to go down this route rather than delay the release further.

The most visible set of changes to FlexUnit, and something you've probably already noticed from the screenshot above, is in the graphical test runner, designed by the User Experience team at Adobe Consulting.

Within the runner, we've added more information about the tests being run. We've provided the average number of asserts per test case, and also the number of asserts in each individual test case.

When tests do fail, we've extracted the failure information to make it clearer to the user, and, so long as you have compiled your tests with debug set to true, and are running with the debug flash player, you will also see the stack trace, to give that extra level of information not necessarily previously available.

Finally, you can now also filter your test results, for those larger projects where you have hundreds of test cases.

You can filter on individual test case names, test names, expected results or actual results, and also choose to see results based on all test cases, only those with errors or failures, or just empty test cases.

We are incredibly excited about this move, and look forward to the community getting involved through the submission of enhancement requests, code patches, documentation and taking part in the discussions around FlexUnit.

I was hoping to contact the project members of the existing as3flexunit project; unfortunately, Google Code does not let me easily identify the current members. So, if you wish to contribute to the project, please contact me.

The FlexUnit home page on Adobe Open Source can be found here.

Posted by amcleod at 10:00 AM | Comments (8)

August 14, 2008

Cairngorm on Adobe Open Source - One Week On

So, Cairngorm has been on Adobe Open Source for over one week now, and I thought I'd summarize what's happened since.

It has been interesting to watch the community response to my announcement. To Adobe Consulting, this was a move of an already open source project from Adobe Labs to Adobe Open Source, but while the response has been extremely positive, many of the reports read as if Cairngorm becoming open source was something new.

I guess this says something about our previous messaging, and the fact that the setup on Adobe Labs wasn't the same as Adobe Open Source, where we now a full source code hosted on Subversion and available to all, rather than a single ZIP download of the source.

As i explained in my announcement, we made a conscious decision not to add any new features in the process of the move. We did, however, provide the facility for community feedback, and already, we've had a good amount of involvement.

Over on the Cairngorm Forums, we've had various discussions, including those on creating a test suite for Cairngorm, tooling support for Cairngorm within Flex Builder and how we should approach extending Cairngorm.

The Cairngorm Bugbase has sprung into life too, and Christophe Herreman has already submitted patches containing some initial unit tests, alongside two other bug reports with patches. We've also had an enhancement request, for better support for Cairngorm with Flex Modules.

JIRA, on which the Cairngorm bugbase runs, has a voting facility, so please get invovled, and vote on the bugs and enhancement requests you think should be part of a future release.

What next?

A team from Adobe Consulting met on Monday of this week to discuss the Cairngorm roadmap, both in the short-term, to apply the patches provided and ensure Cairngorm is fully up to date with the latest releases of the Flex SDK, BlazeDS and LiveCycle Data Services, and also looking to the future, and Cairngorm 3.

We'll be socializing our thinking over the coming weeks

In the meantime, we encourage you to get involved in the discussions taking place on the forums or to submit enhancement requests to the bugbase.

Posted by amcleod at 10:20 AM | Comments (1)

August 6, 2008

Cairngorm Moved to Adobe Open Source

Adobe Consulting is pleased to announce that the Cairngorm Micro-architecture has moved onto Adobe Open Source.

Its hard to believe that Cairngorm is approaching 4 years old - Steven and I announced it at the Max conference in New Orleans in October 2004 and the first version was released soon thereafter.

We've gone through a number of different versions since then, but each one has always held true our vision: Provide a lightweight MVC architectural framework around which to build Rich Internet Applications with Adobe Flex or Adobe AIR.

The latest version, Cairngorm 2.2.1, was released back in October 2007 and, although we at Adobe Consulting consider that being a good reflection as to the maturity of the framework, there have been some questions on when the next release would be made available and what new features it would have, alongside some specific feature requests.

At Adobe Consulting, we've always had a minimalist approach to Cairngorm; we don't want to add feature for feature sake, add functionality that doesn't belong within an architectural framework, or introduce another design pattern into the mix because it's the latest fad in the software industry. The framework is there to allow us to build well-architected software solutions, and we've only ever added features we truly believe helps us do that.

There are no new features in this release - at this time we are simply moving Cairngorm 2.2.1 from Adobe Labs to Adobe Open Source.

However, we do listen to the community and to our customers, and this announcement is in response to this invaluable feedback. We hope that this launch will emphasize the commitment that Adobe has to the framework, and reinforce the message that the framework is the one that Adobe Consulting visibly advocates.

There are many benefits to having Cairngorm on Adobe Open Source. Alongside having a well defined home for downloading the framework, its documentation and samples, Adobe Open Source also provides additional resources one would expect of an open source project:

Alongside this move, we are also introducing a level of governance, a charter that explains how the Cairngorm project will be managed, and how leaders in the Flex community can get involved in the project.

We are also extending an open invitation to the community to submit bugs or feature requests and take part in the Cairngorm discussion forums.

The community has read-only access to the Cairngorm source code by default, and contributors will also be able to submit code patches.

We are incredibly excited about this move, and look forward to the community getting involved in the framework, through the submission of enhancement requests, sample applications, code patches, documentation and taking part in the discussions on the future direction of Cairngorm.

The Cairngorm home page on Adobe Open Source can be found here.

Posted by amcleod at 12:50 PM | Comments (7)

November 14, 2007

Cairngorm - Commands and Responders

Recently, I've seen a few questions around Cairngorm and how commands and responders fit together when using asynchronous services with Flex. I'd like to clarify a couple of points.

A Command need only implement the Flex IResponder interface if it is to be the responder for an asynchronous service call.

This is probably obvious to many, but I've seen Command classes which implement IResponder, but don't do any ansychrnous service calls and have empty result() and fault() methods. In this cases, the Command should implement the ICommand interface only and not the IResponder interface.

The Command class does not have to be the responder for asychronous service calls.

I've not seen many implementations like this, but the Cairngorm command pattern is designed in such a way that your responder can be an instance of another class, as in this example:

public class AddTaskCommand implements Command
{   
  public function execute( event : CairngormEvent ):void 
  {
    var addTaskEvent : AddTaskEvent = event as AddTasksEvent;
    var task : Task = addTaskEvent.task;

    var addTaskResponder : AddTaskResponder = new AddTaskResponder( task );
    var delegate : TaskDelegate = new TaskDelegate( addTaskResponder );
         
    delegate.addTask( task );                  
  }
}

public class AddTaskResponder implements IResponder
{
  private var task : Task;
   
  public function AddTaskResponder( task : Task )
  {
    this.task = task;
  }

  public function result( event : Object ):void 
  {
    //handle the result here
  }

  public function fault( event : Object ):void 
  {
    //handle the fault here
  }
}

This implementation allows better separation of logic and potential reuse of responders, and also makes things easier to test.

Posted by amcleod at 10:14 AM | Comments (7)

October 8, 2007

Cairngorm 2.2.1 Released

After a few months of being in beta, Cairngorm 2.2.1 for Flex has been released on Adobe Labs.

There is nothing new in this release over previous releases; it's only purpose is to align Cairngorm with the moving of SWC libraries in Flex 2.0.1 with Hotfix 2 and LiveCycle Data Services 2.5.x.

Posted by amcleod at 5:23 PM | Comments (4)

June 29, 2007

Flex Scheduling Framework - Now on FlexLib

The Flex Scheduling Framework, previously on Adobe Labs, now has a new home, as part of the FlexLib project on Google Code.

The Flex Scheduling Framework was borne out of Adobe Consulting engagements, as is not part of the Flex SDK. As such, maintenance and bug fixes were mainly community led, with Adobe Consulting staff members spending their own time to apply any fixes.

The latest release on FlexLib includes a number of bug fixes when compared to the original version that appeared on Adobe Labs. I'd like to give a thanks to those people who identified bugs and submitted fixes, and to Alex Uhlmann who applied those fixes, and some of his own, to the framework before we handed it over to FlexLib.

FlexLib contains a full source code repository, so if you want to see any new features as part of the Flex Scheduling Framework, download the source and submit your proposed changes back, for inclusion in the code repository and subsequent framework builds.

The full set of ASDocs for the Flex Scheduling Framework can be found on FlexLib, but other content is quite light on Flex Lib at present - we will migrate the Adobe Labs content to FlexLib over time.

As always, your feedback is welcome.

Posted by amcleod at 3:35 PM | Comments (4)

May 30, 2007

New Release - Cairngorm 2.2.1 for Flex 2.0.1 with Hotfix 2

I posted last Friday about the release of Hotfix 2 for Flex 2.0.1, and how the moving of classes between the core Flex SDK and LiveCycle Data Services was causing a compiler error unless you had fds.swc on your library path.

The fix at that time was to include fds.swc on your library path, even if you did not use or need LiveCycle Data Services 2.5.

I've now created a new build of Cairngorm and Cairngorm Enterprise that is aligned with the new packaging of Flex 2.0.1 with Hotfix 2 applied and with LiveCycle Data Services 2.5. This packaging should also work for standard Flex 2.0.1 installations.

I've had to put this package together quite quickly and full testing hasn't taken place, so this release is a Beta for now.

The only change in this release is the moving of the Consumer and Producer service locator methods from the base Cairngorm ServiceLocator into the Cairngorm Enterprise EnterpriseServiceLocator class.

You can download the packages here:

I've leave these package on this blog for now, until feedback has been received, and then I'll get them moved over onto the Cairngorm page on Adobe Labs.

Posted by amcleod at 1:13 PM | Comments (8)

May 25, 2007

Flex 2.0.1 Hotfix 2 and Cairngorm

Flex 2.0.1 Hotfix 2 has been released today, containing a collection of Flex 2.0.1 bug fixes.

As part of this release, some classes, which are not required as part of the core SDK, have been moved into Flex Data Services (FDS), now rebranded LiveCycle Data Services 2.5 (LCDS 2.5) and newly released.

However, because the ServiceLocator class of Cairngorm has a soft reference onto the Flex framework's Consumer class, applying Hotfix 2 will cause the following compiler error in your Cairngorm application, unless you have fds.swc on your classpath.

1046: Type was not found or was not a compile-time constant: Consumer.

We will be releasing another version of Cairngorm and Cairngorm Enterprise, which will align themselves with the new class locations in Hotfix 2, and also be compatible with the standard Flex 2.0.1 release. In the meantime, if you update to Hotfix 2 or switch to LiveCycle Data Services 2.5, ensure you have fds.swc on your classpath. You can get this from the new LiveCycle Data Services 2.5 release.

Posted by amcleod at 5:06 PM | Comments (7)

May 17, 2007

Cairngorm 2.2 - Cairngorm Enterprise

In today's post about the recent release of Cairngorm 2.2, I'll give the reasoning behind the most obvious change made to the distrubution of the framework - the splitting of it into two parts, Cairngorm and Cairngorm Enterprise.

The main reason for the change at this time was to remove Cairngorm's dependancy, introduced in Cairngorm 2.1, on the Flex Data Management Services library, fds.swc. This dependency forced developers to download Flex Data Services, even if they were using Cairngorm with a relatively simple applications that used RemoteObject, HTTPService or WebService only.

Mea culpa, as they once said.

However, this change also hints at the longer term roadmap view of where Cairngorm is heading.

Our vision is that Cairngorm will have a core framework, which mid-sized applications will use. Alongside that, we foresee the need for a set of additional modules, for use in enterprise-scale applications.

These modules will contain repeatable, best-practice solutions to common application problems and will address areas such as:

Extended support for Flex Data Management Services
Extended support for Flex Messaging Services
Platform specific module for Apollo
Product specific module for LiveCycle Enterprise Suite
Security and authentication modules
Others we haven't thought about yet

The modules could vary in architecture, from a simple set of command, delegate and service definitions, or even some server side Java code (eg, for LiveCycle ES), through to new sets of classes that implement the common patterns we see emerging in our solutions.

We expect the modules to surface as best practices out of our day-to-day consulting work, rather than by us attempting to determine the solutions upfront. As such, we cannot commit to any specific date for any new features, but we can say that they will remain free and open-source.

As always, we welcome your feedback on our thoughts.

Posted by amcleod at 2:40 PM | Comments (1)

May 3, 2007

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.

Posted by amcleod at 11:16 AM | Comments (6)

May 1, 2007

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.

Posted by amcleod at 12:09 PM | Comments (7)

April 30, 2007

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.

Posted by amcleod at 4:31 PM | Comments (13)

February 1, 2007

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.

Posted by amcleod at 1:46 PM | Comments (5)

January 19, 2007

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.

Posted by amcleod at 10:23 AM | Comments (2)

October 24, 2006

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.

Posted by amcleod at 9:02 PM | Comments (4)

October 16, 2006

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.

Posted by amcleod at 6:35 PM | Comments (13)

October 6, 2006

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...

Posted by amcleod at 3:42 PM | Comments (13)

September 7, 2006

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.

Posted by amcleod at 5:50 PM | Comments (7)

August 31, 2006

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.

Posted by amcleod at 6:50 PM | Comments (59)

August 22, 2006

Open Source Flex 2 Calendar Component

A regular discussion on Flex forums such as FlexCoders is the availability, or otherwise, of a good Calendar component for Flex 2.

So, it is with great pleasure that I can announce that the Adobe Consulting team in EMEA will be releasing an open source Calendar framework to the community within the coming weeks.

This is a framework the team here have been working on for a while and Alex Uhlmann is putting the finishing touches to.

Below is a screenshot of a simple Calendar built on top of the framework, which uses the default renderers for the calendar entries and timeline.

Don't be deceived by the basic look of this example calendar and its surrounding controls - the calendar is built on top of an extremely powerful framework which can be used to build very complicated scheduling components and we've spending the majority of our time working on that rather than this example. However, we do plan to ship some better examples with the framework.

Some of the features of the Calendar framework are:

Display and manipulate 1000s of calendar entries without losing performance.
Define how entries are laid out using the predefined layout manager or by providing your own customized layout manager.
Assign custom renderers that can dictate the complete look and feel of your calendar entries.
Provide renderers in MXML or ActionScript.
"Live" zoom support using zoom API.
Use framework effects such as Zoom and Move to make best use of the expressiveness of a Flex RIA in order to achieve the best user experience possible while navigating the component.
Efficiently add, remove and update entries at runtime.
Assign customized background areas to show office hours, lunch time etc
Fully stylable
Ability to select calendar entries with visual highlighting
Consistent in usage with the Flex Framework, eg. dataProvider driven
Broadcasts events to help interaction development
Can be used in MXML or Actionscript
And more...

To give a glimpse of the API of the calendar, here's the MXML used to create the above example. However, please note that we are still defining the API, so it may change in the final version.

<scheduling:CalendarViewer 
   id="calendar"
   width="600" height="400" 
   dataProvider="{ appointments }"
   startDate="{ new Date() }"
   duration="{ DateUtil.DAY_IN_MILLISECONDS }" 
   zoom="{ zoom }"
   itemRenderer="com.adobe.scheduling.AppointmentEntryRenderer" 
   itemLayoutManager="com.adobe.calendarClasses.BestFitLayoutManager" />

We're very excited about this contribution to the Flex community and, in time, look forward to seeing it used within your Flex applications.

Finally, in expectation of the being asked the obvious question, and following in the footsteps of all good delivery teams, the answer is "It'll be ready when its ready" ;)

Posted by amcleod at 7:06 PM | Comments (57)

May 9, 2006

Cairngorm 2 Stateless Commands

You may have seen over on Steven Webster's blog that Cairngorm 2 for Flex 2 Beta 3 has been released.

The main change in this release, compared with previous releases, is how commands are instantiated and used. I'd like to touch on the motivation behind this change.

In Cairngorm for Flex 1.x, a single instance of each command was instantiated by the controller and that one instance is used for each and every invocation of the command.

There are reasons why the original implementation was done in such a manner, mainly historical due to Cairngorm originally being developed for Flash applications, but since the advent of Flex, we've wanted to change it. With the API scrub taking place between Flex 1.5 and Flex 2, we see now is a good time to make this change.

Steven explains on his blog the single change you'll have to make to your concrete front controller because of this API change.

So now, rather than the single instance of the command being used for each command invocation, the front controller now instantiates a new instance of the command on each invocation. There are a couple of implications here:

1) If, in your existing Cairngorm applications, you rely on the same command being used for each command invocation, (eg, if you store state in the command, and reuse that state on the next invocation), you will have to change your implementation. What we'd recommend here is that you store your state in your model, possibly via the ModelLocator pattern.

2) Because a new instance of the command is instantiated on each command invocation, you can now store local state in that command for the duration of its invocation. This is particularly useful for cases where you make server side calls (eg, via RemoteObject). Previously, you'd have to use a pattern such as the Asynchronous Completion Token, but now, you can store your state in a command's instance variable in the execute() method (for example, you may store the event object), and then retrieve it again in your result or fault handler. We find this useful for cases where you want to update different parts of the model in the result handler, depending on the context of the initial command execution.

So, go get Cairngorm 2 for Flex 2 Beta 3 and let us know what you think.

Posted by amcleod at 4:14 PM | Comments (1)