Adobe Flex First Thoughts: Part III

I was able to sneak into a two day Adobe Flex 3 training session two weeks ago, and here is my reaction. This is Part 3 in a 3 part series on Flex. Today covers the Flex Server and Adobe Integrated Runtime (AIR) . The previous posts covered the Flex language and the Eclipse Plugin.

As a word of warning... these are opinions generated by a mere 16 hours in training. Errors and omissions should be expected (that's what the comments are for).

Flex Server

After two days of training, the only fact I'm sure of about the Flex Server is that you have to pay for it. What does it do? I'm not sure. I felt like doing some research this morning (so I don't sound like a complete moron) and found that Flex Server is really called Adobe LiveCycle Data Services ES (ES, huh?). And after reading about the product on the 'net, I'm still not sure what it does.

The one thing I was sure the server did was include the ability to just-in-time compile Flex applications into .swf files for web clients. Perhaps the reason is to dynamically include data into the .swf file without requiring web access. Funny thing is, I don't see this described on the product page.

The other promise the server makes is to allow occasionally connected Flex applications to run on devices outside of a network. I did a lot of work on this problem in the early part of the century, and kudos to Adobe if they finally figured out the architectural issues. I worked with ExtendedConnect, ScoutSync, and a few other of the "Enterprise Synchronization" engines, and they all failed miserably at this task. One project I worked on in 2001 had public service vehicles receiving dispatches from a server using UDP packets, and the middleware provider somehow guaranteed (eventual) delivery. Needless to say, it did not work. Now it's 2007 and I recently heard from the client, who said they finally rolled out a feature that I had been working on 6 years ago. Ha. Anyway, most of the enterprise synchronization players back then were using disconnected record sets and dirty flags on records so as to track offline changes to the database. When devices returned to network coverage, only the dirty records were synchronized. When I asked the trainer how the server manages the "occasionally connected" mode, I got pretty much the same answer. You know, Adobe ain't that bad and I wouldn't mind seeing them succeed (despite their blasted .pdf format), but I don't have high hopes for this occasionally connected thing. I'd personally be prepared to write reams of communication code if this were ever a requirement on my project.

So I'm not wholly sold on this Flex Server thing, regardless of its marketing name.

Adobe Integrated Runtime (AIR)

AIR was cool. Very cool. And it was beta. Very beta. Man, I symphathize with trainers when their software crashes. Demonstrating crummy software is one of the industry's shameful rites of passage. We should force all CS graduates to spend 6 months training users on software that crashes a few times a day just to humble them. At least in this training session, the trainer hadn't personally written the software, as has been my case so many times.

So AIR takes Flex projects and their .swf files and bundles it all into a .exe package that can execute from a user's desktop without any webserver. All the data, all the media, and all the code bundled up into one .exe package. While not complete, the vision is that all operating system resources are available to AIR applications. So AIR apps can access the filesystem and devices, while Flex apps running in a browser cannot.

Macromedia, and now Adobe, really knows how to manage and update a runtime environment, and AIR is a great example of this. Ever updated your JRE through your browser? I'm always asked a whole bunch of questions by an install wizard, and I'm left wondering if all my answers were correct. "Hmmm.... I wonder if _all_ my browsers got updated," I'll say to myself. How about Java Web Start? "Hmmm... I wonder why it's not starting," I'll say to myself. Who knows. Updating Flash versions has always been simple. And with AIR, Adobe has created a sandbox install/uninstall environment, where applications and their dependencies are managed with all the ease of updating Flash. It was really slick. And it crashed a few times. Hey, it's beta.

So while the Flex Server left me a little cold, the premise and promise of AIR got me all hot... let's hope it's not all hot air! Okay, sorry, that was an awful pun. But the alternative would be for me to say the server left me dry while AIR got me all wet. So consider yourself lucky.

Adobe Flex First Thoughts: Part II

Isn't Part II of First Thoughts really Second Thoughts? Anyway... I was able to sneak into a two day Adobe Flex 3 training session two weeks ago, and here is my reaction. This is Part 2 in a 3 part series on Flex. Today covers the Flex Builder Eclipse Plugin, yesterday covered the Flex language, and next up is the Flex Server and Adobe Integrated Runtime (AIR) components.

As a word of warning... these are opinions generated by a mere 16 hours in training. Errors and omissions should be expected (that's what the comments are for).

The Flex Builder product is the for-sale development environment from Adobe. It runs within Eclipse, and features the usual code editing capabilities, a full debugger, and a beautiful visual page layout mechanism.

Editing Code
I previously stated that putting ActionScript, CSS, and XML within one source file was a bad idea. I've since learned that there are recommended ways to separate out these layers. In fact, mxml isn't needed at all and entire applications can be coded in ActionScript only. For simple applications, a lot of the pain of managing these concerns is alleviated by the code editing and navigation features of Builder. Code-folding and syntax highlighting helps here, but those features are really the bare minimum of what a modern IDE should provide. The IntelliSense and Auto-Complete features within Builder worked at a basic level. I found myself looking for the more advanced completion features though. Attribute lookup of XML elements is one thing, but finding advanced matches of object names in the project is another. The existing product is much better than using a text editor, but is still somewhat behind IDEA or Eclipse for Java. It sounds like most people are using statically typed ActionScript, so writing advanced features is not an incredibly difficult problem. So far Adobe has promised the "Find All References", "Move", and "Rename" refactorings. I hope Adobe is putting a lot of work into these features rather than providing a bare minimum and hoping the community fills it in later.

The Debugger
The debugging capabilities offered by Eclipse is an enormous improvement over debugging Flash or JavaScript. Coming from an Eclipse/IDEA background, it worked exactly as I expected it to. Bravo, Adobe, for fixing on of my largest pain points in Flash. You get all the usual debug windows from Eclipse: Variables, Watches, Breakpoints... Such an improvement over the trace() method (or God forbid the alert() method).

The UI Builder
The Flex UI builder picks up right where the .NET form builders left off. Which is exactly where the Java form builders dropped the ball. I've never found a Java form builder as nice as the one published with Visual Basic 6 in 1998. And I would kind of like the portion of my brain back that is currently in use holding onto all of the stuff about Java's GridBagLayout. Drag and drop widget libraries are nice. Visually aligning widgets is nice. Visually resizing widgets is nice. Humans are biologically visual people. We have forward vision to track targets (hunting food) and peripheral vision to watch for dangers (becoming food). We are built to look at three objects and quickly tell which one is the wrong size. We are not build to scan a text file and find two instances of the string ".x = 418" and one of ".x = 422". What are Java LayoutManagers if not a denial of human biology?

One last piece of information is that the Flex Builder has been reported to compile ActionScript faster than the command line version. While the comparison must not be apples to apples, (I'm sure they use the same compiler), there might be layers of tools needed to get the command line version to work, and the Builder may sense file changes and build as you work. To the end user, Flex Builder may indeed seem to build faster than the alternative, free tools.

Flex Builder 3 looks like a great, polished product. It is expensive. Most developers know that the price of tools is small compared with the productivity savings from those tools... but how many shops use Eclipse simply because it is free? And how many shops will use the Flex command line compiler, Ant, and some XML DTD plugins for auto-complete simply because it is free? I've heard both sides: the free tools are good enough, and Flex Builder is almost required for serious development. And I've heard them both from the same person! The download is free... decide for yourself.

Adobe Flex First Thoughts: Part I

I was able to sneak into a two day Adobe Flex 3 training session a few weeks ago, and now I've finally had a chance to write down what my impressions are of the language and environment. This is Part 1 in a 3 part series on Flex. Today covers the Flex language, next up is the Flex Builder Eclipse Development Plugin, and last is the Flex Server and Adobe Integrated Runtime (AIR) components.

As a word of warning... these are opinions generated by a mere 16 hours in training. Errors and omissions should be expected (that's what the comments are for).

Flex is Adobe's platform for web applications. To the end user, the application produced looks like any other Flash application running in the browser. But the difference between the Flash and Flex development environments is large.

Unlike the Flash development environment (now called CS3), Flex has no concept of a movie, a stage, or a time line. This is good news for programmers because development no longer feels like it is taking place in an animators studio. Instead, Flex ships as an Eclipse based plugin. The IDE looks great: there is a nice looking UI builder, the Eclipse project wizards seem to work, the IntelliSense works good enough, and the debugger contains all the expected Eclipse options. The compiler is available for free, it is only the Eclipse plugin and the Flex server that requires a purchase

The Basics

Flex applications are written in mxml, which is really just an xml file. The file contains xml based component definitions ("put text box here"), css to determine look and feel ("background is green", and ActionScript 3.0 to handle behavior ("MyTextBox.onClick(Event e)...").

For me mxml was a bit of a turn off because it mixed the xml, ActionScript, and css all in one file. Even with the syntax highlighting, there was a lot of noise to sort through when you wanted to get down to the business of editing ActionScript. It looked like all the naive sample Java Swing applications that Sun published (you know, where every sample is one big class that extends from JFrame). These examples influenced thousands of Java programmers, like myself, into thinking that every Swing app started with subclassing JFrame. Ack! Model, View, Controller anyone? I know this approach of mixing all three layers in one mxml file isn't required, and that css can be externalized to an application level css file. But it's sad to see Adobe implicitly promoting this style the same way Sun did with the Swing examples.

The good part of mxml is that it could drive component driver development. Each mxml file is typically a visual component that extends an existing widget and adds functionality to it. There are currently hundreds of existing components in the base component library, and more are available on the web for free and otherwise. All of the dependencies are located within the component, and the application is simply a shell that assembles these components into a coherent layout. Nice and reusable. Just like COM! Wait... that doesn't sound good. But it is like COM in that the goal is to define reusable components that developers can add to their component library. And it seems like Adobe wants to make it easier for 3rd parties to create and resell components, just like the COM business model. A ramification of this model is that 3rd parties become very important to the success of both Flex and COM. All the components look great today: crisp, well-animated, modern looking. But in 5 years they are going to look old, dated, and clunky. Everyone knows a VB 5 application when they see one; in 5 years will Flex apps be the same? The answer is maybe, depending on what happens with the community and what Adobe contributes.

Working with Widgets

Within the mxml file, Flex visual components are defined and laid out using xml markup. Verbose? Yes. Old Fashioned? Yes. Industry Standard? You betcha. The nice part is that layout and positioning are controlled within the component declaration. Compared with Swing's GridBagLayout, the Flex layout mechanisms were a joy. It was a lot of containers and alignment attributes, but it was all intuitive, especially for someone versed in JPanels and scarred by GridBags. What's more, there was an absolute layout option. Why did Java never include this with Swing? VB has always been easier to prototype with than Java, and my opinion is that the missing absolute layout manager has a lot to do with it. VB UI's were a breeze to throw together, and so are Flex's. The downside here is that resizing doesn't work. For a rich, pretty website designed by a graphic design professional, this might be a non-issue. But most pages I piece together benefit from resizing. As monitors grow in size, a blog column constrained to 600 pixels doesn't make sense.

But wait? Wasn't css part of the mxml? If you lay out the page in XML, then what does the css do? The answer: css only controls looks such as color and fonts, not the size and layout of the components. I love this because I've never graduated beyond html tables. Never once have I gotten css positioning to work. And now I don't have to!

Hopefully, most my time with Flex will be spent with ActionScript 3.0, making the components behave the way I want. I've been told at times that AS 3 is a subset of Javascript 2, a superset of Javascript 2, and that both are based on ECMAScript. It seems to me like both are based on ECMA, AS based on edition 4 and JS based on edition 3. Anyway, you get all the nice features you'd expect like anonymous functions, object prototypes, and the mixins that go along with it. For anyone with a passing knowledge of Javascript, the ActionScript language shouldn't be hard to learn. One cool feature is that the Flex compiler has a command line switch on whether to enforce static/strong typing or to allow dynamic/weak typing. The demonstration I saw was strongly typed, but a little exploring exposed this option. Exciting! In Java, I've been advocating having production code written in Java (static/strong typing), but unit test code written in Groovy (dynamic/weak typing). This allows me to refactor the production code without worrying about compiler errors, which simply serve to slow down many refactorings. I lose the ability to think out loud with code, and find myself thinking for short periods of time and then fixing all the compiler errors I introduced. (Technically, what I want is static typing in production code and dynamic, but strong, typing in unit test code, but getting dynamic is an improvement). (More technically, what I really want is weak, dynamic typing for both lines of code and the good tool support typically associated with static types)! Anyway, it looks like static typing in production and dynamic typing in test is supportable with Flex. It would just take some clever code organization and build scripts. Awesome!

Working with Data

One of the best parts of a dynamic language is the parsing and text processing capabilities. XML creating and parsing is a breeze with Flex. Look how easy it is to create a large XML document:

var employees:XML =
<employees>
<employee ssn="123-123-1234">
  <name first="John" last="Doe"/>
  <address>
    <city>San Francisco</city>
  </address>
</employee>
<employee ssn="789-789-7890">
  <name first="Mary" last="Roe"/>
  <address>
    <city>Newton</city>
  </address>
</employee>
</employees>;

This is more intuitive to me than the equivalent Groovy Builder object that uses closures to build XML. Accessing XML is a snap too. Just take the XML object and reference it without the endless findChild(), findAttribute() method calls associated with Java parsing:

employees.employee[0].address.zip;   // 98765
employees.employee[1].@ssn;          // 789-789-7890

This whole thing makes me happy.

Flex components are tied to data sources, such as web services or files, using a very similar technique to Visual Basic's component bindings. A component itself has a data source attribute which references an ActionScript variable declared as Bindable. This is simple, slick, and makes for a great demo. However, a DAO layer would definitely be needed for large-scale projects. Remember, not only does the mxml file have AS, XML, and CSS in it, it now also contains bindings to the data model. Separation of concerns was not a design principle for the training material. Sure, it could all be separated out, but Adobe does not seem to be leading the way for higher quality Flex designs. One nice thing about this data binding is how simple the Ajax integration becomes. Since everything you need is within the mxml component, the component itself can connect and update itself asynchronously without crossing any layer boundaries. I was similarly impressed with Grails custom tags and the ease with which they could be Ajax-ified. The two aren't that dissimilar to someone without in depth knowledge (me).

The Bad Stuff

One large downside of Flex is the lack of community and support. Try to do anything in Javascript and you can find hundreds of forum posts and articles describing how to do it. Try to do anything in ActionScript and it will be much harder to find examples. Moreover, some of the examples will be AS 2 or earlier. The few edge cases I found myself working with stumped me for quite a while, and lack of online help played a role. Also, there simply aren't as many people with Flex skills, so hiring good people might prove to be tougher (whereas, hiring awful Javascript programmers is pretty easy nowadays!). Flex does have good documentation from Adobe, which is modeled after Javadoc. Overall though I'm hesitant to invest a lot of time into something that may never be mainstream. But last month's Minnesota Flex User's Group had 30 people show up, so maybe this is the next big thing.

The other downside of Flex is the US$400 license you need to buy for the Eclipse development environment. While this isn't needed to develop Flex apps, it sure was nice. It's also the topic of the next part in this series.