Flex Monkey Patches

Here are some debugging tips I provided to a customer this week regarding debugging ant tasks that seemingly compiled a Flex app that used dataservices fine, but the app didn’t seem to get any data. The are generally useful, so I thought I would post them.

1. Try setting fork=”false” in your mxmlc and compc ant task, since forking the compile process will hide the stdout and stderr streams from the compile process and hide any errors or warnings that may be happening in the compile process, setting the fork to false will allow you to see any compile output in your console.

2. In your ant target echo out a formatted statement that would represent the equivalent mxmlc (or compc) commandline statement with all variables and relative paths, etc. resolved. Then you can use this echoed statement to run against mxmlc to help detangle yourself from ant to rule that out as a source of problems or rule out any pathing issues.
(Maybe you are not pointing to correct sevices-config.xml file?)

3. Make sure your dataservice tags and dataservice operations have fault handlers. (Maybe faults are being returned from the dataservice or the operation, but they are not being handled.)

4. Compile the Flex app with and run in the debug Flash Player. This should produce logging info in the flashlog.txt that is helpful for watching the network traffic between your Flex app and a server and may help narrow down the issue.

http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=logging_125_10.html

5. Look in your LCDS install dir under resources/config at the services-config.xml. This file is a sample config file that has comments explaining the various settings. You want to look at the logging tag and enable more verbose serverside logging.

You should probably set the logging tag like this:

(This will log “Debug level” output to your servlet container’s logs.)
The default patterns are probably sufficient to start with, but this sample config file lists all the possible debug patterns. If the debug level does not result in enough info, you may want to try the “All” level.

6. Use a network traffic sniffing tool like Charles: http://xk72.com/charles/ to view traffic between browser and server.

Tweet

No Comments »

I recently had a customer who was trying to debug his Flex components. Under certain circumstances the updateDisplayList() method of his component was getting called and it wasn’t obvious why.
In writing and debugging Flex components sometimes it would be useful to be able to see who called what method to figure out what is going on. Profilers are good for this, but unfortunately there is no Flex 2.0 (or 2.0.1) profiler. In speaking with Flex Engineer, Alex Harui (see his blog here), he suggested the strategy below:

• Subclass the component you are interested in (or if you are writing your own components just add the following to your component).
• Override the invalidateDislayList() method (or whatever method you are interested in).
• Create a new error object.
• Dump out the error objects getStackTrace() method.

This should get you the hierarchy of calls that caused the invalidateDisplayList call.
(And it is the calling of invalidateDisplayList that will flag the updateDisplayList() to be called.)

Read the rest of this post»

Tweet

No Comments »