La classe Proxy ne possède pas de constructeur et il n’est pas recommandé de l’instancier. Utilisez la classe Proxy en tant que sous-classe pour bloquer des méthodes telles que getProperty et fournir un comportement personnalisé. Si vous tentez d’utiliser une méthode de la classe Proxy sans la bloquer, une exception est renvoyée.

N’oubliez pas que, si votre propre code bloque les méthodes de la classe Proxy, des exceptions risquent d’être renvoyées non intentionnellement. Le renvoi d’exceptions lors de l’utilisation de ces méthodes est source de problèmes, car le code appelant (qui utilise des opérateurs tels que in, is, delete, etc.) ne s’attend pas à des exceptions. A moins d’être certain que la méthode de remplacement ne renvoie pas d’exceptions, Adobe recommande l’utilisation d’instructions try..catch de part et d’autre de votre implémentation de la classe Proxy afin d’éviter les erreurs irrémédiables lorsque les opérateurs appellent vos méthodes. Par exemple :

La classe Proxy remplace les fonctionnalités Object.__resolve et Object.addProperty d’ActionScript 2.0, qui ne sont plus disponibles dans ActionScript 3.0. La fonctionnalité Object.addProperty() vous permet de créer dynamiquement les méthodes get et set dans ActionScript 2.0. Bien que ActionScript 3.0 fournisse les méthodes get et set à la compilation, il est impossible d’en affecter une dynamiquement à un objet sans utiliser la classe Proxy.

Pour éviter les doublons des espaces de noms public, les méthodes de la classe Proxy sont dans l’espace de noms flash_proxy.

Si les méthodes de la classe Proxy nécessitent un argument name, name peut correspondre à un objet String ou QName (sous réserve d’utiliser les espaces de noms).

Remarque : la classe ByteArray s’adresse aux développeurs chevronnés qui doivent accéder aux données au niveau des octets.

Les données en mémoire correspondent à un tableau contracté (la représentation la plus compacte du type de données) d’octets, mais une occurrence de la classe ByteArray peut être manipulée avec les opérateurs [] (accès au tableau). Ces données peuvent également être lues et écrites sous forme de fichier en mémoire, en utilisant des méthodes similaires à celles des classes URLStream et Socket.

En outre, la technologie zlib de compression/décompression est prise en charge, de même que la sérialisation d’objet AMF (Action Message Format).

Exemples d’utilisation de la classe ByteArray :

• Création d’un protocole personnalisé pour établir une connexion à un serveur
• Ecriture de votre propre URLEncoder/URLDecoder
• Ecriture de votre propre paquet AMF/Remoting
• Optimisation de la taille de vos données à l’aide de types de données
• Utilisation des données binaires chargées à partir d’un fichier dans Adobe^® AIR^®.

Toutes les opérations IDataInput et IDataOutput utilisent l’ordre d’octet « bigEndian » par défaut (où l’octet le plus significatif de la séquence est mémorisé dans l’adresse de stockage de plus bas niveau ou dans la première adresse de stockage) et ne sont pas bloquantes.

L’extension de signe ne joue un rôle que lors de la lecture des données et non lors de leur écriture. Il est donc inutile d’utiliser des méthodes d’écriture distinctes pour faire appel à IDataInput.readUnsignedByte() et IDataInput.readUnsignedShort(). En d’autres termes :

• Utilisez IDataOutput.writeByte() avec IDataInput.readUnsignedByte() et IDataInput.readByte().
• Utilisez IDataOutput.writeShort() avec IDataInput.readUnsignedShort() et IDataInput.readShort().

Le contenu de Flash Player ou d’Adobe^® AIR™ peut interagir avec un serveur en utilisant directement le protocole binaire de ce dernier. Certains serveurs utilisent l’ordre d’octet bigEndian, tandis que d’autres font appel à littleEndian. Sur Internet, la plupart des serveurs utilisent l’ordre d’octet bigEndian, car « ordre d’octet du réseau » correspond à bigEndian. L’ordre d’octet littleEndian est le plus populaire car il est utilisé par l’architecture Intel x86. Utilisez l’ordre d’octet correspondant au protocole du serveur qui envoie ou reçoit les données.

Si une classe n’implémente pas l’interface IExternalizable et qu’elle n’hérite pas d’une classe qui implémente elle-même l’interface, une occurrence de la classe est sérialisée par le biais du mécanisme par défaut réservé aux membres publics. De ce fait, les membres privés, internes et protégés d’une classe ne seront pas disponibles.

Pour sérialiser les membres privés, une classe doit utiliser l’interface IExternalizable. Par exemple, la classe suivante ne sérialisera aucun de ses membres, parce qu’ils sont privés :

Cependant, si vous implémentez l’interface IExternalizable, vous pouvez lire et écrire dans le flux de données les membres privés de la classe, comme suit :

Remarque : si une classe implémente Externalizable, la sérialisation par défaut ne s’applique plus à ses occurrences. Si cette classe hérite des membres publics d’une super-classe, vous devez également les gérer avec soin.

Lorsqu’une sous-classe de la classe qui implémente IExternalizable possède des membres privés qui lui sont propres, elle doit remplacer les méthodes de IExternalizable, comme suit :

L’interface IExternalizable permet également de compresser les données avant de les écrire dans un flux de données. Par exemple :

Vous pouvez créer des objets Timer pour les exécuter une seule fois ou à intervalles spécifiés, afin d’exécuter du code conformément au planning défini. Selon la cadence du fichier SWF ou l’environnement d’exécution (mémoire disponible et autres facteurs), le moteur d’exécution risque de distribuer les événements à intervalles légèrement décalés. Par exemple, si la cadence d’un fichier SWF est de 10 images/seconde (i/s), soit une fréquence de 100 millisecondes, mais que votre horloge est réglée de sorte à déclencher un événement à 80 millisecondes, l’événement sera déclenché à une fréquence proche de 100 millisecondes. Les scripts qui consomment beaucoup de mémoire risquent également de décaler les événements.

Toutes les opérations IDataInput et IDataOutput utilisent l’ordre d’octet « bigEndian » par défaut (où l’octet le plus significatif de la séquence est mémorisé dans l’adresse de stockage de plus bas niveau ou dans la première adresse de stockage) et ne sont pas bloquantes. Si les données disponibles sont insuffisantes, une exception EOFError est renvoyée. Utilisez la propriété IDataInput.bytesAvailable pour déterminer le volume de données disponible pour la lecture.

L’extension de signe ne joue un rôle que lors de la lecture des données et non lors de leur écriture. Il est donc inutile d’utiliser des méthodes d’écriture distinctes pour faire appel à IDataInput.readUnsignedByte() et IDataInput.readUnsignedShort(). En d’autres termes :

• Utilisez IDataOutput.writeByte() avec IDataInput.readUnsignedByte() et IDataInput.readByte().
• Utilisez IDataOutput.writeShort() avec IDataInput.readUnsignedShort() et IDataInput.readShort().

Les instructions suivantes indiquent les relations qui existent entre un objet Dictionary et un objet clé :

 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