Flex RSL – Les différents types de RSL
Si vous avez plusieurs applications Adobe Flex, vous aurez sûrement des librairies de classes / composants partagées que vous réutilisez sur plusieurs applications. Pour cela, vous pouvez utiliser les RSL: Runtime Shared Libraries. Le but est toujours le même: s'assurer qu'un minimum de code soit téléchargé par l'utilisateur.
Une RSL est une librairie, distincte du SWF de l'application principale et qui sera téléchargée par Flash Player une seule fois, si elle n'est pas encore disponible. Une fois qu'elle est disponible, elle peut être utilisée par plusieurs applications sans devoir être téléchargée à nouveau.
Différents types de liaison avec les librairies Flex: Static Linking et Dynamic Linking
Pour savoir s'il est mieux pour vous d'utiliser des RSLs ou pas, il faut bien comprendre la différence entre les différents types de liaison avec des librairie Adobe Flex.
Static Linking
Le type de liaison ("Linking") par défaut est Static Linking. Toutes les classes nécessaires à l'application sont compilées en un seul lot ("bundle"). L'avantage principal est un chargement des classes plus rapide à l'exécution et donc un meilleur temps de réponse. Le principal inconvénient est un temps de téléchargement plus long (fichier SWF final plus lourd) et l'inclusion possible de classes redondantes dans de multiples applications qui pourraient partager ces classes.
Dynamic Linking
Le type de liaison Dynamic Linking est une alternative au static linking. Dans ce cas là, les classes sont toutes rassemblées dans un "bundle" unique (fichier SWF) qui peut être chargé à l'exécution.
Avantages et inconvénients liés aux RSLs
Les RSL ont les avantages suivants:
- La taille du fichier SWF de l'application principale est réduite. Cela accélère le démarrage de l'application pour une meilleure expérience utilisateur
- Une RSL est téléchargée une seule fois et ré-utilisée autant de fois qu'on le souhaite sur plusieurs applications.
- Permet une ré-utilisation du code pour une meilleur organisation applicative
Flex Modules – Chargement de Modules depuis des serveurs différents (allowDomain)
Un module Flex est un fichier SWF que l'on peut charger dans une application mère. Si vous charger un module en ligne qui se trouve sur le même serveur que l'application principale, vous n'aurez aucun problème. Cependant, pour charger un module depuis un autre serveur, vous devez indiquer au module et à l'application, les domaines auxquels ils peuvent accéder.
Permettre l'accès entre les domaines
- Dans votre application mère, vous devez appeler la méthode allowDomain() et spécifier un domaine cible depuis lequel vous allez charger votre module. Faîtes bien cette étape au moment de l'évènement preinitialize de votre application pour vous assurer que l'application est bien en place avant le chargement du module.
- Dans le fichier cross-domain.xml du serveur distant où se trouve votre moule, ajoutez une entrée qui spécifie le serveur sur lequel l'application à charger se trouve.
- Chargez le fichier cross-domain du serveur distant lors du preinitialize de votre application.
- Dans le module chargé, appelez la méthode allowDomain() pour qu'il puisse communiquer avec l'application que le charge.
L'exemple suivant montre la méthode init() de l'application mère:
public function setup():void {
Security.allowDomain("remoteservername");
Security.loadPolicyFile("http://remoteservername/crossdomain.xml");
var request:URLRequest = new URLRequest("http://remoteservername/crossdomain.xml");
var loader:URLLoader = new URLLoader();
loader.load(request);
}
Le code suivant montre la méthode init() du module chargé:
public function initMod():void {
Security.allowDomain("loaderservername");
}
Et voici le fichier crossdomain.xml à placer à la base du serveur distant:
<!-- crossdomain.xml file located at the root of the server --> <cross-domain-policy> <allow-access-from domain="loaderservername" to-ports="*"/> </cross-domain-policy>
Création d'Applications Flex – Flash Player Security (crossdomain)
Flash Player applique des règles de sécurité pour l'accès à la données depuis une application. Les applications Flex peuvent accéder toutes les sources de données qui sont sur le même domaine que le SWF. Par exemple, si le SWF est déployé sur www.exemple.com, il peut accéder à un webservice qui est déployé sur www.exemple.com.
Cependant, l'accès aux données sur différents domaines est interdit par le Flash Player, sauf si le domaine lui donne la permission explicite. Les règles de sécurité de Flash Player interdisent l'accès à la donnée si les domaines ne correspondent pas exactement, y compris les sous-domaines. Cela veut dire qu'un SWF déployé sur www.exemple.com ne peut pas accéder les données de test.exemple.com ou même exemple.com sauf si le serveur lui donne l'accès.
Pour que le serveur donne l'accès aux données, on utilise un fichier appelé cross-domain.
Flex LocalConnection – Communication en Cross-Domain
Dans le tutorial Flex sur les LocalConnection simples, nous avons assumé le fait que les deux SWF qui communiquent sont sur le même domaine. Par défaut, Flash Player interdit les LocalConnection entre des SWF chargés depuis des domaines différents. Cependant, vous pouvez explicitement autoriser la communication en cross-domain pour le SWF récepteur.
Il y a deux types de communication cross-domain par une LocalConnection: les domaines connus et les domaines inconnus. La communication avec les domaines connus se présente lorsque les deux SWF communiquant se connaissent entre eux et connaissent les domaines sur lesquels ils sont hébergés. Cependant, il y a bien des cas pour lesquels les domaines ne sont pas connus au moment de la compilation. Par exemple, vous pouvez utiliser une LocalConnection pour créer une application type plug-in qui va interagir avec de nombreuses applications. Dans ce cas, vous ne connaîtrez pas nécessairement tous les domaines possibles à l'avance.
Mes projets (Open Source)
Autres
