Flex Stuff by Gilles Guillemin

For the past few days, I’ve started – like many others – toying with the new kids on the block: namely Flash Builder 4 and Flash Catalyst. As I’m going back to implementing the Tailgate Platform, I’m considering switching straight ahead to the new versions, even though they are not fully completed. But before jumping in the dark (and into a possible nightmare) I’m weighting my options. Among the potential issues / greatness is the Flash Catalyst / Flash Builder workflow.

It seems that this famous seamless workflow between designers and developers is the selling point for Adobe. But it’s not quite there yet, unfortunately.

But it's not quite there yet...

And in order to solve this (temporary according to Adobe) problem, everyone brings their own contribution:

• Peter Molgaard came up with a Flash Catalyst / Flash Builder Workflow Optimizer Air application. It’s a very early thing so I won’t complain, at least he tried
• Marc Hugues found his own (and in my opinion excellent) way in A Flash Catalyst / Builder workflow method and its complement
• Yesterday, Mihai Corlan made a Round-trip Flash Catalyst and Flash Builder 4. Not the most straightforward ever though.
• This morning (who said it was a hot subject?) The Morphic Group provided some very good insights in Adobe Flash Builder and Catalyst Tips, Tricks, and Hacks

And now here is my own little contribution:

One important thing I’ve forgotten to mention in the video: the Catalyst project that shows up in /Users/{userProfile}/Library/Application Support/Adobe/Flash Catalyst/workspace/ (that’s OSX’ path) is temporary, so it is completely deleted whenever you quit Catalyst or create/open a new project. It also means that when you need to synchronize a project between Flash Builder 4 and Catalyst, the project must be open at the same time in Catalyst.

As you can see, it’s not particularly seamless either, but at least it doesn’t require (at the moment) any 3rd party software. Still, I consider working on an AIR app, somewhat similar but richer than Peter Molgaard’s, in order to ease the process, and possibly validate or not the modifications between the source and the target. A synchronizing tool if you wish. Until then, you’re good to go “manually”. If you do experiment this method, please do post your comments on the improvements, caveats, etc you might encounter.

Edit (25/06/09):
Marc Hugues published today an excellent update on why he thinks his approach is a good one, and one must admit that his arguments are solid (go and have a look, if only for the lovely diagrams ). I already believed it sounds like the right way when you think about team workflow (meaning more than a one designer/one developer or even a one-guy-using-the-two-softwares thing like I’m currently doing).
I’ll keep investigating my one-guy thing though (and try his when it’s time to do some real work)

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

(No Ratings Yet)

 Loading ...