Singleton, chargement de multiples applications Flex (SWF) et loaderContext
98% du temps, je vous dirais que la création de Singletons dans votre application est une mauvaise pratique, à éviter (par expérience). Bon, il reste 2%, tout premièrement car le framework Flex utilise lui-même des Singletons (chaque application est un singleton, mais aussi PopUpManager, DragManager, CursorManager & co). Et parfois, ils peuvent vous sauver la mise pour éviter de mettre en branle des techniques de sioux pour arriver à ses fins.
C'est ce qui m'est arrivé hier pendant mes développements dans une situation assez spéciale que l'on ne rencontre pas tous les jours.
Le contexte.
Je développe actuellement une administration pour un SIG Web qui consiste en une série d'applications Flex. Ces applications sont indépendantes dans leur fonctionnement et sont chargées par une application-mère qui consiste simplement en un TabNavigator contenant des SWFLoader.
Un petit schéma pour expliquer la situation:
La contrainte
Ces applications communiquent toutes avec un seul et même serveur baptisé Aigle. Ce serveur ne peut, par utilisateur, ne recevoir qu'une seule requête à la fois et c'est ici la contrainte qui nous intéresse. Si le serveur reçoit 2 requêtes du même utilisateur, la 2 sera mise en attente pendant un certain temps. Si la sous-application 1 fait une requête assez longue et que l'on bascule sur un autre onglet pour faire quelque chose qui va envoyer un autre requête, on tombera donc sur ce problème.
Le système d'envoi de requêtes en 2 mots
Pour envoyer des requêtes au serveur, j'utilise un Singleton (oui, c'est le dernier) nommé "RequestManager". Celui-ci s'occupe d'envoyer les requêtes au serveur à la chaine. Quand on tente d'envoyer une requête, on va simplement alimenter une pile de requête qui se dépile lorsque l'on reçoit le retour d'une requête. On a donc une FIFO (si je ne m'abuse) qui me permet de ne pas me heurter à la contrainte imposée par le serveur.
La classe RequestManager se trouve dans une librairie, utilisée par tous les projets.
Première approche, chargement simple des SWF applicatifs avec SWFLoader
Dans un premier temps, j'ai tenté de simplement créer des new SWFLoader et de faire un load(pluginPath.swf). Dans ce cas-là, chaque SWF est dans une "sandbox" locale. Il n'y a aucun partage de classe, chaque SWF est une entité bien distincte. Si on charge 6 sous-applications, on aura donc 6 instances bien distinctes de RequestManager (ce sont des Singletons par rapport à chaque SWF).
Flex Modules – TypeError: Error #1034: Echec de la contrainte de type : conversion de mx.managers::PopUpManagerImpl@18658d01 en mx.managers.IPopUpManager impossible [Résolu]
Voici un bug Flex que vous allez sûrement rencontrer si votre application comporte plusieurs modules à la fois. Ce n'est pas vraiment un bug en soi, c'est simplement un comportement du Framework Flex qu'il faut connaître pour éviter les surprises.
Le bug en question
Ce bug se produit de nombreuses manières différentes, mais toujours quand vous allez utiliser plusieurs modules dans une même application. Après des actions qui peuvent pourtant sembler banales, vous allez obtenir une RTE (RunTime Error) assez étrange du style:
TypeError: Error #1034: Echec de la contrainte de type : conversion de mx.managers::PopUpManagerImpl@18658d01 en mx.managers.IPopUpManager impossible. at mx.managers::PopUpManager$/get impl()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\managers\PopUpManager.as:68] at mx.managers::PopUpManager$/addPopUp()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\managers\PopUpManager.as:169] at mx.controls::ComboBox/getDropdown()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\controls\ComboBox.as:1459] at mx.controls::ComboBox/displayDropdown()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\controls\ComboBox.as:1552] at mx.controls::ComboBox/downArrowButton_buttonDownHandler()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\controls\ComboBox.as:1801] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\core\UIComponent.as:9298] at mx.controls::Button/http://www.adobe.com/2006/flex/mx/internal::buttonPressed()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\controls\Button.as:2504] at mx.controls::Button/mouseDownHandler()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\controls\Button.as:2750] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\core\UIComponent.as:9298] at mx.controls::ComboBase/textInput_mouseEventHandler()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\controls\ComboBase.as:1388]
Cette erreur de conversion (Coercion) se reproduit facilement sur le PopUpManager ou sur le DragManager mais peut aussi se produire avec vos propres classes. Vous obtiendrez des messages qui pourront vous sembler étranges. Par exemple:
TypeError: Error #1034: Type Coercion failed: cannot convert MyClass@5d73ce1 to MyClass.
Une conversion de type entre un type MyClass et le même type MyClass qui ne fonctionne pas, il y a de quoi se poser des questions. Ce bug a été maintes fois reporté sur la Bug Base d'Adobe (SDK-16474, SDK-14384, …) mais peut facilement être corrigé.
Un exemple d'application qui pose problème
Flex Modules – Décharger (Unload) correctement ses modules
Le principal intérêt des modules Flex est de découper votre application en plusieurs SWF pouvant être chargés et déchargés à la volée. Le fait de décharger (unload) permet de libérer la mémoire prise par le module une fois qu'il n'est plus utilisé. Cependant, même en faisant un unload() du module, il ne sera pas forcement libéré de la mémoire par le Garbage Collector. En effet, si des références vers ce module existent toujours, le module ne sera pas libéré. Parfois ces références sont évidentes mais parfois elles sont plus difficiles à trouver, surtout quand elles se trouvent au fin fond du framework Flex.
La Flex Team a publié un article pour récapituler les principales cause connues qui font qu'un module n'est pas libéré de la mémoire. Voici le détail.
Chargement de modules dans différents "applicationDomain"
Le fait de charger des modules depuis différents "applicationDomain" peut obliger Flex à référencer des classes dans ses Managers. Ces références peuvent causer la persistence du module en mémoire. Essayez de charger les modules avec l'applicationDomain par défaut (en utilisant les paramètres par défaut de la méthode load().
Fuites mémoire
Les "Memory leaks" peuvent créer des références vers votre module qui vont empêcher le Garbage Collector de libérer le Module Flex de la mémoire. Voici les causes principales:
Styles
Cela se produit même sans tag mx:Style dans votre MXML. Si votre module utilise un composant qui n'est pas utilisé par l'application principale, le module va enregistrer le style par défaut pour ce composant dans le StyleManager et coincer la première instance de votre module. Vous pouvez utiliser l'option du compilateur -compiler.keep-generated-actionscript pour voir quels styles le module et l'application principale utilisent. Vous pouvez aussi utiliser l'option -compiler.keep-all-type-selectors dans l'application principale pour forcer l'application principale à enregistrer les styles par défaut de chaque composant dans le fichier defaults.css. Les CSS chargés à l'exécution (StyleManager.loadStyleDeclarations) ne sont pas concernés par ce problème car ils sont chargés de manière différente.
Resources
Si votre module utilise des composants qui utilisent de ResourceBundles non-utilisés par l'application principale, ces Resource Bundles vont être enregistrés dans le ResourceManager et coincer la première instance du module. Vous pouvez utiliser l'option du compilateur -compiler.keep-generated-actionscript pour voir quels Resource Bundles le module et l'application mère utilisent. Vous pouvez forcer l'application principale à avoir ces Resource Bundles additionnels en ajoutant les metadata du Resource Bundle dans l'application principale.
Par exemple, vous ajouter le Resource Bundle "controls", vous devez ajouter à votre application:[ResourceBundle("controls")]. Si vous chargez vos Resource Bundles comme des modules, assurez-vous que les Resource Module ont bien fini leur chargement avant de charger le module Flex qui utilise le Resource Bundle.
ExternalInterface.addCallback
Les modules ne devraient pas utilier la méthode ExternalInterface.addCallback(). Cela enregistre la méthode dans le navigateur et il n'y a, à ce jour, aucun moyen de la supprimer. Il est recommandé de laisser l'application principale enregistrer une méthode qui va appeler une référence de fonction. Il suffit ensuite de remplacer cette référence par la méthode du module. Quand le module est déchargé, il suffit de mettre cette référence à null.
Timers et autres mécanismes de Timing
L'utilisation de Timer, setTimeout() et setInterval() peuvent causer des fuites mémoire. Les Timer doivent être arrêtés et avoir leurs listeners supprimés. setTimeout et setInterval doivent faire quant à elles appel à clearTimeout() et clearInterval() pour pouvoir être GCed correctement.
Listeners sur évènements depuis des objets à l'extérieur du module
Utilisez des références faibles (weak references) ou assurez vous d'avoir bien supprimé les event listener. Rappelez-vous que lorsque vous appelez A.addEventListener("foo", B.someMethod), "A" a une référence vers B, et pas l'inverse.
Focus
Si un des objets du module a le focus, le FocusManager aura toujours une référence vers le module. Il est conseillé de bouger le focus vers un autre objet à l'extérieur du module avant de le décharger.
RemoteObject
Si un module amène une nouvelle classe qui va faire partie d'une requête serveur, cette classe va être enregistrée par Flash Player et amener une référence vers le module. Liez les Data Classes à l'application principale lorsque c'est possible.
Images chargées
Si un module charge une image, cette image doit être déchargée sinon Flash Player va garder des buffers autour de cette image.
Autres éléments à connaitre
Une fois qu'ils n'y a plus de référence vers les objets d'un module, Flash Player peut encore garder un module en mémoire pendant un moment si certains des objets d'un module on eu le focus. Essayez de taper du texte ou de cliquez dans l'application pour éventuellement libérer des références vers le module.
Les versions Debug d'un module peuvent empêcher le module d'être libéré de la mémoire. Les version de debug contiennent des informations de debug qui peuvent être enregistrées par le debugger. Assurez-vous de tester avec des versions realease des modules et une application lue par un Flash Player classique.
Mes projets (Open Source)
Autres
