Tutorials, extensions, and source files for ActionScript, Flash, and other Adobe products.

 

Hurdles of an experienced Flasher learning Flex

Posted April 03, 2009 by senocular

The day before Yesterday I made the decision to use Flex [Builder] for a project I was working on that had already been prototyped in Flash CS4. Up until now, my experiences with Flex Builder have been extremely limited. I'm not, by any means, new to Flash or ActionScript (which I imagine, if you're reading this, you already know), but Flex is not something I've really worked with before.
Why haven't I used Flex before? The main reason is that I don't truly trust it. This mostly stems from the fact that it takes away my control and introduces concepts that aren't inline with core player concepts. In a way I understand that this is done to make it easier for the end user, but if you know what you're doing as a developer, it can make it more confusing. Take for example, addChild. The DisplayObjectContainer.addChild method is designed to accept any DisplayObject instance. However, in the context of the Flex framework, it has been overridden to work only with instances of Flex's own UIComponent objects.

Another reason I'm not a fan of Flex is bloat. The Flex framework is massive, complicated, and so dependent on itself that even an empty application, compiled, consists of 260 (!) classes and is around 170K in size. SRSLY?

But I digress. This is more about my learning experience and impressions from taking that first step to actually doing something productive with Flex, such as creating a useful application.

The application: An image comparison tool. It's not, by any means, a complicated application. It basically just loads and compares a couple of images. I made a prototype in Flash CS4 in less than a day.

The Environment: Flex builder 3.2 with Flex SDK 3.3 on Windows XP.

First things first: some nice things about working with Flex.


  • MXML: It's basically HTML for Flash. Most of us already know HTML, right? So having a markup equivalent for Flash development is a no-brainer.

  • Layout Components: If you've ever tried to make a scalable interface in Flash Authoring, you're probably familiar with how difficult (mostly time consuming) it can be. With the Flex layout components, you just throw a few things together and you instantly have a scalable interface. All the properties are there to adjust your layout to your liking.

  • Custom Components: It's a cinch to create a custom component in MXML and drop it into your main application. It's about as intuitive as it should be.

  • Code Assist: Unlike Flash, it picks up custom definitions instantly, and metadata can be used for about everything else (e.g. events).

  • Debugging tools: Though I haven't had a whole lot of experience with them yet, they seem much more capable than those found just about anywhere else.



And some of the not so nice?


  • MXML: It's completely new and consists (mostly) of a bunch of classes you, as a non-Flex using Flash developer, are not familiar with. Sometimes its curious how some of the connections are made, but in the end it really doesn't matter so long as it works, right? It's certainly a learning curve, even if you think you already know Flash and ActionScript.

  • Code Assist: It doesn't help everywhere. And if you've ever used FlashDevelop, you know too well what you're missing when developing in Flex. And I don't know how much Eclipse as a platform is to blame here because Java development under Eclipse (in terms of code assist) also blows Flex away.

  • Debugging tools: They're complicated and aren't very intuitive to work with. I couldn't get some panels to work right if at all and the overall workflow process seems overly complicated (that is if I'm even doing it right - but I don't know since it's not inherently clear). The debugger also seemed to terminate unexpectedly at times. Don't know what was going on there.

  • Refactor: This seems not quite 100% just yet.

  • Curly Braces: On a new line? Not my preferred style (I'm a cuddler), but saw no way to change that. Given that its the standard for Flex to have them on a new line, I'll deal with it.

  • SAP?: Where's the standalone player integration? Why do I have to endure browser initialization to test my application? And IE isn't my default browser... Granted, it's nice that you can do that, but I don't always want to have to.

  • GUI Redraw: There is some nasty issue going on with the gradient redraw for the property inspector in Flex Builder. When switching applications or when views change, I have to sit there and watch the gradients draw in for a few seconds before the application becomes active. Wut-up?

  • FormItem: Dear Mr FormItem, Why don't you appear in the Components list when in Design view?



Those are the highlights. I have a couple other specific issues I'd also like to address in more detail.

Working Locally: For my image compare tool, I'm working with images located in a folder on my hard drive. I'm not running a server on localhost (for the purposes of this project) so the SWF must be able to read from the hard drive to load in these images. As an experienced Flash developer, I know this requires that the SWF be published with its UseNetwork flag set to false. In Flash Authoring, this is an option in the publish settings GUI. But where is it in Flex Builder? No such option exists. Instead you have to use the compiler flag -use-network and set it to false. That's not very intuitive, but at least something people can fairly easily find online (I personally have used it before when working with the compiler via command line).

But it didn't stop there. For some reason I was getting a security warning when running my application locally. I narrowed it down to the TabNavigator component I was using. If it existed within my application the error occurred. Without it, no error. Why would that matter?

It turns out that this was due to browser history management. The kicker was I considered this and even unchecked the "Enable integration with browser navigation" option in the project properties. Doing so did not help, BUT placing historyManagementEnabled="false" in my Application element did. Sounds like a bug to me. Why has no one else run into this?

Running an application: As an experienced Flash developer, I know the difference between a release SWF and a debugger SWF, just like there's a difference between the release player and the debugger player. In Flex Builder, I look at the interface and see there there is an option to "Run" the application or "Debug" it. My quick goat thinking tells me that "Running" must mean creating a release SWF while "Debugging" creates a debugger SWF. After all, why would you need a debugger SWF if you're not debugging? Turns out this is not the case.

I carried over a lot of code from my Flash prototype over to Flex when recreating it there. One particular function was timed because it was processor intensive and pretty much did not change at all between the two development environments. Yet, for some reason, the Flash version ran more than twice as fast as the flex version, even when not debugging! How could this be? I didn't figure it out until as a last ditch effort I decided to click on the "Export Release Build" button, which to me looks like an "Export HTML" button. So up to this point, I've been ignoring it. But the tooltip with the "Release Build" clue (or smack in the face) identified the problem. Sure enough, publishing a release build and testing that gave results that were more inline with what was seen in Flash.

I'll have to say that this whole release build process also seemed overly complicated. I'll be wanting to test the release build a lot and I'm a little disappointed there's no respective button for that. Do I really have to open the export release build dialog, select my application, export, then manually open and test the file? That's not ideal. Similarly, the default placing of debug and release builds in different directories make it a little difficult when working with local files, especially when they're designed to be under the application's own directory.

Killer Flash Player: The biggest problem I had with Flex was not Flex at all, it was actually thanks to Flash Player. Turns out that I had a bad Flash Player installed on my system. The funny thing is (I say funny now, but it wasn't yesterday when I spent all day trying to figure it out), there were no problems for me using Flex SDK 3.1. Errors only started appearing after I started using Flex SDK 3.2 or 3.3. Obviously, when you see something like that, you have to assume that the new SDKs are to blame. Then again, you have to wonder that when a new, empty application fails to run without errors in a clean install of a release build of Flex Builder that maybe something else is to blame. And sure enough, there was (ahem, Flash Player). So this word of warning goes out to anyone involved with Flash Player beta programs or those of you that download players from labs: Beware! Flex may not play well with your players!




Overall, with its component set, Flex is a great platform for quickly creating GUI-based applications - so long as you know what you're doing. I still don't like the complexity involved, but to do something similar on your own, the complications of your custom approach are likely to be just as unappealing. I still have a lot of learning to do, but that comes with any framework. The tooling also lacks maturity, but each release improves on that and I'm hopeful that a lot of the existing problems will be ironed out.

At this point I think I'm still going to use Flash Authoring as my primary development tool. I'll probably only consider Flex for situations where there are advanced GUI requirements.