Construire une architecture de plugin avec Adobe AIR

Question

Je songe à choisir Adobe AIR comme technologie d'implémentation côté client pour un projet à venir. (Le choix précédent était C # et WPF, mais je suis très impressionné par Flash / Flex / AIR ces derniers temps.)

Mais l’une des fonctionnalités les plus importantes de mon produit sera son architecture de plug-in, permettant aux développeurs tiers d’étendre les fonctionnalités et l’interface graphique de manière intéressante.

Je sais comment concevoir l'architecture en C #: un chargeur de plug-ins énumérerait tous les assemblys du répertoire local & "app / plugins / &"; annuaire. Pour chaque assemblage, il énumérerait toutes les classes, recherchant les implémentations de & "IPluginFactory &"; interface. Pour chaque plug-in créé par l’usine, je lui demanderais ses classes MVC, et jetterais ses éléments d’interface graphique (éléments de menu, panneaux, etc.) dans les emplacements appropriés de la présentation d’interface graphique existante.

J'aimerais réaliser la même chose dans AIR (charger des plugins à partir du système de fichiers local, pas du Web). Après avoir lu cet article , je crois comprendre que c'est possible et que L’architecture de base (chargement de fichiers SWF dans ApplicationDomains en mode bac à sable, etc.) est très similaire à celle utilisée dans .NET.

Mais je suis curieux de connaître les pièges.

Si vous avez déjà effectué un chargement dynamique de classe avec le lecteur flash (de préférence dans des applications mixtes flash / flex et particulièrement avec l'hôte AIR), j'aimerais connaître votre expérience de la construction de votre framework de plug-in et de votre parcours dans des situations délicates avec Flash Player et avec les API flash, flex et AIR.

Par exemple, si quelqu'un me posait la même question, mais en gardant à l'esprit la plate-forme Java, je dirais que la JVM n'a aucune notion des & "; modules &"; ou " assemblies " ;. Le plus haut niveau d'agrégation est la & "Classe &"; Il est donc difficile de créer des structures organisationnelles au sein d'un système de plug-in pour la gestion de grands projets. Je parlerais également des problèmes avec plusieurs chargeurs de classe et de la façon dont chacun gère sa propre instance distincte d’une classe chargée (avec ses propres vars statiques distincts).

Voici quelques questions spécifiques qui me sont restées sans réponse:

1) Le actionscript " Chargeur " La classe peut charger un fichier SWF dans un domaine ApplicationDomain. Mais que contient exactement cette application? Modules? Des classes? Comment les composants MXML sont-ils représentés? Comment trouver toutes les classes qui implémentent mon interface de plug-in?

2) Si vous avez chargé un plugin dans un ApplicationDomain distinct de l'application principale, est-il beaucoup plus compliqué d'appeler du code à partir de cet autre domaine d'application? Existe-t-il des limitations importantes concernant les types de données pouvant passer par la couche de marshalling inter-applications? Le marshalling est-il prohibitif?

3) Idéalement, j'aimerais développer la majorité de mon propre code principal sous forme de plug-in (l'application principale ne représentant guère plus qu'un shell de chargement de plug-in) et utiliser l'architecture de plug-in pour intégrer cette fonctionnalité dans l'application. . Cela vous fait-il peur?

Answer 1

Luca Tettamanti a déjà donné de bonnes réponses à vos questions spécifiques, je vais donc simplement vous proposer quelques informations supplémentaires sur le sujet général:

J'ai implémenté une API de plug-in simple pour une application Flex à l'aide du ModuleManager classe (et les autres éléments de mx.modules .) L’essentiel est de sous-classer les plug-ins de ModuleBase et d’utiliser IMyAppPlugin dans l’application hôte pour les charger. Ensuite, les plugins implémentent une interface commune (par exemple MyAppFacade implements IMyAppFacade) et utilisent une sorte de façade pour représenter et implémenter l'interface avec l'application hôte que les plugins peuvent utiliser (par exemple <=>.). Chaque fois que les plugins sont chargés, injectez-y cette référence de façade.

Le sujet " Applications modulaires L’affichage général " de l’aide de Flex 3 contient quelques informations utiles (le sous-chapitre " Domaines de modules " traite des domaines d’application dans le contexte des modules. ) Voici un extrait:

  

" Par défaut, un module est chargé dans un domaine enfant du domaine en cours.   domaine d'application. Vous pouvez spécifier un   domaine d'application différent en utilisant   la propriété applicationDomain du   Classe ModuleLoader. & ";

