Debug and describeType()

This post was written by jimrobson on September 3, 2012
Posted Under: Flash, Flex

My team is building an enterprise web application with a Flex UI that generates its screens at runtime based on XML files. It determines how to form its data service requests, what components to use, how to configure the components (line styles, custom data grid columns, etc.) all based on the XML, using a schema that we developed in-house. It’s a lot of fun.

The ability to quickly and easily introspect classes comes in very handy with this sort of development, since we don’t want to write or maintain a separate method for every class defined by our XML schema to instantiate itself. The native Flash.utils.describeType() is very useful here, as it gives a pretty complete description of the class in an easily traversed XML format. However, I learned that it can also be misleading.

I had created a single routine to initialize a wide range of classes from XML, and it worked perfectly - as long as it was running in debug mode. It took a while, but I found the cause of the propblem: describeType() gives more information when the SWF is compiled as a debug SWF than when it is compiled as a release SWF.

Screen shot depicting demo app compiled two ways (one as a debug and the other as a release SWF) and displayed in the same HTML wrapper.

Screen shot depicting demo app compiled two ways (one as a debug and the other as a release SWF) and displayed in the same HTML wrapper. Click image to view.

It’s not too surprising that such metadata as “__go_to_definition_help” is only available for a debug-version SWF. However, I did not expect to see something as useful as ArrayElementType omitted from the release SWF.


A couple of workable solutions have been posted here.


Reader Comments


The “-keep-as3-metadata” compiler option will sort that out for you.


Written By Simon Gladman on September 4th, 2012 @ 12:52 am

Simon: thanks - I knew I was forgetting something, but evidently used the wrong keywords when searching the docs. I solved the issue a different way, but will update the post so that it’s more useful.

Written By jimrobson on September 4th, 2012 @ 4:07 am

Perfect timing… Just today I was debugging a test suite failure where I observed the failure while manually debugging. The test’s assertion was comparing actual describeType output on the expected, hard coded output. The expected output was taken from running without debug mode, and the test was only failing in debug mode, but not in normal mode when running on Continuous Integration.

Not sure if we could use System.isDebugger() as a conditional switch or not, but ideally we could improve the test by having 2 expected values, one for debug mode and another for normal mode.

Written By Steven Erat on September 11th, 2012 @ 1:18 pm


Previous Post: Can Adobe kill Flash?