Slow Compiles in Flex Builder with Multiple Library Projects

/in , /by

At See4th, we are developing an Enterprise AIR application that has a growing number of Library Projects. We hit 10 rather large Library Projects a few days ago and could no longer deal with the pain associated with 2 minute compiles. So the solution took our compile times from over 2 minutes down to 5 seconds! The solution works for both Flex Builder standalone and Eclipse Plugin.

We have created two Eclipse/Flex Builder workspaces. Workspace “A” contains our Library Projects that are tested one at time with a “test harness” or “thin-client”. Since only a few Library Projects are open at any given time, builds are peppy.

Workspace “B” is where our main application lives. Instead of pointing the main application to all 10 Library Projects via App Properties > Flex Build Path > Library Path > Project, we point to src directory of each Library Project via  App Properties > Flex Build Path > Library Path > Source Path.

This has improved compile times significantly: from over 2 minutes down to about 5 seconds. Very nice. And if you use the “Linked Resources” feature of eclipse (ours is ‘FLEX_SERVER_ROOT’), there are no path conflict issues in a collaborative environment.

For those of you who haven’t migrated to the tiny six leg creature to do your compiles and prefer using Flex Builder or Eclipse Flex Builder plugin for the job, this a great way to get huge compile-time performance improvements with very little effort. Additionally, the two workspaces gives you the ability to build modular application components as a swc and improved compile times by accessing the swc’s source path.

Adobe Air Updater error 16824

/in , /by

Trying to do a quick test of the Adobe AIR Updater feature, I ran into Error# 16284 immediately after the download of the update air file.

Adobe AIR Updater Download Error 16824

A quick google search presented me with the following description:

16824 Invalid update descriptor. subErrorID may provide more information.

Although vague, it did lead me to the solution. In my haste to test the updater, I simply copied and pasted the  app_1.0.air file and renamed it to app_1.1. Then I set the updater.xml file’s <version> tag to ‘1.1’ pointed the <url> tag to the new ‘app_1.1.air’ file.

The problem occurs when AIR downloads the app_1.1.air file and inspects the <version> tag in it’s app-app.xml file. AIR did not like the fact that version number still remained at ‘1’ when it was looking for ‘1.1’.  A quick update to 1.1 in the version tag, and upload the new build and problem solved.

If I didn’t want to create a new build, I could have simply renamed app_1.1.air to app_1.1.zip, open the zip file, edit the app-app.xml file and named the file back to app_1.1.air.

Chalk it up to another copy and paste error of a different kind. I hope this saves someone a little time.