Personally, I'd think long and hard before doing something like this. It really depends on how much of the actual "work" is in the very top layer of frosting, how much work is done in the "meat" of the AIR app, and what kind of feedback you need to have going between these layers.
Perhaps you can get the designers to build simpler components (buttons, window decorations, etc) in Flash using the FCK, and lay them out with MXML and Builder. If they're building SWCs with the FCK at least they can expose [Event] metadata and such, which will make life easier for whoever needs to tie things together in Builder for the AIR side of things. I'd be very loath to make SWFs part of my app for anything more complex than image resources. If it generates Events and exposes an API, I need to interact with it without regard for its internal timeline, the possibility of memory leaks caused by loading SWFs (mainly in Player 9), etc. I agree with them 100% that compile-time is horrible for Builder. Adobe knows this, and they're working on it. Building from Ant using MXMLC rather than Builder is apparently faster as-is, and I believe you can get a signifigant speedup using the compiler from Flex 4 but building against Flex 3 libraries. This opens you up to "issues" as Fx4 is still in early development, but most of the changes these days appear to be happening in Spark and the new MXML stuff, so building against the old namespace using the Halo components could be a helper. Also, recently on the FlexShow podcast they interviewed a guy (sorry, name escapes me) who's been backporting some of the speedups from Fx4 into Flex 3. They're not part of the official download, but I believe you can patch the compiler source, recompile with Java, and reap the benefits of his hard work without the technical risk inherent in building using the WIP Gumbo toolchain. Enough ranting and suggestions from me, I think - time to yield the floor! :) -Josh 2009/4/7 Scott Delap <scott-li...@richclientsolutions.com> > I have a question for the list. We are currently doing rapid UI > changes to our Air application. Our UI designers that have experience > with Flash have not been happy with the iteration turn around time of > "skinning" our UI's. Complains range from issues with compilation > time to being able to easily preview changes. They have proposed that > we develop our UI's in pure Flash with only Flash level UI controls. > We'd then embed these UI's as swfs in our Flex/Actionscript code. I > can see doing this for some UI components. However, I must admit I'm > very hesitant to implement the entire UI this way since it becomes one > big passive view black box. Would anyone else have pro's or con's to > such an approach? > > Scott > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." Josh 'G-Funk' McDonald - j...@joshmcdonald.info - http://twitter.com/sophistifunk - http://flex.joshmcdonald.info/
