Working with Adobe Flex

RIA is a pretty hot topic in these days; even in ThoughtWorks a lot of discussions are going on (if you have time check fellow ThoughtWorkers posts here, here and here).

I’m quite involved in the conversation, mostly due to the use of Adobe Flex in my current project.

What is Flex ?

Flex is the Adobe solution for RIA; based on ActionScript, it promises quick development of rich UI, the ability of testing and TDD-ing, good tools for development and out of the box integration with Web Services and REST services.

Everything sounds cool, but my experience with Flex highlighted few elements that worth a bit of attention…let’s analyze those one by one.

Testability

ActionScript is actually really hard to test.

A Unit testing framework (FlexUnit) is available but it cannot be used by command line because the test runner works only in your browser; this slow down your development cycle (red-green-refactor) quite a lot, reducing your effectiveness during the day.

ActionScript is a half way between a static and a dynamic language (with a clear direction towards being a pure static language, my guess is that the language designers are trying to increase the language appeal to the Java and the .Net community).The main concert here is you miss the testing support of static languages(mock libraries mostly) and of a dynamic one you’re missing the complete dynamic approach(all the classes are sealed by default, and you can’t do methods override at runtime even for objects that are explicitly declared dynamic).

In this scenario interaction testing is nearly impossible to do; sure, you can write your own mock library or stub everything out but this is a pretty strategic decision and a lot depends on the scope of the project.

Flex Security Model

Another aspect that gave us more than one trouble is Flex security model.

A Flex application can connect to a WebService or a REST service only if:

• the target service is on the same domain where the Flex application is deployed
• the target service is on an external domain but in the target domain there is a crossdomain.xml file that declares your domain as secure

What does it mean ? That if I want to access a public feed (let’s say the BBC weather feed) BBC has to have my domain specified on its crossdomain.xml file that lives on its server.

This is a strong limitation: you cannot simply call BBC and ask to add your domain to their list of trusted site, and this take you down the path of over design your application (like adding a proxy web service on your domain just to be able to get the real data you need from BBC).

Tutorials and suggested best practices

A final comment is for the Adobe tutorials: it’s hard to see in 2008 something so poor. The tutorials (have a look at the Flickr one to have an idea) are a collection of bad practices: the suggested development style is spaghetti-code, where you write all the code in the Script tag within your main Flex application file (mxml).

And what about separation of responsibilities ? Do we really think that this is the code you obtain doing TDD ?

The heavily usage of the Script tag will take you down maintenance nightmares, transforming your application in something that is quickly out of your control and you cannot evolve.

Final thoughts

Looking at these pain points I can’t sat that Flex is a mature technology. Adobe promises a lot but a number of the promises are not there; TDD is simply too hard to do due to the lack of mock support(even if looks promising), the set of possible permissions you can give to the Flash player clashes with the new services oriented features (introducing cumbersome security model that take you to overdesign as a possible workaround), and tooling is quite poor (FlexBuilder, the IDE, crashes regularly and the Ant task is pretty basic).