There are basically two kinds of class mappings between the Server and the Client in a Flash application.
Both techniques are based on something called ClassAlias, which the Flash Player uses to define which class to instantiate when it gets an AMF message containing a serialized object from the server.
The ClassAlias is a string value which corresponds to the classname on the server. When an object is serialized from the server into AMF object-notation, this classname is then added to the AMF message making it possible for the Flash Player to read upon receiving it from the server. The ClassAlias (which again is a fully qualified string literal representing the complete classname) is associated with a client class definition.
This is most easily understood by looking at the class registerClassAlias found in the flash.net package, the following excerpt is taken from the documentation of registerClassAlias:
It preserves the class (type) of an object when the object is encoded in Action Message Format (AMF). When you encode an object into AMF, this function saves the alias for its class, so that you can recover the class when decoding the object. If the encoding context did not register an alias for an object’s class, the object is encoded as an anonymous object. Similarly, if the decoding context does not have the same alias registered, an anonymous object is created for the decoded data.
LocalConnection, ByteArray, SharedObject, NetConnection and NetStream are all examples of classes that encode objects in AMF.
The encoding and decoding contexts do not need to use the same class for an alias; they can intentionally change classes, provided that the destination class contains all of the members that the source class serializes.
There is one challenge in using this class to create class aliases, and that is that the class definition itself needs to be loaded at the time of the actual call to registerClassAlias. If the class is not available at the time of the call, the player will throw a TypeError.
The second way of adding class mappings is by adding the RemoteClass metatag to the class element of an ActionScript class.
Essentially it does the same thing, but instead of you having to make explicit calls you can just add the metatag to the ActionScript classes that correspond to your server classes.
There is another challenge with this approach, and that is that it will not work if you have not already loaded the class definition prior to getting instances from the server. This eventually means that you would have to do some initialization to trigger the loading of the ClassAlias, or you would as I see used as the most prevalent workaround for the challenge, that people create dummy-variables in the root of the application they never instantiate, just to ensure that the class definition has been loaded. This obviously is not very nice.
Personally I also don’t like this way of doing it because it lacks flexibility since I prefer to centralize classmappings. This is mostly due to the fact that servers and clients tend to change independently of eachother and it tends to get tricky if the server definitions are spread out through the application. If you then add multiple application domains on top, it becomes impossible to maintain a stable and clearly defined mapping between client and server.
For very simple applications I recommend using the RemoteClass metatag, however for larger applications the scalability and flexibility of registerClassAlias comes in quite handy.