The Flex development landscape has many frameworks for creating scalable, enterprise RIA applications. The two major players, in my opinion, are Cairngorm and Mate. Both frameworks offer a solid approach to an enterprise RIA. Having used both Cairngorm and Mate in enterprise Java applications, Mate is the better option for small and large projects(in my opinion). Cairngorm uses a singleton pattern that makes it hard to use modules and requires significant more overhead in compile times, SWF size, and speed of development. Mate on the other hand uses an injection approach which is easy and fast to create, maintain, and debug applications. I am not saying you are going wrong by using Cairngorm, but my first choice is Mate.
Cairngorm development dead; Mate booming
Cairngorm was purchased by Adobe and eventually open sourced. Since being opened source in an SVN repository in July 2008, Cairngorm has had a total of 0 new releases, 15 total commits and no commits since November 2008. The last code release of cairngorm has not been since Flex 2. Mate on the other hand is also open source. Mate had 17 new releases in the last year alone with hundreds of commits to its repository. No other Flex framework out there that I have seen has this amount of activity.
Mate and the Bus Factor
There are a few downsides to Mate that don’t having anything to do with the code. The bus factor. Mate is run by a few people at asfusion. They do a great job at updating the forums, providing documentation, and doing presentations at various Flex events across the country. However, if they decide to change careers or just get overwhelmed maintaining Mate, there may be no one there to step in to keep the framework going. I would like to see Mate gain wider support with its code base, with more people committing code and making decisions for the framework’s direction.
A 1.0 release of Mate is also desirable. The code is quite stable, but a 1.0 release would give a safer feeling to enterprise projects using it.
Support Both or Support None
Adobe bought Cairngorm several years ago. This was a good idea to help with the development of Flex RIAs. Now the Flex SDK and Cairngorm are open source. This completely changes the game. It appears no one is working on Cairngorm or looking for enhancements for things like modules. There also appears to be no community involvement for this project. At what point does Adobe change its direction for a framework? Will Cairngorm still be the Adobe framework of choice 5 years from now? Flex 4 is the time to make the change. One option is to offer both Cairngorm and Mate as preferred frameworks for Flex. But then the question is, who maintains these frameworks? A second option would to be supporting no one framework. This way the community can drive the direction of RIA development by using the best available framework. It has worked over the years with Struts, Spring, Hibernate, Apache, etc.
By supporting just one framework, the door for innovation of frameworks is closed. The Flex SDK continuosly improves and excites the community. Allowing the community to improve the frameworks would be a great step foward.
Time travel between Flex, BlazeDS, and Java can be quite complicated to keep the three correctly in sync. Time travel, aka remote objects that carry date members, can mean different things to each piece of software. Java is very time zone aware, where as Flex is very time zone unaware. Since time in Java, BlazeDS, and Flex is defined in milliseconds since 1970, it can mean translation via BlazeDS can result in inconsistencies. How can this be?
Java
When it comes to time zones and daylight savings time, Java is very smart. It uses the Olson Database to determine how to translate a time in milliseconds since 1970 into an actual date/time based on the current timezone. The Olson Database knows when daylight savings time started and ended in each time zone each year. If you remember, prior to 2007, daylight savings time in the United States started the first weekend in April and ended the last weekend in October. But, it an effort to be more energy conscious, the government changed it to the second weekend of March through the first weekend in November. Java knows about daylight savings time and time zones as they existed in the past. Therefore, milliseconds since 1970 for a date of March 15th, 2006 in Java maybe different than on another platform.
BlazeDS
BlazeDS(and the Flex RPC library) translate time via AMF between Flex and Java. It knows nothing about time zones or daylight savings time. When sending a remote object that contains a date, it will be converted to date.getTime() - milliseconds since 1970. BlazeDS is always translating dates in the present and has no understanding of the client and server’s time awareness.
Flex
Flex only knows about daylight savings time now. Meaning, Flex will think March 15th, 2006 was during daylight savings time. But in 2006, daylight savings time didn’t start until April so Java will have a different answer than Flex to milliseconds since 1970? To be fair, it is not Flex or Flash that aren’t time zone savy. It is the user’s browser and computer that are ultimately at fault. The flash player will just pull the information from them. Imagine if a user enters a date/time today(during daylight savings time). At some point in the future, the government changes daylight savings time to start tomorrow. After the change occurs, the date the user entered will be correct in Java(because Java knows of daylight savings time in the past), but will be one hour off when displayed in Flex.
Creating an identical date/time object in both Flex and Java can cause different results for milliseconds since 1970. Take for example a user entering a birth date on a Flex form as March 15th, 2006 and another user entering a birth date as March 15th, 2009. The following screen shots show a simple Flex app with a date chooser and a label showing the time in milliseconds since 1970.
When the user selects March 15, 2009, the date is correctly translated to Java via BlazeDS as March 15th, 2009. Notice that Java says EDT(Eastern Daylight Time).
Now look at the same test for March 15, 2006.
Notice for the March 15th, 2006 date translation is incorrect. The date given to us via BlazeDS will actually be on March 14th at 11pm. Java correctly identifies the time zone EST(Eastern Standard Time). Java is correct. Back in 2006, March 15th was during eastern standard time. Because this date today is in eastern daylight time, Flex incorrectly reports milliseconds since 1970 to a number off by one hour.
Now the incorrect birth date is put in the database as March 14th!! Want to run a query to find all people born on March 15th, 2006? That could be a problem. There are several ways to solve this problem. One might be creating a JustADate class that has year, month, day fields on it so BlazeDS will send it without using getTime(). Another option might be sending date only fields as strings to avoid the getTime() translation. When working with dates in Flex, BlazeDS, and Java, be sure to consider time travel and its inconsistencies!
“Once confined to fantasy and science fiction, time travel is now simply an engineering problem.” -Michio Kaku
Ever run into the problem with Hibernate where a child collection needs to be filtered? With Flex, most child collections are going to be fetched eagerly. These child collections may need to filtered based on some filter to the parent. I found this problem to be a little tricky. If anyone has a better solution, commentary is welcome.
Take the following object model for example. A Cat class contains a collection of “kittens”. Let’s say that the Cat class has a “color” property on it and I want to pull all Cats whose color is white. In HQL, I would write something like “from Cats where color = ‘white’”. This would get me a collection of all white Cats, which would contain a collection of each of the Cat’s kittens. Now consider that I want to filter the kittens to only get kittens whose color is also white. The entire kittens collection is always filled in each Cat class, with no HQL join query that can filter the kittens collection.
Here is how you can filter the Cat’s kittens by using the Hibernate Criteria api.
Criteria c = this.getSession().createCriteria(Cat.class)
.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)
.add(Restrictions.eq(”color”, “white”))
.createCriteria(”kittens”, Criteria.LEFT_JOIN)
.add(Restrictions.eq(”color”, “white”))
;
List<Cat> cats = c.list();
This is not what I would say is ideal for getting what I want, but it worked. Hope it helps you.
I’m kind of into automation. If I have to do something more than a few times a day, it needs to be automated to work for me. I originally wanted to write a flexpasta.bat file that would just write this post and code it for me, but that seemed a bit overboard.
One thing most web developers encounter in a day is testing their code. This usually involves reloading the page each time a code change in made and published. With Flex, we are having to reload the whole app, then probably make a bunch of clicks to get to the part of the application we are testing. This has become a pain, especially when making nit picky UI changes. Which brings me to the automation part. What if, when we make changes to code, it automatically reloads the flex module I am working on so that I can see the changes right away with no reload/type/click action? Making UI changes would be so much nicer.
To do this I have created DynamicModuleLoader.as. Basically, it extends ModuleLoader. Every 5 seconds it will ping the server to find out if the module has changed. If it has changed, it dumps the old module and loads the new one. Works best with two monitors. Just stating the obvious, but this is not for a production environment! Just helps for development.
package com.flexpasta.modules
{
import flash.display.DisplayObject;
import flash.events.Event;
import flash.events.TimerEvent;
import flash.net.URLLoader;
import flash.net.URLRequest;
import flash.utils.Timer;
import mx.modules.Module;
import mx.modules.ModuleLoader;
public class DynamicModuleLoader extends ModuleLoader
{
public function DynamicModuleLoader()
{
super();
}
private var timer:Timer = new Timer(5000,50000);
override public function addChild(child:DisplayObject):DisplayObject
{
var disp:DisplayObject = super.addChild(child);
if(child is Module && !timer.running)
{
timer.addEventListener(TimerEvent.TIMER, checkForNewModule);
timer.start();
}
return disp;
}
private function checkForNewModule(event:TimerEvent):void
{
var urlLoader:URLLoader = new URLLoader();
urlLoader.addEventListener(Event.COMPLETE, httpResult);
var urlReq:URLRequest = new URLRequest(url);
urlLoader.load(urlReq);
}
private var byteAmount:Number
private function httpResult(event:Event):void
{
if(isNaN(byteAmount))
{
byteAmount = event.currentTarget.bytesTotal;
}
else if(byteAmount!=event.currentTarget.bytesTotal)
{
byteAmount = event.currentTarget.bytesTotal;
unloadModule();
loadModule(url);
}
}
}
}
If you’ve dealt with item renderers in any kind of complexity, you’ve probably run into scroll bars gone wild. Problems usually start happening when you have a list based component that needs to scroll, and each item may have a variable row height. Painful symptoms of scroll bars gone wild include: text being cut off, scrolling becoming choppy, or lots of inner scroll bars appearing and disappearing. A really easy way to run into problems with item renderers is by using images that are loaded by a url at runtime. Take a look at the following simple example that uses mx:List to show a description next to a dynamic image. Try scrolling with the down arrows and scroll thumb to see the less than desirable results(note there are 4 items in the list).
There are many ways to tackle out of control item renderers. In this case, it’s a Repeater For the Win! Take a look at the identical application using an mx:Repeater tag instead of mx:List. The scrolling is smooth and the down arrow works!
The draw back to using the mx:Repeater tag is that there is no item recycling. Meaning, unlike using an item Render, which will be reused when I scroll, the mx:Repeater will draw everything at once. For small lists, using a repeater tag should be ok, but for large data sets, a repeater tag could cause memory problems. Also note, one other benefit to using the repeater tag in this instance is that the images are loading once. In the first example, the item renderers are being recycled as scrolling occurs, this means the images are reloaded everytime they appear on the screen.