Actionscript 3 :: Object Initialization Occur When Deserializing Binary Objects In Flex?

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:[code]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.