My goals here are to integrate www.adobe.com/products/flash/ Flash with www.adobe.com/products/flex/ Flex, i.e. not just treat it as a design asset tool, but as a contributor to the functionality of the client; using Flash for enhancing the design, and helping reduce transition code which tends to be verbose in Flex.

Below you'll find a sample application that has integration of a complicated Flash design done using many different techniques. I describe the reasons why you would want to work this way, compare with other techniques, and walk through the code and files in my example.

To be clear, this is a proof of concept, and uses a variety of techniques for the purposes of showing developers a variety of ways to do things. It is not meant to indicate all ways to integrate Flash and Flex, nor necessarily the best ways for all occasions. Yes, I did in fact abuse this design for schizzle my nizzle.

Why Integration?
Early on in Flex 2's release, many Flash developers recognized immediately that there were serious interop issues with Flash and Flex. This stems from the Flash Player 9's new AVM (or ActionScript Virtual Machine) that runs the new ActionScript 3.0 programming language. ActionScript 2.0, ActionScript 1.0, and Flash Player 4 scripting on down uses the old AVM engine. For security and various other engineering reasons, the AVMs cannot talk to each other. This results in a SWF written in the Flash 8 IDE not being able to "talk" to a Flex 2 SWF. The need for doing this is that the Flash IDE allows creation of design content that Flex cannot create on its own. Flex 2 is an awesome programming environment compared to Flash, is approachable by developers, and is more geared towards large programming projects vs. multimedia. Therefore, there is much incentive to get them to work together, and not just by using a loadMovie approach (dynamically loading in the Flash created SWF at runtime).

There are various solutions out there. One is do just that, load in the content dynamically by using a SWFLoader component in a Flex 2 project. In the cases of a ActionScript 3.0 only project, you merely use the Flash.display.Loader class. If the content can operate on its own, and/or show design content correctly, this is satisfactory.

Another is to utilize a small set of classes to communicate via LocalConnection. LocalConnection is a class that allows multiple SWFs on the same computer to talk to each other. This helps bridge the AVM gap via viable APIs. This is asynchronous, however, and error checking is faith based.

A third one is to utilize ExternalInterface. Flash Player 8 introduced the ExternalInterface, and API to allow Flash Player to talk, synchronously (a.k.a. to block) with its hosting environment and receive callbacks from those method calls. This not only allows strongly typing those external calls, but hosts can call into the SWF they are hosting as well. In this method an API is used to have the Flash Player 8 SWF that is loaded into a Flex 2 to make a call to ExternalInterface which calls out to JavaScript on the hosting HTML page. The hosting HTML page then forwards that call into the same Flex 2 SWF. The Flex 2 SWF can do the same thing going back since both SWFs can independently register callbacks in JavaScript.

A fourth option is to create the SWF using the Flash 9 Public Alpha up on Adobe Labs (http://labs.adobe.com/technologies/flash9as3preview/). It has the ability to not only use ActionScript 3 in the Flash IDE, but can also produce Flash Player 9 SWFs. One technique in doing this is to have have AS3 in the talk up to Flex who is loading it. There are some small gotchas with "digging" your way up to talk to Flex, but it can be done.

So, why not use one of the above methods? First off, Flash is powerful; it's not just a design asset. So, simply being loaded in isn't good enough for some functionality: Flash and Flex need to talk. Secondly, LocalConnection isn't synchronous, and doesn't have good error checking. This makes debugging long and frustrating. Third, Externalnterface uses JavaScript. You've now gone from two languages to three; ActionScript 3.0, ActionScript 2.0 (or 1.0), and JavaScript as well as at least two different tools; Flex Builder for ActionScript 3.0 and JavaScript and Flash 8 for < in compiling when out code specific sound that comment to have you preloading, without via control can so your tag Embed the use if So, example. for mx.core.BitmapAsset and mx.core.SoundAsset not does currently alpha 9 Flash Flex. assets embed are interop with encounter you?ll problems only classes 3 ActionScript same share You future. solution viable a is thus coming? ?is since fourth about said be much there said, That flow. work production of part major software want don?t typically yet, released isn?t 9) (Flash Blaze Fourth,>

What Does Integration Get You?
If I'm making it sound like integration isn't actually the best solution, merely the lesser of the various evils, that's because it is. This is how things are, and even when Flash 9 is released, things won't be much better. Regardless, Flash can produce design content that Flex cannot, and used together the tools are powerful with the right team. Integrating Flash into the developer's work flow rather than as a design afterthought is the best thing to do on larger programming projects - which is typically what Flex is used for. Either that, or the primary skill set on your team is traditional programming, and thus the natural choice is Flex vs. Flash, in which case, Flash is the odd man out, but still a valid contributor.

As mentioned above, you can use the same code. You can write a Flash component in ActionScript 3.0 and use that same component in Flex. You can integrate it into the same Flex project and check it into the same version control. Traditional programmers will get that good feeling they typically don't get with Flash projects with regards to maintenance.

You can compile the same code in both programs. Since you are using ActionScript 3.0, Flex Builder, mxmlc, and Flash 9 can compile it. Granted, there are caveats with embedding, and it's a bitch. If I knew RegExp, I'm sure I could get an http://ant.apache.org/ Ant script to do it. Either way, you can even create Flash based test cases that you only use to test the Flash symbol class using the new Document class feature. Flex, which typically wraps the symbol class created in Flash in a UIComponent class via composition, can have its own test case.

You can compile once in Flash. Like the www.jessewarden.com/archives/2005/04/tried_eclipse_a.html MTASC days of old, mxmlc, the command-line Flex compiler has the ability to do bytecode injection; a.k.a. compiling incrementally. What this means is that you can compile in Flash for the mere sake of "getting the design assets into theSWF." If you later change the code in Flex, it'll merely change the code, but leave the original SWF design assets intact. Since you are embedding the symbol class into a main Flex SWF anyway, it'll compile the assets in the Flash SWF into the main one, and use the updated code you just changed. This is nice because it basically treats the SWFs as little design asset DLLs, so to speak, and uses the most up to date code. Unlike DLLs, the SWFs aren't needed at runtime . It also means that you don't necessarily need Flash to compile the Flex project, which scores major points with some traditional programmers. Third party developers and/or contractors, based on requirements, can deliver just a SWF to some clients or a SWF and a class(es) without having to turn over a FLA. I always give my source to clients, but I know some people have legal reasons for not being able to do so.

Finally, you can produce more types of components. Since Flash can do some crazy design ideas that Flex can't, or can't quickly, you can integrate a lot of that into components to be used in Flex; 3D exported to FLV integration, various compositing, and other hardcore visualizations.