The Proxy class has no constructor, and you should not attempt to instantiate Proxy. Instead, subclass the Proxy class to override methods such as getProperty and provide custom behavior. If you try to use a method of the Proxy class without overriding the method, an exception is thrown.

And, keep in mind, your own code overriding the methods of the Proxy class can throw exceptions unintentionally. Throwing exceptions when using these methods causes problems because the calling code (using operators like in, is, delete and others) does not expect exceptions. Unless you're already sure your overriding method does not throw exceptions, Adobe recommends using try..catch statements around your implementation of the Proxy class to avoid fatal errors when operators call your methods. For example:

The Proxy class is a replacement for the Object.__resolve and Object.addProperty features of ActionScript 2.0, which are no longer available in ActionScript 3.0. The Object.addProperty() feature allowed you to dynamically create get and set methods in ActionScript 2.0. Although ActionScript 3.0 provides get and set methods at compile time, you cannot dynamically assign one to an object unless you use the Proxy class.

To avoid collisions with the public namespace, the methods of the Proxy class are in the flash_proxy namespace.

Where methods of the Proxy class take a name argument, name can be either a String or a QName object (if namespaces are being used).

Note: The ByteArray class is for advanced developers who need to access data on the byte level.

In-memory data is a packed array (the most compact representation for the data type) of bytes, but an instance of the ByteArray class can be manipulated with the standard [] (array access) operators. It also can be read and written to as an in-memory file, using methods similar to those in the URLStream and Socket classes.

In addition, zlib compression and decompression are supported, as well as Action Message Format (AMF) object serialization.

Possible uses of the ByteArray class include the following:

• Creating a custom protocol to connect to a server.
• Writing your own URLEncoder/URLDecoder.
• Writing your own AMF/Remoting packet.
• Optimizing the size of your data by using data types.
• Working with binary data loaded from a file in Adobe^® AIR^®.

All IDataInput and IDataOutput operations are "bigEndian" by default (the most significant byte in the sequence is stored at the lowest or first storage address), and are nonblocking.

Sign extension matters only when you read data, not when you write it. Therefore, you do not need separate write methods to work with IDataInput.readUnsignedByte() and IDataInput.readUnsignedShort(). In other words:

• Use IDataOutput.writeByte() with IDataInput.readUnsignedByte() and IDataInput.readByte().
• Use IDataOutput.writeShort() with IDataInput.readUnsignedShort() and IDataInput.readShort().

Content in Flash Player or Adobe^® AIR™ can interface with a server by using the binary protocol of that server, directly. Some servers use the bigEndian byte order and some servers use the littleEndian byte order. Most servers on the Internet use the bigEndian byte order because "network byte order" is bigEndian. The littleEndian byte order is popular because the Intel x86 architecture uses it. Use the endian byte order that matches the protocol of the server that is sending or receiving data.

If a class does not implement, nor inherits from a class which implements, the IExternalizable interface, then an instance of the class will be serialized using the default mechanism of public members only. As a result, private, internal, and protected members of a class will not be available.

To serialize private members, a class must use the IExternalizable interface. For example, the following class will not serialize any of its members because they are private:

However, if you implement the IExternalizable interface, you can write to, and read from, the data stream the private members of the class as follows:

Note: If a class implements IExternalizable the default serialization no longer applies to instances of that class. If that class inherits public members from a super class, you must carefully manage those members as well.

When a subclass of a class implementing IExternalizable has private members of its own, the subclass must override the methods of IExternalizable, as follows:

The IExternalizable interface can also be used to compress data before writing it to a data stream. For example:

You can create Timer objects to run once or repeat at specified intervals to execute code on a schedule. Depending on the SWF file's framerate or the runtime environment (available memory and other factors), the runtime may dispatch events at slightly offset intervals. For example, if a SWF file is set to play at 10 frames per second (fps), which is 100 millisecond intervals, but your timer is set to fire an event at 80 milliseconds, the event will be dispatched close to the 100 millisecond interval. Memory-intensive scripts may also offset the events.

All IDataInput and IDataOutput operations are "bigEndian" by default (the most significant byte in the sequence is stored at the lowest or first storage address), and are nonblocking. If insufficient data is available, an EOFError exception is thrown. Use the IDataInput.bytesAvailable property to determine how much data is available to read.

Sign extension matters only when you read data, not when you write it. Therefore you do not need separate write methods to work with IDataInput.readUnsignedByte() and IDataInput.readUnsignedShort(). In other words:

• Use IDataOutput.writeByte() with IDataInput.readUnsignedByte() and IDataInput.readByte().
• Use IDataOutput.writeShort() with IDataInput.readUnsignedShort() and IDataInput.readShort().

The following statements show the relationship between a Dictionary object and a key object:

 var dict = new Dictionary();
 var obj = new Object();
 var key:Object = new Object();
 key.toString = function() { return "key" }
 
 dict[key] = "Letters";
 obj["key"] = "Letters";
 
 dict[key] == "Letters"; // true
 obj["key"] == "Letters"; // true
 obj[key] == "Letters"; // true because key == "key" is true b/c key.toString == "key"
 dict["key"] == "Letters"; // false because "key" === key is false
 delete dict[key]; //removes the key