Beer Near Here Desktop Part 3: Setting up the Project in Flex Builder
After laying down the plan for this project I spent quite a bit of time with the setup in Flex Builder. If you’ve read my post, Flex Builder Optimization and You, you’ll know that I’ve done a bit of reading on setting up Flex projects for efficient work flows, particularly compile times, and I’ve come to the conclusion that it’s super, extra important to setup Flex projects well. Aside from the usual upshots of enhancing efficiency and the like, it’s been my experience that a well organized Flex project will load and compile significantly faster that one that’s been poorly organized. Trust me, I learned the hard way.
Beer Near Here Desktop makes use of three libraries, all of which are freely available:
- as3corelib for hashing methods
- Alex Uhlmann’s Distortion Effects for distortion effects
- My own Flex Library, available here.
Now there are a number of ways to link these libraries into the BNHD project, but it all pretty much boils down to two methods. Either I link the project into BNHD’s build path or I copy the SWC that the library produces into BNHD’s build path. My experience has been that neither of these methods is really better than the other and using one over the other largely depends on the nature of the library itself.
Often when people distribute their Flex code it is in the form of a SWC, so there will be plenty of cases where you’ll simply have to use this method. In the case of as3corelib, I downloaded the source so that I could disable the packages I didn’t need, but once I compiled a SWC for the project I included that into BNHD’s build path rather than the as3corelib project itself. As3corelib isn’t going to change beyond my initial modifications and once the SWC is exported I just copy and pasted into into BNHD’s libs folder. This allows the BNHD project to be more self-contained as it now no longer relies on the separate as3corelib project. I then repeated all of this for the distortion effects library.
My own personal Flex library is another matter. It’s very immature with few components and effects so as I work on projects like Beer Near Here Desktop I typically pull out a few of the more useful components and put them into my library. All this is to say, my library changes fairly frequently. In this case I’ve found simply adding the project rather than the SWC it produces to be a faster solution. The downside is that the BNHD project now relies on an external project, so both will have to be present and accounted for in Flex Builder in order to work with BNHD. Doing this also alleviates the need to continually rebuild my library project during development.
To summarize so far, external libraries, like those listed above should be placed into their own Flex Library Projects. Any library project that will remain static throughout development should be compiled into a SWC and copied into the main project’s lib folder. Any library project that will change frequently should be linked into the main project’s build path. Doing all this will prevent you from spending many minutes (or hours) watching your Flex projects compile all while keeping things nicely organized. I believe this is called a “win-win”.
The actual Beer Near Here Desktop project organization is very simple. In the project’s source folder I have three files: main.mxml, main-app.xml and style.css. The first two are the files that define any AIR app and style.css is the master stylesheet for the entire application. In the source folder I also have an images folder that contains all of the apps images and net.beernearhere folder that contains all the classes and components and whatnots specific to Beer Near Here Desktop.
I really cannot stress enough how much more efficient Flex Builder became once I started shunting things off into libraries and strongly recommend you do the same if you’re not already. As for how those projects should be organized, I leave that up to you. I showed how the BNHD project is setup because I’ll reference it later, but it’s pretty standard and really to each his (or her) own.
Hi Sean!
Thanks for your recent posts concerning project/library set up. Before I stumbled onto your site I had begun to use the practice of putting all of my .as and .mxml files into a Library Project.
But I’ve encountered a problem I’ve never had before. My project load time is up to 20 minutes and climbing with each day that new class files are added. Do you have any idea what would cause this kind of project load time? The crazy thing is this – the project has only just begun. We are three weeks into it and haven’t generated a ton of class files.
Any thoughts or suggestions would be greatly appreciated! Thanks for the posts!
Hey Jake,
There are a few things I’d take a look at. First of all, just to clarify so I’m sure we’re on the same page, I put all my general purpose, super-reusable code into a Library Project and keep all my project-specific code within the actual project. One of the goals of this being to cut down on needlessly recompiling the code stored in the Library as it tends to remain unchanged 95%+ of the time. So if you’re putting all of your code into a Library Project you’ll be recompiling everything in the Library each time you make a change. But it sounds like you’re not doing that anymore so here are a few suggestions:
1. Close any projects you are not currently working with that are open in the Flex Navigator. I have about 10 projects in the Navigator and Flex Builder slows to a crawl if they are all open at the same time. To close a project just right-click it and choose “Close Project”. You can open it back up again by double-clicking it.
2. Is any of your code located on a remote drive (a network share for example) or an external hard drive? I used to have a Library stored on an external disk and once I put it on a local disk compile and load times decreased noticeably.
3. Look at the Flex compiler options (http://livedocs.adobe.com/flex/3/html/help.html?content=compilers_14.html). Of particular interest is “incremental” which may or may not be enabled depending on how you compile your app.
4. Look at how your Library is linked into your app. I haven’t noticed any difference (for compile time) between using “Merged into code” versus “Runtime shared library”, but it _could_ have an effect.
5. What are the specs for the machine you are using? Overall I’d say Flex Builder is very slow on my main desktop running Windows Vista with a Pentium D and 2GB of RAM. It’s noticeably faster on my MacBook Pro running 10.5 with a Core Duo and 2GB of RAM. On the other hand the SWFs from FB Win are about one half the size of those from FB Mac with identical compiler settings.