Flex Monkey Patches

I am not sure if this is common knowledge. I googled and didn’t find any other reference to it. (At least not in 10 minutes of googling.)

I wasn’t sure this was possible, but then I decided to look in the Flex bugbase. This is what I found:

https://bugs.adobe.com/jira/browse/SDK-5308

Whaddaya know? An enhancement request that I logged that had actually addressed this issue back in the Flex 2.x days.

Basically if you change the extension of a swc to .zip, you can open the archive with winzip (or similar) and look at the top of the catalog.xml file. You should see something like this:

Hopefully this will help some folks out.

Incidentally such a thing does not exist for compiled swfs. There is an enhancement request:
https://bugs.adobe.com/jira/browse/SDK-14042

If you think such a thing would be valuable, please vote for the bug.

And one more thing…I actually had an AIR app back in the pre-release of AIR 1.0 days:
http://blog.flexmonkeypatches.com/2007/11/12/flex-sdk-fds-lcds-version-detection-adobe-air-application/

You could point it at a fds/lcds war or sdk directory and it would tell you the version (of LCDS and the SDK).
Maybe this should be resurrected and updated to AIR 1.5.1 and to use this new version info (at least new since I built the original AIR app). It could also be enhanced to read version info from individual swcs as well. Oh and maybe allow users to drag and drop directories, or wars or swcs onto the app to read the info. Hmmm….if only I had the time.

Tweet

3 Comments »

A useful compiler switch to help with this is the -dump-config switch.

If you add -dump-config=c:\mycfg.xml to the compiler, it will generate a config file that represents all the compiler (either for mxmlc or compc) settings used for compilation in a Flex Builder compile and then you can use that config file in a commandline compile to do an equivalent compile.

A few notes on the generated configfile.

1. The file is not perfect. I found that the tag that was generated only had a relative path generated. It is much better if that were absolute, so before I used the config file, I changed the value for that tag to something like:

2. For some reason the generated file has a token ${flexlib} which didn’t get resolved and filled in. I found that I could just comment out the 2 properties in the config file as they aren’t relevant to most compilations.

3. I found the easiest way to use mxmlc/compc was to copy the generated config file to the bin dir of the SDK under Flex Builder install. Then I could invoke mxmlc against the app like so:

./mxmlc -load-config+=mycfg.xml C:/myapp/src/app.mxml -output myswf.swf

4. For compc, the classes to actually compile to include in the generated swc aren’t actually output to the generated config file, so you have to add them manually (or on the commandline). I found the easiest way to do this was to add tags like below in the generated configfile

The content for those tags comes from the project file – .flexLibProperties which looks something like this:

The classEntry paths translate into the class tag values.
After doing this you can run compc like this:

./compc -load-config+=mycfg.xml -output myswc.swc

HTH

-Kyle

Tweet

No Comments »

I had seen references describing how to do this, but hadn’t seen a complete example, so I whipped this one up for a customer.

Using RemoteClass metadata triggers code gen in in the compilter to ensure that the class is registered with the VM before the application can use it, this includes receiving it from a network request. The only case in which this could be a problem is if it was being used with remoting and there wasn’t a corresponding server class that also implemented the flash.utils.IExternalizable interface.

Externalizable interface doesn’t effect the ability to be serialized in AS3, it just provides customization of what gets serialized. Generally it is only used to serialize private data or hide public data from serialization. Marking the class with [RemoteClass] is what allows the typed serialization of the object (again just mxmlc code gen at the right point using the registerClassAlias() method).

There aren’t any issues, at least none that we have hit, with LSO storage and custom serialization using IExternalizable. As long as the SWF that is retrieving the data from the LSO has the IExternalizable classes linked in and registered (potentially with a “dummy variable”) then I don’t know of any reason why that wouldn’t work.

The real work behind the scenes is done by using flash.net.registerClassAlias() and it is documented (although hard to find) at:
http://livedocs.adobe.com/flex/201/html/lsos_087_3.html

Browse the source of this example.
Download a zipfile containing the source to this sample.

Read the rest of this post»

Tweet

1 Comment »