« July 2008 | Main | September 2008 »
August 25, 2008
Using Flex SWCs within Flash CS3?
Can you use framework-less Flex 3 SWCs within Flash CS3? I assumed that you could do this if the compatibility-version flag was used and you didn't use any of the Flex framework. I haven't been able to get this to work, however, so I'm hoping someone else has had some luck with this. I've also asked about this on flexcoders, so I'll update this post with any information I learn there.
There's little information out there on this subject. Tim Walling has a post on this which points to some problems, but there's nothing else that I've been able to google. I'm surprised that there's not more people who are stuck on this.
A colleague of mine, Crystal West, is the person who is really banging her head on this. She created an example to show the issue. The example has two SWCs within it, one created using Flash Authoring and one created using Flex 3. Try compiling swc_test.fla with just flash_bc_ads.swc in the same directory (that is, remove flex_bc_ads.swc). The fla should compile fine. Then try with just flex_bc_ads.swc. You should get a number of compile errors for the AdTranslator class.
She tried a lot of variations on compiling with flex_bc_ads.swc, and nothing has worked. flex_bc_ads.swc was built using the compatibility flag and doesn't use any of the Flex framework. She also tried compiling the Flex SWC using compute-digest=false (as recommended by the Tim Walling post mentioned above). That didn't work either, and, according to some of the comments on this blog post, didn't work for others.
Anybody have any experience here or any suggestions?
Update: A minute after I posted, Oscar told me about a Yahoo post on the subject. It doesn't seem like this is the same problem, however, since a related post says the problem is "code SWCs". So hopefully this isn't our problem, since we are trying to create a SWC which can be used as a Sprite.
Solution: There's a new post with an update on the issue.
August 11, 2008
New Flex Blog by Al Manning
Al Manning has an excellent new Flex blog. Some of you may remember Al from his days working on Spectra at Allaire. I've gotten to know him as a lead Flex developer at Brightcove.
He already has some long posts on unit testing and assertions. I know he'll have a lot more posts about Flex, so go check it out.
Improving the Flex Ant Tasks
I've been looking at ways to improve some Ant Flex builds, and in the process I've added "arg" support to the Flex Ant tasks. I'll show how this can be done below, and I'll also share a bit about my investigation into speeding up Flex builds.
I wanted to convert some Ant builds to use the Flex Ant tasks, but it's painful to convert Ant targets that use "java". The problem is that all existing "java" calls will use command-line arguments, aka the "arg" element. The "arg" elements follow the command-line use of mxmlc and compc, and it's a different format than the Ant tasks.
In order to get the "arg" support, you'll have to do the building of the Ant tasks yourself. I could have just provided the jars here, but I don't have a clean copy locally. And it's good to have the source locally to know how to make more changes. Here's the steps:
1. Download the Flex 3 source.
2. Open the Ant tasks you want to alter. They're found in "modules/antTasks/src/flex/ant/".
3. Add the following line somewhere within prepareCommandline():
cmdl.addArguments(getCommandLine().getJavaCommand().getArguments());
4. Recompile the jar by running "ant" when in the directory "modules/antTasks". You'll have a new version of the Ant tasks at "lib/flexTasks.jar".
If anybody creates a version of the flexTasks.jar with just this change, I'll link to it here.
Why would you want to convert existing targets to use the Flex Ant tasks? I thought that the usual reason was to get wildcard support for compc arguments, but I don't see this feature in the documentation. In any case, Brightcove already had this support through some complicated Ant work. The reason I was looking into this was for some performance improvements.
I thought I could get some speedup by keeping a bit of shared state between compilations, and doing this required some Flex Ant task and compiler changes. I had forgotten, though, how much shared state is needed to really improve the performance. So although I started to convert over some of the Ant targets, in the end I left them all as "java" calls.
A better approach to getting some faster Ant builds is to use the compiler API in a set of new Ant tasks. If anybody has any Ant tasks out there for this, I'd be interested in using them. I know about the Maven support, but it looks to me like I need to create some Ant tasks myself to take advantage of the compiler API.
