Marc Hughes


Home
Blog
Twitter
LinkedIn
GitHub
about
I am a developer from a bit west of Boston.

Why I like my proposed catalyst workflow

25 Jun 2009

I've been an advocate of compiling from Catalyst to a swc in a two previous blog posts.  (A Flash Catalyst / Builder workflow method , Compiling FXP->SWC, a Catalyst workflow) I'm hoping to explain why I prefer that workflow here.  With big pretty pictures!

First, let us look at the catalyst workflow that's been all the rage in the demos online that introduce catalyst (like this one).  Refer to the diagram below.

workflow1

Pros:

  • Super simple
Cons:
  • Limited to one designer and one developer
  • Limited to a single catalyst project
  • Developer can't start until designer is finished
  • Once the designer has handed off the file, they can't make edits.
If your software development process can handle those cons, this "super simple" option will rock for you.  But for anything beyond the most trivial of projects, those restrictions will be a deal breaker.  I consider this workflow similar to editing Actionscript in keyframes on the timeline in Flash.  It works, it's simple, sometimes it might be the right way of doing things, but most of the time it's like shooting yourself in the foot.

Something that hasn't been as widely discussed, but that is still part of the official offering from Adobe goes something like this diagram:

workflow2

In this scenario, the developer creates a plain old Flash Builder project.  While he's doing that, the designer creates a .FXPL file.  The developer takes that .FXPL and imports it as a Flex Library project, which he then references from his main project.  (Just import the .fxpl like a .fxp, the correct type of project is auto-created) Later, the designer can make changes in Catalyst.  Then the designer exports a new .FXPL file and the developer can re-import it (re-import steps below).

Optionally, the developer can move the classes into a package structure inside Flash Builder.  If there will be more than a single .fxpl imported, this is required since there will be name conflicts.  Currently, the refactor in Flash Builder doesn't work 100% for this as the skin references aren't updated, hopefully that's just a beta-bug and will be fixed.

This is a huge improvement over the previous workflow and will probably work out great for most people.

Pros:

  • Developer and Designer time can overlap
  • You can have multiple designers and developers (by repeating that middle bit in the diagram
  • Can use a package structure
  • An "official" Adobe method
Cons:
  • Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project.
  • Every time a new .FXPL comes out, the developer must (I bet some of this could be automated!):
    1. Delete the current Flex Library project
    2. Import the new .FXPL
    3. Modify the main project to reference this newly imported project
    4. Move the classes in the Flex Library project into a new package structure
    5. Rebuild the swc
    6. Rebuild the app
  • Does not retain the Main class from catalyst, so all work must be done in sub-components
That's doing a lot better in the scalability department.  It's doing a bit worse in the complexity department.

What if we could automate some of the process of turning a .FXPL into a .swc?  Or even better, what if we could turn a .FXP into a .swc?  Then we'd have something that looks very similar to the previous workflow, but with one important difference:

workflow3

Pros:

  • Developer and Designer time can overlap
  • You can have multiple designers and developers
  • The script automatically converts the Main catalyst component from an Application object to a Group object so you can use it in your project.  (Coming Soon!  The next version of my script will)
  • Automatically uses a package structure
Cons:
  • Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project. (But he only ever sees a swc now, so no worries)
  • Every time a new .FXP comes out, the developer must somehow get the new .swc (more on this below)
  • Requires a script to run (requiring whatever environment that script was written in)
That may seem like a fairly minor difference, but imagine how much better it scales.

Instead of a single developer and a single designer, picture a whole team of them.  If every developer needs to go modify their workspace every time any designer makes a new .FXPL, they'll end up spending too much of their time just managing their build environment.  The more people you add, the worse it gets.

If that script can be run through a command line script, it can be automated.

Most teams that consisting of more than a couple people use a version control system.  That system can be used to distribute .swcs that are generated from the catalyst projects.  Many version control systems have hooks integrated into them so they run a script whenever a certain file or directory is modified.  If yours doesn't have than a simple scheduled job could do it.  This can simplify the process even further to:

  1. Designer checks .FXP into version control
  2. Script runs, automatically generating the .swc
  3. Developers sync up, getting the new .swc
That means, once it's set up there is no additional work that needs to be done.  The designer works in his tool.  The developer works in his.  Assets are magically propogated.

If you don't use a version control system, scheduled jobs and a shared network folder could do the same thing.

This solves the scalability problem.

workflow4

All that is good-and-well, but that script to generate the .swcs must be awfully hard to do, right? Wrong. It was easy. It's done. Go give it a try.

Blog post describing the script. Download: fxp2swc.rb

Any windows based Ruby developers want to take a crack at updating the script to work correctly on windows?