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.