CODEWITHSUNDEEP
flashapache-flexproject-managementflash-builderproject
Steven
Steven

Reputation: 1979

Flex/Flash Builder : Proper way to reference another project?

I have a fairly large Flex/Flash Builder project using Flash Builder 4.5. I want to create another project that uses some of the components from that original project. In the new project, I link resources with the original project and it works fine but the new project's file size is pretty large. It's close to the original project's file size even though it only uses a fraction of the components and assets. Is there a better way to do this to minimize the file size of the new project?

Upvotes: 5

Views: 2668

Answers (2)

RIAstar
RIAstar

Reputation: 11912

You should separate all the common, reusable code into one or more library projects. In FlashBuilder you cannot convert the nature of a project from application to library, so you'll have to create a blank library project and copy over the code that you want available in both projects.

In its simplest form you project structure should look like this:

Flex app project A (swf) \
                           Flex library project (swc)
Flex app project B (swf) /

Now to use that library, go to 'Properties > Flex Build Path', click the 'Add Project...' button and select the library project you just created.

add library project

Now that you've linked to that project, you want to choose how the referenced components will be linked. (Double click on 'link type' to edit.)

choose link type

With your way of linking your projects FB apparently just compiled all classes from project A into project B. That's obviously not what you want. These are your linkage options (for an application project):

  • merged into code: only the code that is actually referenced will be compiled into the main application. So if ClassA from the lib project is never referenced and ClassB is, only ClassB will be compiled into the main application.
  • RSL: nothing is compiled into the main application, but the library is loaded at runtime; completely, since we don't know which classes we are going to need. This library is cached on the client though, so you'll have the longer load time just once. The main application will be smaller than with 'merged' linkage.

Which option to choose depends on the situation and is entirely up to you. I suggest you play around to see the difference for yourself (use a real server, because on a local server you won't get a feel for the loading times).

I should also mention there is the external linkage option, which doesn't compile any classes into the main app and also doesn't load them at runtime. This is primarily used for dependencies between libraries that will be used as RSL's in the same main application.

Upvotes: 10

user797257
user797257

Reputation:

You should definitely look at what compiling with -link-report flag does. This prints the dependency map and would've showed you why are you using that many resources.

If you don't know how to do it: there's a place where you can add compiler arguments in the project settings - usually FB adds -locale=en_US there (which you actually don't need probably), add -link-report=report.xml and compile. It will generate an xml file in the root directory of your project. Open it and examine.

http://www.kahunaburger.com/2008/03/08/air-link-report-visualizer/ I didn't use this program, but it seems to give nice visual representation of dependencies - could be also useful.

Upvotes: 3

Related Questions