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!

You know you had a good idea when you see someone else implement it, and they do it better than you may have yourself.  Brian Lesser posted an article this week on O’Reilly titled, “MVC As Anti-Pattern.”  I have been meaning to write a similar article for a while.  Internally at Gorilla Logic, Stu Stern and I have had a long running dialog questioning the wisdom of bringing in full blown MVC frameworks into Flex (especially model 2 like implementations with a front controller).

Brian Lesser does a good job of arguing against implementing the traditional MVC pattern within Flex applications.  Lesser outlines the language/framework features in Flex that are far different than the language MVC grew out of many years back (i.e. Smalltalk), including discussing data binding and event listeners in Flex.  In addition to his main points, I am still a little awestruck at the willingness of developers to drag in a framework that quadruples or more the amount of code without adding much clear value.

Obviously, architecture is important and Lesser does spend some time discussing what the layers look like within Rich Client applications.  I am still digesting this section, but my initial reaction is that his ideas fit well with how I view application architecture in context of RIA’s (hard to go wrong when you borrow from Eric Evans).  It really is an exciting time as the move to rich client runtimes not only allows us to build better applications for end users, but forces us to think differently about the architecture.

The current state of the Flex eco-system continues to remind me of Java in the mid-to-late-1990’s.  Overall, it is at such an exciting place.  At the same time it can be frustrating, as some of the immaturities can really make it challenging to build quality applications.  However, even that can bring more excitement, as it really just means more opportunities to contribute.  And, I am ecstatic that Gorilla Logic is now finding ways to do that!

A couple of months ago, I blogged about the state of Flex, including a post on the state of testing tools.  We never did find a tool that satisfied our needs.  So, Gorilla Logic (mostly Stu Stern) finally built one, and open sourced it!   The new project is called: FlexMonkey.

Here is an overview of FlexMonkey’s features:

• Non-invasive. Requires no modifications to your application source.
• Records and plays back Flex UI interactions.
• UI Interactions can be edited and replayed.
• Generates FlexUnit TestCases.
• Integrated with FlexUnit.
• Handles all Flex UI events.
• Uses Flex Automation API to provide native control over your flex app. Requires no javascript or browser plug-ins to use.
• Unit tests are written entirely in ActionScript. No other programming or special purpose scripting languages are needed to develop comprehensive UI test suites.

Check out the tutorial: http://code.google.com/p/flexmonkey/wiki/QuickTutorial

You can also check out an example application compiled with Flex Monkey: http://keystone.gorillalogic.com/~sstern/MonkeyContacts.html#.

I just got around to checking out James Ward and Bruce Eckel’s Flex RefCard on DZone: http://refcardz.dzone.com/refcardz/very-first-steps-flex.  It looks super useful for those new to Flex, but it also looks like a useful tool for those already working with Flex to get a quick review.  Check it out when you get a minute.

Update 9/10/2008: Since this post, my company has launched a new Flex testing tool called FlexMonkey.  Read More about it here: http://ectropic.com/wordpress/?p=50.

I have finally gotten the chance to immerse myself in Flex code lately. I decided to do this series to capture my first hand experiences with Flex. Please share your feedback on the challenges and strengths I highlight. I would love to know if your experiences differ, or if you can fill in some of the gaps where I might be missing something. For those of you considering Adobe Flex, hopefully this will give you an accurate picture of building applications with Flex.

We have spent a bit of time evaluating FlexUnit and DPUnit. Both seem decent for unit testing, but don’t seem to solve the problem of doing full on automated UI testing for Flex applications. We are looking at a couple of recording tools (HP QuickTest professional & one from IBM), but it appears that they will be in the 5-10K range (and we can’t seem to get a call back from sales as of yet…). We really need something like HtmlUnit for use with traditional browser technologies. HtmlUnit allows us to mimic a client browser programmatically, and validate that the actual user interface renders and accepts input correctly. Is this what FlexUnit and/or DPUnit are supposed to do for us – are we missing something? If not, how are you approaching the testing of your Flex applications?

Click here to subscribe to my RSS feed and follow the rest of this series along.

I have finally gotten the chance to immerse myself in Flex code lately. I decided to do this series to capture my first hand experiences with Flex. Please share your feedback on the challenges and strengths I highlight. I would love to know if your experiences differ, or if you can fill in some of the gaps where I might be missing something. For those of you considering Adobe Flex, hopefully this will give you an accurate picture of building applications with Flex.

