2012/02/28

debugging like a boss: AS3 (Flash CSx and Flex)

debugging techniques in AS3 are quite similar to PHP's techniques, but there are some key differences:
  • unless you use one of the debugger players, you're in tough luck -- you'll get no error messages, your script will just break and do nothing. so get one. if you use the debugging player plugin, choose a browser you don't use primarily -- because with debugging enabled, you'll be very surprised by the number of buggy flash movies on the net. and you don't want to have your flash game experience interrupted by constant error messages, do you?
  • while console output is possible, even in the plugin versions, it's a hassle to get it going. you'd be much better off using the JS console or the alter popup of your browser to output errors (through using ExternalInterface calls) or native flash alert windows.
  • AS3 is very picky, and can die even on the slightest mistake. and not even Flex Builder helps in a lot of instances.
  • flash movies are not linear in execution, rather they are event-driven. that makes simple rundown debugging impossible, but you can still use the watch point techniques as described with PHP.
  • sandboxes are very important in AS3; please check adobe's documentation regarding this issue. a lot of broken scripts actually just try to step outside their security sandboxes, and get zapped in exchange.
  • since it's flash, you can't write a debug log file anywhere. sorry. all you have is the console and the builtin alerts and external JS calls.

some tips:

  • if you are developing in Flash CSx, use the console logging option, as the IDE will show you that.
  • if you are developing in Flex, use either mx.controls.Alert.show('your debug msg'); to pop up your own debug messages, or use an ExternalInterface call and either log to the browser's console or use its alert popups.
  • if you are developing in Flex, always use the swfs in the bin-debug folder, because a release-exported swf will throw error messages, however without any useful info regarding files or line numbers. however, once your app is ready, always do a release export, because you a) don't want your files to be twice as big as necessary (yup, lots of debugging information inside!), and b) you don't want to expose your sources to the world...
  • use the try..catch construct in AS3 as well, sometimes it's the only way to avoid your script breaking down on some miniscule error (all errors, regardless of their severity, stop the flash movie's main thread dead in its tracks).
  • you can use the /* ... */ commenting out and then moving bit-by-bit technique as i've shown you for PHP here as well; but never forget to recompile your movie by each bit.
  • if you use the standalone player (projector), you must assume the worst security sandbox, and you won't have access to the ExternalInterface methods. be prepared for that.
  • always remember you're developing in an event-driven environment.

No comments:

Post a Comment