Ha! I serialized a display object. Didn’t think it could be done, but with a little work it can be. See my previous post about overriding Transform and Matrix objects for a little more context. I’m jumping right in to how I did it.
So the main problem before was the Transform class requiring a parameter in its constructor. So I subclassed Transform and made that parameter optional. Turns out if you pass in null to the superclass you get an error too, so if no displayObject is passed in I use a Shape. (I figured it was one of the cheaper display objects to make, though between that and Bitmap I’m not sure.) No I need to subclass Sprite so that it uses my new Transform subclass.
MyTransform:
public class MyTransform extends Transform
{
public function MyTransform(displayObject:DisplayObject = null)
{
super(displayObject || new Shape());
}
}
MySprite:
public class MySprite extends Sprite
{
private var _transform:MyTransform;
public function MySprite()
{
super();
_transform = new MyTransform(this);
}
public override function get transform():Transform
{
return _transform;
}
public override function set transform(value:Transform):void
{
_transform = new MyTransform(this);
_transform.colorTransform = value.colorTransform;
_transform.matrix = value.matrix;
}
}
Proof that it works:
// register all the classes required to store a sprite
registerClassAlias("MySprite", MySprite);
registerClassAlias("MyTransform", MyTransform);
registerClassAlias("MySoundTransform", SoundTransform);
registerClassAlias("MyMatrix", MyMatrix);
registerClassAlias("MyColorTransform", ColorTransform);
var sprite:MySprite = new MySprite();
trace(sprite.transform is MyTransform); // true
var ba:ByteArray = new ByteArray();
ba.writeObject(sprite);
ba.position = 0;
sprite = ba.readObject();
trace(sprite.transform is MyTransform); // true
Yeah!! It totally worked! And I could add that sprite to the display list and everything!
Now a couple of things to note: when serializing only read/write variables are stored. So Sprite’s and Shape’s graphic property is not stored. Neither is parent or any of the children because they aren’t referenced by any properties that can be written too. So if you draw on your shape or sprite with the drawing API it won’t be stored. Of course, this can be worked with if you have methods that draw on creation, or if you store some of Flash 10’s new IGraphicData objects publicly which can be drawn. You could also store all your sprite’s children in a public array that has to be set like the filter array for it to alter the display list. Then you could serialize your whole display tree. :) Might be fun.
Oh, and one more quickie that I double tested to make sure. I was told at one of our uFlash meetings that private properties are stored in serialized bytearrays. This didn’t seem consistent with what I understood, so I tested and retested and it is only public properties with getters and setters that are stored. Tyler said people sometimes had issues when they put [Bindable] at the top of a class and the complier made everything public (even privates) so that they would work with binding. But that’s a compiler issue with how it rewrites code. Private properties are not stored in bytearrays.