I found a few extra minutes and decided to read through an article I wrote last summer titled, From Java to Flex.  I hope that isn’t as narcissistic as it sounds, but I like to continue to learn and evolve and I thought I would see how much I still agree with myself.

Well, I made it to the second paragraph before I had to disagree with myself, “… developers should be considering the adoption of Flex is the maturity of the framework.”  It is hard for me to argue this point since I just blog about the Flex Immaturities. I still think Flex is worthy, and would argue that the wealth of off the shelf components for Flex makes it mature in a certain way.  The API’s are somewhat immature, but so many “UI Frameworks” don’t offer any real component library, so this is a big help in Flex.

I did a decent little review on LCDS.  Since writing the article, Adobe open sourced BlazeDS, which was an important step to give the community another open source option for remoting with Java backends.  BlazeDS does breakdown with any large scale push deployment, but this was still an important step forward.

Another thing that stands out is that I have the standard Adobe pitch in there that ActionScript is ECMAScript.  I have since concluded that this a silly pitch.  All I can figure on is that it feeds Adobe’s marketing claim on the large number of people who know their programming language (i.e. because they include all the JavaScript developers).  I think they should scrap this and start making the language better with abstracts and private constructors.

I don’t spend much time on AIR in the article.  I do see that AIR can have value, but I still see it as a weird fit for so many applications.  I guess I just don’t see it as much of a game changer as Adobe does.  I kind of like David Heinemeir Hansson’s take, You’re Not on A Plane.

I still strongly believe that Flex is a natrual extension of Java.  I am going to write a full post on that, so I wouldn’t go into that here.  I guess I still really like Flex.  I have seen more of its warts, but it still the best option I can find, as it offers a full suite of components essential for building enterprise applications.  This seems like a trival point, but I believe it is the key.  Shouldn’t all UI frameworks offer a full suite of components?

I was talking with a Ryan Knight, a co-worker at Gorilla Logic, about our general impression of Flex.  We are both developing significant functionality with Flex these days, and we quickly agreed that are some real pain points.  I boil most of these down to immaturities, and do expect Flex to overcome most of these as the platform matures.

One of Ryan’s examples was the Flex Date class, which for some odd reason is final.  This is of course problematic, and a bit bizarre to have something like this be final.  This caused Ryan’s projects challenges because the default behavior was causing issues, and they had to override the AMF serialization to overcome the issue, which is overly involved.

A similar pain for me was ArrayCollection (see previous post).  In my previous post, I didn’t discuss our attempts to extend ArrayCollection to control the typing when they are created from our Remote call.  First off, I was quite surprised to realize that ArrayCollection doesn’t have its own interface, as my first attempt was to hold the data in an Array and lazy instance the ArrayCollection by delegating to a private ArrayCollection.  Second, I tried to extend and wanted to not call the super constructor, but this was problematic because the compiler inserts super even if I omit it. Anyhow, as each typical object oriented approach ended in a road block, it seemed to being highlighting a real immaturity.

I won’t bore you with all the issues we banter about, but it is important that Flex evolves in the next 12-18 months.  Also, I do respect how difficult it is to design a good API, and I am not claiming that I would fare any better.  All that said, I am hoping to see the framework take huge steps forward with next year’s Flex 4 release.

I hope you made it this far because I did bury the lead a bit… Ryan and I both agree we still love Flex overall, and that wealth of components still makes it possible to build things simply not possible in many of the popular Java frameworks.

A few weeks ago my co-workers and myself spent a few hellish (but fun) days with significant performance issues on the eve of our first release of a Flex application we are building for a Gorilla Logic client.  First off, the majority of the issues were unrelated to Flex, but architectural choices outside of the presentation tier that we do not have much say in.  However, we did encounter a major challenge with Flex’s ArrayCollection.

Due to a somewhat unusual data set, we have a large number of ArrayCollections being returned in our Object graph, and we were experiencing a large time lag between when Flex reached the result handler and after BlazeDS had finished its work.  Times ranged from 10-60 seconds depending on the size of the data set.  After a decent amount of analysis, we discovered most all of this time was related to the performance hit of instancing an ArrayCollection.

By our testing, we were experiencing an 18x difference between instancing a large number of Arrays versus ArrayCollection.  We measured this with a simple program that just instanced 100,000 Arrays and then 100,000 ArrayCollections.  In addition, we tested with BlazeDS returning Arrays versus ArrayCollections and saw the same 18x difference.

The solution for us was to have BlazeDS return Arrays instead of ArrayCollections, with the legacy-collection setting.  This is obviously a decent trade off, as Arrays lack much of the essential functionality of ArrayCollection.  The root problem with ArrayCollection is the number of events that dispatches, and there are the methods for enabling and disabling “auto updates” to turn this off.  However, it is possible, but difficult to do this before Flex client reaches the result handler.

Beyond making instancing ArrayCollection faster, it would be nice to have the option to easily disable this behavior with a configuration property.  Here is the feature request I made: http://bugs.adobe.com/jira/browse/SDK-17916.  Please go vote for it!

I don’t usually get off the technical tracks with this blog, but what an amazing night for America.  I know that about half the country will be disappointed with the election of Obama, and I think it is ok to be disappointed if you don’t agree with his politics.  Regardless, I think you have be excited that this country elected a black man tonight. We cannot change the bad things in our past, like slavery, but I think we should all be enthused about the uniqueness of this country.  To quote Ronald Reagan, “America is a shining city upon a hill whose beacon light guides freedom-loving people everywhere.”  There have been a number of lowlights for our nation in recent years.  It is awesome to remember what is possible here.

We are living in truly historic times!

While I was sipping Pina Colada’s in Mexico last week, my video cast partner posted Episode 2 of Drunk On Software. In this Episode, we discuss FlexMonkey with Stu Stern.  This was extra fun to record (and hopefully to watch), as Stu is always entertaining with his unique and interesting banter.  Enjoy!

http://www.drunkonsoftware.com/2008/10/30/episode-2-flex-automated-testing-and-flexmonkey/