flash - Crear una arquitectura de complemento con Adobe AIR

flex3 dynamic-loading

Question

Estoy pensando en elegir Adobe AIR como la tecnología de implementación del lado del cliente para un próximo proyecto. (La opción anterior era C # y WPF, pero últimamente he quedado muy impresionado con Flash / Flex / AIR).

Pero una de las características más importantes de mi producto será su arquitectura de complementos, lo que permite a los desarrolladores de terceros ampliar la funcionalidad y la GUI de maneras interesantes.

Sé cómo diseñaría la arquitectura en C #: un cargador enchufable enumeraría todos los ensamblajes en el directorio local "app / plugins /". Para cada ensamblaje, enumeraría todas las clases, buscando implementaciones de la interfaz "IPluginFactory". Para cada complemento creado por la fábrica, le pediría sus clases de MVC, y ajustar sus elementos de GUI (elementos de menú, paneles, etc.) en los espacios apropiados en el diseño de GUI existente.

Me gustaría lograr lo mismo dentro de AIR (cargar complementos desde el sistema de archivos local, no desde la web). Después de leer este artículo , entiendo que es posible y que la arquitectura básica (cargar SWF en Sandboxed ApplicationDomains, etc.) es muy similar a la forma en que lo harías en .NET.

Pero tengo curiosidad sobre las trampas.

Si alguno de ustedes ha realizado una carga de clases dinámica con el reproductor flash (preferiblemente en aplicaciones mixtas de flash / flex, y ESPECIALMENTE en el host AIR), me encantaría conocer sus experiencias en la creación de su marco de plugins y dónde se topó con situaciones complicadas con el flash player, y con las API flash, flex y AIR.

Por ejemplo, si alguien me hiciera esta misma pregunta, pero con la plataforma Java en mente, mencionaría definitivamente que la JVM no tiene noción de "módulos" o "ensamblajes". El nivel más alto de agregación es la "clase", por lo que puede ser difícil crear estructuras organizativas dentro de un sistema de complementos para gestionar grandes proyectos. También hablaría sobre problemas con múltiples cargadores de clases y cómo cada uno mantiene su propia instancia separada de una clase cargada (con sus propios vars estáticos separados).

Aquí hay algunas preguntas específicas aún sin respuesta para mí:

1) La clase actionscript "Loader" puede cargar un SWF en un ApplicationDomain. Pero, ¿qué contiene exactamente ese dominio de aplicación? Módulos? Clases? ¿Cómo se representan los componentes MXML? ¿Cómo encuentro todas las clases que implementan mi interfaz de complemento?

2) Si ha cargado un complemento en un ApplicationDomain separado de la aplicación principal, ¿es mucho más complicado llamar al código desde ese otro dominio de aplicación? ¿Existen limitaciones importantes sobre los tipos de datos que pueden pasar a través de la capa de clasificación inter-appdomain? ¿Es extremadamente costoso ordenar?

3) Idealmente, me gustaría desarrollar la mayoría de mi propio código principal como un complemento (con la aplicación principal siendo poco más que un shell de carga de complementos) y usar la arquitectura del complemento para elevar esa funcionalidad a la aplicación. ¿Eso te da miedo en tu corazón?

Answer 1

1. La aplicaciónDominio se parece más a un espacio de nombres, agrupa las definiciones de clase y las pone en una jerarquía: un dominio puede acceder directamente a los símbolos en su propio dominio o en el dominio principal, pero no en dominios secundarios o hermanos (o mejor: puede hacerlo). t hacerlo directamente: debe ir a través del objeto applicationDomain, pidiendo la definición de una clase dada); al cargar un swf externo, puede decidir dónde colocar los nuevos símbolos: un dominio secundario (predeterminado), un nuevo dominio conectado al sistema (usando null), el dominio actual , un dominio adjunto en otro lugar (pasando explícitamente el padre del nuevo dominio). Tenga en cuenta que los nuevos símbolos nunca sobrescribirán símbolos en el dominio actual, pero puede existir el mismo nombre en múltiples dominios.
   Desafortunadamente no se pueden enumerar las clases en un dominio dado (bueno, al menos no sé cómo hacerlo), pero la solución común es requerir (como en "The Plugin Interface") la presencia de un conocido fábrica en cada swf, que devolverá la definición (Clase) del plugin o el plugin en sí.
