On embedding XML

If you're embedding huge gobs of XML (damned if I know why you'd need to do this): Pasting the XML into a class as a static XML object seems to offer the best performance and compression. The compile-time processing and optimization is significant.

Recompress your Flash 11 SWFs with LZMA

Flash 11 can load SWFs that have LZMA compression; previously SWF contents were either uncompressed or zlib-compressed.

Since the mxmlc compiler doesn't yet support this compression, and since it was a PITA to compile Tinic Uro's zlib2lzma on anything but Windows (http://blog.kaourantin.net/?p=124), and since no one else seems to have done it... I wrote a Python script to do the conversion. Woot. It only requires that the input SWF be compiled with -swf-version=13 (or higher). It will fail if you feed it an LZMA-compressed SWF -- feel free to fork me on GitHub and fix that.

Usage: python swf2lzma.py in.swf out.swf

Grab the code from: http://github.com/jspiro/swf2lzma

build decay chronograph

After hours of coding and reloading, I constantly forget whether I reloaded a browser tab under development, and otherwise question whether the SWF actually got rebuilt (and am often wrong on both counts).

Enter the BuildDecayChronograph, an object that shows you how long it's been since a given SWF was last built, and a quick visual indicator from green to red of how fresh it is (for me, 5 minutes). The only requirement is that the given SWF was compiled with mxmlc.

Usage:
addChild(new BuildDecayChronograph(5*60, 'engine'));

Download from GitHub.

---

This could not have been done without the brilliantly hacky org.igorcosta.hacks.SWF

Blog Text and Codes (Igor Costa ) / CC BY-NC-SA 3.0

unable to transcode this meaningless error message

If you're compiling with mxmlc on Linux, and you get the 'unable to transcode' error message, and you're transcoding hundreds of files... and you've wasted two days on this (no, I'm not bitter):

>: ulimit -a

That may be really small. Like 1024 files. Try compiling again after:

>: ulimit -n 5000

Better? mxmlc swallows the Java IO error #fml >_<

Tailing Flash

>: tail -f /Users/jspiro/Library/Preferences/Macromedia/Flash\ Player/Logs/flashlog.txt

How did it never occurred to me to tail with Flash before? Shameful.

Though, really, I wish I could control who gets to write to that log, or identify who IS writing to it -- there's so much spam from other running SWFs.

Dragging's a Drag

For reasons that are beyond my comprehension, Flex List components have a property to allow moving of list items, but not one for copying.

If you allow moving, then you SURELY must also want to allow a poor implementation of copying, whereby your object is deep copied rather than cloned via some interface, putting Objects into your dataProvider rather than whatever class you were using. Also, copying is enabled by holding the control key -- not obvious to me, at least.

package
{
import mx.events.DragEvent;
import mx.managers.DragManager;

import spark.components.List;

/** Disables copy-dragging on List */
public final class NonCopyableList extends List
{
 override protected function dragDropHandler(event:DragEvent):void {
  event.ctrlKey = false;
  event.action = DragManager.MOVE;
  super.dragDropHandler(event);
 }
 
 override protected function dragOverHandler(event:DragEvent):void {
  event.ctrlKey = false;
  super.dragOverHandler(event);
 }
}
}

You're welcome.

Best Practices when Listening

* Try to always use a weak listener, even though it's extra typing. The classes of bugs you are exposed to with strong listeners are mostly running out of memory, taxing the garbage collector, and killing performance as you take memory off the heap -- they creep up and are hard to detect. The classes of bugs with weak listeners are functionally worse -- but easy to detect -- stuff just doesn't work because the listeners got GCed (they are a little less performant too, due to tracking their weak-ness).

* When writing weak listeners: Make sure that objects you are listening on will not get prematurely garbage collected and are attached to something -- either the class, or some static Singleton.

* Make sure the object will get garbage collected eventually and write a comment about it.

* Assume that all weak listeners and objects will never get GC'd and will keep listening forever -- code for this. In other words, explicitly remove listeners when it is IMPERATIVE that you do not receive any more messages, do not rely on setting a parent to null to break the cycle.

* You DO NOT have to remove weak listeners if it doesn't matter if they continue to receive events until they GC -- e.g. a mouse move handler -- once you've removed the object from the display list, it doesn't matter that this handler MIGHT run. If you code your handlers to guard against runtime errors, then you never have to remove weak listeners. And if the listeners are still receiving after a long while... then you have a memory leak and the object you are listening on is not getting GC'd (see this post).

* If you are going to skip removing a listener, DOCUMENT IT at the line where you add the listener. If you won't document it, then don't do it.

* This is tricky stuff, so treat listeners with respect like you would NEW and DELETE in C++. Work them out in your head -- document the hell out of them. They are expensive and cause almost all memory and (many) performance leaks.