A few lessons learned while serializing custom classes.
Compiler metadata tags only get you part of the way. Metadata alone is perfectly suitable when you’re not serializing classes with members that contain complex datatypes where those complex types have private members.
If there are private members in your complex data types then you’ll need to implement IExternalizable.
IExternalizable requires implementing two methods, ‘readExternal’ and ‘writeExternal’.
Another thing to watch out for is that it appears you must use a no args constructor in order to deserialize an object. If anyone knows otherwise please leave details in the comments.
AS3 makes it ultra simple to serialize variables via the IDataInput and IDataOutput objects. You just need to remember, when writing out things like Strings, to use writeUTF / readUTF rather than writeUTFBytes / readUTFBytes. The writeUTF method inserts a UTF string representing the number of bytes in each String which means you don’t have to do any grunt work when deserializing with readUTF — nice.
5 Comments
Great article, I lost a lot of blood learning these things on my own :) but I would like to pass on another tidbit to add to your post. When your AS packages do not match your java classes you have to register the alias in addition to adding the meta data described above. The scenario is this:
AS3 class name: com.example.as.Widget
Java class name: com.example.java.Widget
Put this line somewhere in your startup class after importing your Widget
flash.net.registerClassAlias(”com.example.java.Widget”, Widget);
Everything should work from this point on, but as a best practice make sure your packages match!!
Thanks!
Using Blaze DS it seems to require on the JAVA side, that objects have public setter methods for properties. This doesn’t make sense to me but it seems so…
JL
We are currently using Granite Data Services (GDS) instead of BlazeDS (we were using it before BlazeDS was open-sourced); it provides a bit more flexibility when it comes to serialization. For example, it’s Externalizer’s provide an additional method, newInstance(…). We override this instead of readExternal(…) which allows us to use immutable objects (i.e. no setters; no default no-arg constructor). We haven’ had any problems with it so far.
Might be worth a look.
Jamie
Just use null defaults to get around constructor argument problems, we do this all the time.
public function AuthToken(token:String=null, perms:String=null, etc…){
}
Need 3 Flex engineers in New York City:
1. You have to be living in New York City for now.
2. Work part time or full time with us.
3. Good at Adobe Flex technology.
4. Please contact us for other requirement and details.
Busycode Inc. is a top Adobe Flex shop who develops Flex/AIR applications for clients.
For more info, please visit http://www.busycode.com