2. Solo tienes que obtener una referencia al objeto de alguna manera (la fábrica), entonces es solo otro objeto. No hay clasificación: el dominio es simplemente una partición lógica del espacio de nombres (es una ramificación de árbol del dominio del sistema).
3. No :) Pero tenga cuidado: puede convertirse fácilmente en un infierno para el GC, donde los dominios no utilizados no se pueden descargar debido a las referencias difundidas en otros dominios. Sugiero echar un vistazo al marco PureMVC multi-núcleo, posiblemente con tuberías para garantizar una separación estricta entre los complementos.

Por cierto, Flash Player también es un concepto de dominio de seguridad, pero en realidad nunca lo toqué, así que no sé cuáles son las posibilidades aquí.

Answer 2

Luca Tettamanti ya dio buenas respuestas a sus preguntas específicas, así que solo ofreceré información adicional sobre el tema general:

Implementé una API de complemento simple para una aplicación Flex utilizando la clase ModuleManager (y las demás cosas en el paquete mx.modules ). Lo esencial es que subclasifica los complementos de ModuleBase y utiliza ModuleManager en la aplicación de host para cargarlos . Luego, los complementos implementan una interfaz común (por ejemplo, IMyAppPlugin ) y utilizan algún tipo de fachada para representar e implementar la interfaz de la aplicación de host que los complementos pueden usar (p. MyAppFacade implements IMyAppFacade ., MyAppFacade implements IMyAppFacade ). Cuando se carguen complementos, inyecte esta fachada referencia en ellos.

El tema " Descripción general de las aplicaciones modulares" en la ayuda de Flex 3 tiene buena información (el subcapítulo "Dominios del módulo" trata sobre los dominios de la aplicación en el contexto de los módulos). Aquí hay un extracto:

"De forma predeterminada, un módulo se carga en un dominio secundario del dominio de aplicación actual. Puede especificar un dominio de aplicación diferente utilizando la propiedad applicationDomain de la clase ModuleLoader".

El tema "Uso de la clase ApplicationDomain" profundiza en el tema de los dominios de la aplicación, y definitivamente debería leerlo si aún no lo ha hecho.

Answer 3

¿Has intentado cargar sub-aplicaciones?
Hay una buena documentación para hacer esto en AIR y tuve éxito en unas pocas horas. Sin embargo, la misma implementación es una historia diferente en Flex debido a la violación de la zona de pruebas entre la sub-aplicación y la aplicación principal. He pasado semanas golpeando mi cabeza contra la pared.

Answer 4

Respondiendo a la declaración sobre Java como una posible arquitectura de complemento:

Resulta que Java se ha utilizado para diseñar sistemas de arquitectura de plug-in durante muchos años. En cuanto al lado del cliente, los marcos de gestión del módulo Equinox OSGi son probablemente los más conocidos. En un punto, el Eclipse IDE refactorizó su arquitectura de plug-in sobre Equinox OSGi. Eclipse IDE es quizás uno de los sistemas de arquitectura de complemento del lado del cliente más exitosos que se haya diseñado, desde el punto de vista de la longevidad histórica, así como la amplitud de la base de usuarios y la comunidad de continuación de desarrollo de complementos. También ofrecen su arquitectura de complemento como un marco fundamental para diseñar aplicaciones arbitrarias del lado del cliente: Eclipse RCP.

Solo tuve que intercalar esto porque, aunque Java se posicionó como una opción muy débil para esto, en realidad es mucho más exitoso que cualquier otro entorno de lenguaje / tiempo de ejecución hasta la fecha en la entrega de sistemas de este tipo, especialmente contra C # .NET, que, por supuesto, tiene una buena facilidad innata para los módulos. Es un poco irónico, pero ahí lo tienes.

En cuanto a Adobe AIR, soy desarrollador de un proyecto que se está diseñando en AIR. En nuestro caso, nuestra extensibilidad del módulo siempre se enviará desde el servidor web, no desde un directorio local. Flex tiene el

<mx:Module/>

etiqueta para crear módulos que pueden cargarse discretamente en el tiempo de ejecución.

Por desgracia, una frustración con AIR es su falta de API de clase para el lanzamiento de otras aplicaciones. Puede cargar una URL para cargar algo en el navegador predeterminado del usuario, pero no puede iniciar, por ejemplo, Excel. Tanto Java como C # tienen API para lanzar otras aplicaciones como procesos externos.