views:

454

answers:

1

The jist of what I'd like to know and focus on understanding, is details on how binary deserialization occurs in Flex 3. When is the constructor called, when are properties set, are private members serialized or does all deserialization occur on and through setters, etc? I'm having a hard time finding information on this.

In a Flex 3 AIR application, I have a pretty complex object graph(just a bunch of objects referencing one another, kinda like a big data model except a bit more complex) that I serialize to a file using a single call on the FileStream.writeObject and readObject on a root object, which serializes and deserializes the entire object graph.

I found that I needed to always have a default constructor, else I would get exceptions on the objects when deserializing if they were part of an ArrayCollection. So I had to eleminate the constructor parameters or set default values. I now have many setters like this in my classes, such as the below where mConnection accumulates some information it needs through different setters, where as before I had this all packed into the constructor since all of the information is really necesary for the Connection to function:

class Client
{
 private var mConnection:Connection;
 public function get connection():Connection{ return mConnection; }

 public var mUser:User;
 public function get user():User { return mUser; }
 public function set user(value:User):void 
 {
  mUser = value;
  mConnection.username = user.username;
  mConnection.password = user.password;
 }

 private var mServer:Server;
 public function get server():Server { return mServer;}
 public function set server(value:Server):void 
 { 
  mServer = value;
  mConnection.serverIP = value.serverIP;   
 }

 public function Client()
 {
  mConnection = new Connection();
 }   
}

public class Server
{
 [Bindable]
 public var Clients:ClientsCollection  = new ClientsCollection( );//contains Client type 
 private var mServerIP:String;
 public function get serverIP():String { return mServerIP; }
 public function set serverIP(value:String):void 
 {
  mServerIP = value;
  serverName = mServerIP;
 }

 public var serverName:String;

 public function Server(serverIP:String = "")
 { 
  this.serverIP = serverIP;
 }
}

This seems to work fine for the most part, before I added serialization. I serialize the object graph when the application closes, and deserialize it when the application opens. What I was having happen

When I added serialization, I run into the problem that after deserialization, the mConnection will sometimes have an empty string, and sometimes will have the ip address that was serialized. What seems to be happening as best I can tell, is that sometimes the objects are deserialized in a different order, and then objects are assigned to properties in varying order. So let's say at the time I serialize the object graph, I have an isntance of a client, with a reference to an instance of a server and a connection, and one sequence of events during deserialization(just a single call to readObject) might be:

  1. Connection is constructed.
  2. Connection's properties are set with deserialized values.
  3. Server is constructed with default constructor(has empty string for serverIP)
  4. Server values are deserilized and set through the setters, restoring the serverIP to "127.0.0.1" or whatever it was.
  5. Client is constructed
  6. Client's server property is assigned with the previously constructed server instance, causing the connection's serverIP value to be set via this setter.

In this scenario, the Connection has the correct server ip. I think, seemingly at random, the below is happening sometimes however, causing the connection's serverIp to be an empty string after deserialization is complete.

  1. Connection is constructed.
  2. Connection's properties are set with deserialized values.
  3. Client is constructed
  4. Server is constructed with default constructor(has empty string for serverIP)
  5. Client's server property is assigned with the previously constructed server instance, causing the connection's serverIP value to be set to an empty string via this setter.
  6. Server values are deserialized and set through the setters, restoring the serverIP to "127.0.0.1" or whatever it was.

So the connection's serverIP is still an empty string because the server was assigned to the client's property before the server was completely initialized.

I could probably resolve this by using binding so that updates to the serverip in the server are bound to the connection, but I find binding properties to be fairly complicated (it's really simple on UI in mxml cause you just use the curly bracket syntax but doing it by code is what I found complicated). I have also resolved some cases by removing the constructor parameters entirely, so that there is no default values. All that aside, I still really need a deeper understanding of the details of binary serialization as far as how it rebuilds the object graph. I even have circular references, and it seems to handle those fine and maintain multiple references without duplicating objects. It's just when my constructors/setters are more complex that I'm running into these problems because of the order of what occurs during deserialization. It is really inconsistent though, as adding breakpoints in various places seems to influence the order that things occur, making it more difficult to debug.

On a side note for anyone that might sidetrack the topic because I am serializing a class called Connection. I added some code to address some things, like in the Connection class there is an instance of a Socket. Of course my socket would not be connected after I close and reopen the application and deserialize it, so before I serialize my object graph, I go through and close the socket and set the reference in the Connection class to null, so that there is no longer a reference to the socket and thus it will not get serialized. After deserialization on the next application run I create a new socket.

+1  A: 

Sort of a side-note: you can use a static function as a pseudo-overloaded constructor

class Fred
{
    public function Fred()
    {
        // boring, default constructor with no parameters
    }

    public static function Freddy(aValue1 : String, aValue2 : Object = null) : Fred
    {
        var result : Fred = new Fred();

        result.value1 = aValue1;
        result.value2 = aValue2;

        return result;
    }
}

(Yes, I do miss my Object Pascal virtual constructors, why do you ask?)

Richard Haven