The true object oriented nature of the Flex components is excellent. I am sure there have been a number of “real” UI frameworks over the years that did things like this, but I have never had the opportunity to work with one…. So, being able to actually apply OO principles to UI development has been a pure joy. In addition, the Flex framework provides virtually every component I could ever imagine being needed for enterprise applications. This was always a huge challenge with Java web frameworks, as they always seemed to depend on the community to fill the “gaps,” if you can call the components of UI framework, the “gaps.” Anyhow, there are a few issues that seem to come out of the maturity questions I raised initially. For a few examples:

1. The default button implementation does not offer the ability to wrap the text. The fact that the components are really OO paid off here, as we were able to extend the core button and add this functionality. It was nice to be able to be able to work around the limitation this way, but this is clearly a common thing that people would want to do with a button.
2. We have been experiencing general difficulty with the ComboBox. It was surprising to have to set things manually – not being able to provide a reference that has the same value, but having to find the actual object in the list and provide him for setting the selected object, etc… The data grid layout breaks out of the columns on us when our custom ComboBox is clicked on… just weirdness.
3. Another surprise was that there was no default option to allow users to resize the default components. This would seem quite natural for an animation engine. Anyhow, we used the following to implement resize on our custom title window pop-ups: http://myflex.wordpress.com/2008/03/05/resizable-collapsable-titlewindow/. We made a few tweaks for our custom needs, and did our best to hide this in our implementation so we can easily replace it if we find a better implementation.

Also, here a quick link on styling – since it took me a while to find this: http://examples.adobe.com/flex3/consulting/styleexplorer/Flex3StyleExplorer.html.

Click here to subscribe to my RSS feed and follow the rest of this series along.

I have finally gotten the chance to immerse myself in Flex code lately. I decided to do this series to capture my first hand experiences with Flex. Please share your feedback on the challenges and strengths I highlight. I would love to know if your experiences differ, or if you can fill in some of the gaps where I might be missing something. For those of you considering Adobe Flex, hopefully this will give you an accurate picture of building applications with Flex.

Overall, the Flex programming model is enjoyable and easy to use – minus a few annoyances with ActionScript, it is a pretty elegant language (I would like to see abstracts and private/protected constructors added). Having the MXML declarative abstraction on top of AS3 proves to be quite genius. It makes laying out graphic components quite easy by hand, and would seem to be what really empowers the visual editor.

For a Java developer, ActionScript brings my first hands on experience with closures. I am no language expert, but what is all the debate about? Of course closures should be added to Java. I know there is quite a bit of nuance on what the syntax/implementation looks like, but it seems pretty obvious that this functionality can greatly reduce the code to implement any number of things.

I am finally learning to take advantage of the event model in Flex. It took me a while to train my brain to think in terms of events and listeners. I am used to taking a much longer path to wire things together. Not to get too far off the tracks, but with this in mind I am surprised that anyone would want to use a heavy weight MVC framework within Flex (especially one that looks more like MVC2). The separation of concerns seems quite natural in Flex. I am not a hater of MVC frameworks – I have spent my fair share of time in Java MVC frameworks, but they seemed much more necessary in a Java web world where all the core language provided was JSP pages.

Click here to subscribe to my RSS feed and follow the rest of this series along.

I have finally gotten the chance to immerse myself in Flex code lately. I decided to do this series to capture my first hand experiences with Flex. Please share your feedback on the challenges and strengths I highlight. I would love to know if your experiences differ, or if you can fill in some of the gaps where I might be missing something. For those of you considering Adobe Flex, hopefully this will give you an accurate picture of building applications with Flex.

The compiler is currently my number one frustration with Flex development – it is quite SLOWWWWWWW…… To the point where I have been wondering if we are doing something wrong. I have done dozens of Google searches and only found mild relief.

In general, all compile operations seem quite slow. Our near deal breaking issue is around a SWC library we are building. Here are a few numbers to help quantify what we are seeing:

• 31 MXML source files
• 24 ActionScript source files
• 3 embedded images
• Building typically ranges from: 25-35 Seconds (On ThinkPad T60, Ubuntu, FlexBuilder 3, 2 GB RAM, Core Duo T5600)

We do have a couple of embedded resources, but I don’t see many options here since we do need these as part of our API. We also have the incremental and keep flags set:

-incremental=true –keep=true

It is nice to see Flash Player 10 beta is out with its performance improvements, but I don’t see much talk about addressing the MXMLC compiler performance. Are there plans to address this, or is there a workaround we are missing?

Click here to subscribe to my RSS feed and follow the rest of this series along.