Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Flex Modules – Introduction aux Modules Flex

Quand on parle de Modules Flex, on parle de fichiers SWF qui peuvent être chargés et déchargés par une application. Ils ne peuvent pas être lancés indépendamment d'une application, mais plusieurs applications peuvent se partager des modules.

Les Modules permettent de séparer votre application en plusieurs parties. L'application principale (aussi appelée la coquille/shell), peut dynamiquement charger les modules dont elle a besoin, quand elle en a besoin. Elle n'a pas besoin de charger tous les modules au démarrage. En fait, elle n'a même pas besoin de charger aucun module si l'utilisateur ne les utilise pas. Quand l'application n'a plus besoin d'un module, il peut le décharger pour libérer de la mémoire et des ressources.

Les applications modulaires ont les avantages suivants:

• Un temps d'initialisation de l'application plus court
• Un temps de téléchargement initial plus court (SWF principal plus léger)
• Une meilleure encapsulation des différents aspects de votre application. Par exemple, une fonctionnalité de "reporting" peut être séparée en un module sur lequel vous pouvez travailler de manière indépendante.

Ce que les modules peuvent apporter à votre application Flex

Un module est un type spécial de SWF pouvant être chargé de manière dynamique qui contient une Class Factory nommée IFlexModuleFactory. Cela permet à une application de charger du code à l'exécution et de créer les instances de classe sans que l'implémentation de la class soit liée à l'application principale.

Les modules sont similaires aux RSLs (Runtime Shared Library) en un sens car ils séparent le code de celui application dans un fichier SWF séparé. Les modules sont bien plus flexibles que les RSLs car ils peuvent être chargés et déchargés à l'exécution, et compilés sans l'application.

Les applications lourdes (en terme de poids) avec différent chemins-utilisateur et une application "portail" sont généralement de bons candidats à l'utilisation des modules.

Par exemple, prenez une grosse société d'assurance ayant une application qui contient des centaines d'écrans, pour l'assurance vie, l'assurance auto, l'assurance santé, l'assurance dentaire, etc.

En utilisant une approche traditionnelle RIA, vous allez créer une application monolithique (en un seul bloc) avec un arbre de classes MXML. L'utilisation mémoire et le temps de chargement de l'application seraient significatifs, et la taille du fichier SWF grandirait à chaque ajout de fonctionnalités.

Cependant, à l'utilisation de cette application, les utilisateurs ne vont accéder qu'à un sous-ensemble de ces écrans. En faisant un regroupement (refactor) des écrans en petits groupes de modules chargés à la demande, vous pouvez améliorer les performances de votre application principale et réduire l'utilisation mémoire. De plus, quand l'application sera séparée en modules, la productivité des développeurs sera meilleure, grâce à une meilleure encapsulation de l'architecture. Quand vous allez relancer un build de l'application, les développeurs n'auront qu'à recompiler une simple module au lieu de l'application entière.

En utilisant des modules, vous pourrez facilement créer une interface de "portail". Vous pouvez par exemple utiliser un XML pour déterminer quels modules charger pour une session.

L'API des Modules Flex en détails

Les Modules implémentent une Class Factory (une usine à classes pour les francophones) avec une interface standard. L'application principale et les modules connaissent ces interfaces (interface au sens programmatique).

En utilisant cette définition d'interface commune, on réduit les dépendances fortes entre la coquille et les modules. Cela permet d'avoir une communication typée et force à avoir une couche d'abstraction sans augmenter la taille du SWF.

La classe ModuleManager gère l'ensemble des modules chargés, qui sont traités comme une Map de singletons, indexés par l'URL du module. Le chargement d'un module déclenche une série d'évènements qui laisse le client visualiser le statut d'un module (en chargement, progression, complete, etc.).Les Modules ne sont chargés qu'une fois mais les tentatives de chargement suivantes vont aussi propager des évènements pour que le code client soit simplifié, et ne se base que sur l'utilisation de l'évènement READY pour informer que le module est prêt à l'emploi.

La classe ModuleLoader est une couche fine au dessus de l'API ModuleManager qui agit un peu comme la classe mx.controls.SWFLoader pour les modules qui ne définissent qu'un simple composant visuel UIComponent. La classe ModuleLoader est la class la plus simple à utiliser pour implémenter une architecture basée sur des modules. Cependant, la classe ModuleManager vous fournira un plus grand contrôle sur les modules.