Le sujet " L’utilisation de la classe ApplicationDomain & Quot; approfondit le sujet des domaines d’application, et vous devriez absolument la lire si vous ne l’avez pas déjà fait.

Answer 2

1. Le domaine d'applicationDomain s'apparente davantage à un espace de noms. Il regroupe les définitions de classe et les place dans une hiérarchie: un domaine peut accéder directement aux symboles de son propre domaine ou du domaine parent, mais pas dans l'enfant. ou des domaines frères (ou mieux: il ne peut pas le faire directement - il doit passer par l'objet applicationDomain, demandant la définition d'une classe donnée); Lorsque vous chargez un fichier swf externe, vous pouvez décider où placer les nouveaux symboles: un domaine enfant (par défaut), un nouveau domaine lié au système (à l'aide de null), le actuel . domain, un domaine attaché ailleurs (en passant explicitement le parent du nouveau domaine). Notez que les nouveaux symboles ne remplaceront jamais les symboles du domaine actuel, mais que le même nom peut exister dans plusieurs domaines.
   Malheureusement, vous ne pouvez pas énumérer les classes d'un domaine donné (enfin, du moins, je ne connais aucun moyen de le faire), mais la solution courante consiste à exiger (comme dans & "L'interface du plugin &"; ) la présence d’une fabrique connue dans chaque fichier swf, qui renverra soit la définition (classe) du plugin, soit le plugin lui-même.
2. Il vous suffit d'aller chercher une référence à l'objet (l'usine), alors il ne s'agit que d'un autre objet. Il n'y a pas de triage: le domaine n'est qu'un partitionnement logique de l'espace de noms (c'est une branche du domaine du système).
3. Non :) Mais soyez averti: cela peut facilement devenir un enfer pour le GC, où les domaines inutilisés ne peuvent pas être déchargés en raison de références répandues dans un autre domaine. Je suggère de jeter un coup d'œil au framework multicœur PureMVC, éventuellement avec des tubes pour assurer une séparation stricte entre les plugins.

Btw, Flash Player est aussi un concept de domaine de sécurité, mais je ne l'ai jamais touché, alors je ne sais pas quelles sont les possibilités ici.

Answer 3

Avez-vous essayé de charger des sous-applications?
Il existe une bonne documentation pour le faire dans AIR et j'ai réussi en quelques heures. Cependant, la même implémentation est une histoire différente dans Flex en raison d'une violation de sandbox entre une sous-application et une application principale. J'ai passé des semaines à cogner ma tête contre le mur.

Answer 4

Réponse à la déclaration concernant Java en tant qu'architecture de plug-in possible:

Il s’avère que Java est utilisé depuis de nombreuses années pour concevoir des systèmes d’architecture de plug-in. Pour ce qui est du côté client, les cadres de gestion de modules OSGi d’Equinox sont probablement les mieux connus. À un moment donné, l'EDI Eclipse a restructuré son architecture de plug-in au-dessus d'Equinox OSGi. Eclipse IDE est peut-être l’un des systèmes d’architecture de plug-in côté client les plus aboutis à ce jour - du point de vue de la longévité historique ainsi que de l’ampleur de la base d’utilisateurs et de la communauté de développement de plug-ins qui lui a succédé. Ils proposent également leur architecture de plug-in en tant que cadre fondamental pour la conception d’applications côté client arbitraires - Eclipse RCP.

J’ai juste dû interrompre cela parce que, même si Java était peut-être considéré comme un choix très faible, il a en réalité beaucoup plus de succès que n’importe quel autre environnement d’exécution / langage à ce jour pour fournir des systèmes de ce type, en particulier par rapport à C #. .NET, qui, bien sûr, a une bonne facilité innée pour les modules. C'est un peu ironique, mais vous l'avez.

En ce qui concerne Adobe AIR, je suis en train de gérer un projet conçu par AIR. Dans notre cas, l'extensibilité de nos modules sera toujours fournie à partir du serveur Web, et non d'un répertoire local. Flex a le

<mx:Module/>

balise permettant de créer des modules pouvant être chargés discrètement lors de l'exécution.

Malheureusement, AIR est frustré par le manque de toute API de classe permettant de lancer d'autres applications. Vous pouvez charger une URL pour charger quelque chose dans le navigateur par défaut de l'utilisateur, mais vous ne pouvez pas lancer, par exemple, Excel. Java et C # ont tous deux des API permettant de lancer d’autres applications en tant que processus externes.