A couple of weeks ago, I posted about a workflow I had devised that allowed me to utilize Flash library symbols but still write my code in Flex Builder. While Adobe apparently thinks this awkward hybrid approach qualifies as “integration”, I thankfully discovered a better process just a day or so after my posting. I discovered the main concept of this better workflow from Arpit Mathur’s blog.

What it basically boils down to is using Flash authoring to create a SWC that you then use as a library in your ActionScript project in Flex Builder. Getting Flash authoring to generate a SWC is as simple as checking a box in the Publish Settings dialog.

exportSWC

Then make your ActionScript project use the resulting SWC.

useSWC

What you can then do is create ActionScript classes that extend the symbols in your Flash file. As long as you give your symbol a linkage name it will be available for extension (and will itself extend MovieClip by default), allowing you to add behaviors and logic using class-based ActionScript like developers expect and prefer to do. The convention I have settled on is to add “_Symbol” to the end of the class names specified in Flash authoring to make it completely clear where everything originates.

myButtonLinkage

The other major advantage this approach has is that it renders the “Automatically declare stage instances” debate irrelevant. You can let the designers leave this setting off and write bits of timeline code if they need to and your classes that extend their symbols will still work. Regardless if they are specified manually in class files for the symbols themselves or Flash generates the classes automatically, the children of your symbols (text fields, child movie clips, etc.) will all be available to your code.

myButtonClass

With this simple structure of a symbol in Flash:

symbol

You can write a class like this to control it.

The result is a functioning button that allows the designer to use the expressive, proven tools in Flash authoring to create the graphical assets while allowing the developer to use the mature code editing environment of Flex Builder. This process has proven valuable and efficient over the last two weeks and it addresses the major shortcoming of my previous post. That was an inability to use a proper debugger, and it also lets the designer and developer work in parallel, both in the environment most familiar to them. It lets each tool and each team member do what they do best.

While I developed this workflow (not that its an original one by any means, just new to me) due to my assignment on a project that could not use Flex, I actually think it could be valuable in Flex projects as well. For views that are highly detailed and/or non-standard it may very well be easier to let your designer create them in Flash than it would be to create some crazy MXML file that carefully layers exported images and animations that you then try to wire up and orchestrate with code. Simply write a class that extends your designer’s symbol and manipulates it as needed.

To me this seems like the best kind of workflow available today by far, and so its really disappointing and frustrating to think Adobe may not be taking things a step further in their next releases. We don’t need or want Flash Builder to compile and run our projects in Flash authoring. What we need are workflows that allow us to use tools that do their job well and that we’re comfortable with, and that simplify the inevitable round tripping between design and development. Having Flash Builder trigger compiles in Flash authoring may sell more licenses to the uninformed, but its a sad excuse for integration from a company that creates tools ranging from authoring to runtime.

All code and sample files for this post can be found in my Google Code repository.