Blog

Had a hell of a time debugging some OpenAMF calls yesterday. Turns out, when Flash deserializes your class, it basically takes a vanilla object, puts properties on it and assigns their values, and then points that instance’s __proto__ property to the prototype of the class you registered via Object.registerClass. The downside to this is it doesn’t run your setter functions on any getter/setters you have set on the class. Naturally, your getters fail immediately because they look to a private equivalent variable which is different, and when you call the setter… it’s really a function.

How Flash manages to keep “firstName” the public property and “firstName” the public getter function in the same namespace is beyond me, but regardless, I’ve tested in Flashcom last night, and the same thing happens there, too, so it appears to be how Flash deserializes your class.

The way we, “solved it” as my manager says, or “worked around it” as I claim, is emulating, EXACTLY the Java class equivalents. So, you have private properties in the Java model class, like:

private String firstName;

And same on the Flash side:

private var firstName:String;

And instead of getter/setter functions in Flash, you just use the get/set function methology:

public function getFirstName():String
{
return firstName;
}

public function setFirstName(val:String):Void
{
firstName = val;
}

I really don’t like this at all, and personally feel that there should either be an event letting you know when the class is deserialized (Flashcom does this for server-side ActionScript classes via the onInitialize event) so you can then run the getter/setters yourself, OR Flash should just intrinsically know there are getter/setters in place, and set the private variables accordingly. This gets sticky though because you’re now having the Flash Player run code on your classes. Thus, I vote for the first.