Flash Builder Beta2, Catalyst, asset organization, FXP->SWC

Published on November 25, 2009 in Uncategorized. 3 Comments

Today, I’ve been experimenting with project structure and workflows.  I’ve got two major problems I want to solve.

Problem #1

When working in Flex Builder, if you have a lot of non-embedded assets, it can go really slow.  At seemingly random times Eclipse will decide it needs to delete all of your output files and re-copy them.  For our current project, that can take 10 minutes.  We have yet to figure out what triggers this behavior.

Problem #2

When working in Flex builder, if you have a lot of embedded assets, it can go really slow.  Especially on clean builds, or builds that touch a lot of modules.  This is an every-compile type thing, but is far less severe than problem #1.

Solution for Problem #1

Don’t let Eclipse do the copying for you.  Put your assets outside of your source tree, and turn off “Copy non-embedded assets”.  To the right is an example directory structure.  There are a few differences than most Flex/Flash builder projects.

  1. My assets folder is a sibling of my src folder, instead of inside it.
  2. My compiler is set to output to assets/bin-debug instead of just bin-debug

In your source, you’ll have to link to your assets a little bit differently.  Here’s an example from my TestProject.mxml that shows both an embedded and a runtime loaded asset.

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
  3.          xmlns:s="library://ns.adobe.com/flex/spark"
  4.          xmlns:mx="library://ns.adobe.com/flex/halo"
  5.          minWidth="1024" minHeight="768"
  6.  
  7.         <s:layout>
  8.         <s:VerticalLayout />
  9.         </s:layout>
  10.         <mx:Image source="@Embed(‘../assets/art/Image1.png’)" />
  11.         <mx:Image source="../art/Image2.png" />
  12. </s:Application>

Since the embed is relative to the source folder, we need to use paths in the form of ../assets/art/*

The runtime loaded assets are relative to the final compiled location, so those take the form ../art/*

Now, eclipse will never try to manage your assets.  This appears to completely solve problem #1.

Solution for Problem #2

A while back I blogged about turning a Flash Catalyst project into a .swc.  (Read that here)

I dusted off my script and tried it with the Beta-2 of Flash Builder and Catalyst.  And low-and-behold it worked without any changes.  The only thing I had to do was reset my FLEX_HOME environment variable to the new location.

So, if we were to move away from a model where we embed assets from designers into Flash Builder, and to a model where the Designer puts those assets into Catalyst, and then we run a script to compile the catalyst project into a .swc, I think that would completely solve problem #2.

3 Responses to “Flash Builder Beta2, Catalyst, asset organization, FXP->SWC”

Feed for this Entry
  • Dan
    November 25, 2009 at 6:14 pm

    Awesome, thanks for the tips!

  • Dan
    November 28, 2009 at 12:40 am

    I am having trouble getting your solution #1 for a runtime loaded asset working in an AIR application. I got it working just fine in just a web application. Can you try this out in an AIR application to see if it works for you?

  • Marc
    November 28, 2009 at 5:24 pm

    I bet it won’t work in AIR.

    This is taking advantage of the fact that we control the source-time location and the deploy-time location of the files. In an AIR file we can’t control that deploy-time location, at least not relative “up” from the main swf. Perhaps it would be possible to make them siblings.

Comments are currently closed.