Creación de una arquitectura de complemento con Adobe AIR

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 me 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, permitiendo 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 de plug-in 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 correspondientes 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 this article, 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ía en .NET.

Pero tengo curiosidad acerca de los problemas.

Si alguno de ustedes ha realizado una carga de clase 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 al construir su marco de plugin y dónde tropezó con situaciones difíciles con el reproductor de flash y con las API de 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).

---

Estas son algunas preguntas específicas sin respuesta para mí:

1) La clase de ActionScript "Cargador" puede cargar un archivo SWF en una 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 al aplicación ¿Eso te da miedo en tu corazón?

Answer 1

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

he implementado un simple API de plugins para una aplicación Flex utilizando la clase ModuleManager (y las otras cosas en el paquete mx.modules). La esencia de esto es que usted subclase los complementos desde ModuleBase y use ModuleManager en la aplicación host para cargarlos. Luego tiene los complementos para implementar una interfaz común (p. Ej. IMyAppPlugin) y usar algún tipo de facade para representar e implementar la interfaz de la aplicación de host que los complementos pueden usar (por ejemplo, MyAppFacade implements IMyAppFacade). Cuando se carguen plugins, inserte esta referencia de fachada en ellos.

El tema "Modular applications overview" en el Flex 3 ayuda tiene buena información He aquí un extracto (el subcapítulo "dominios del módulo" discute dominios de aplicación en el contexto de los módulos.):

"De manera predeterminada, se carga un módulo 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 "Using the ApplicationDomain class" entra en más profundidad sobre el tema de los dominios de aplicación, y sin duda debe leerlo si no lo ha hecho.

Answer 2

1. El applicationDomain se parece más a un espacio de nombres, TI definiciones de clases de grupos y los puso 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 hijo o hermano dominios (o mejor: no puede hacer eso directamente; debe ir a través del objeto applicationDomain, pidiendo la definición de una clase dada); al cargar un swf externo, puede decidir donde poner los nuevos símbolos: un dominio secundario (predeterminado), un nuevo dominio conectado al sistema (usando nulo), el dominio actual, un dominio adjunto en otro lugar (que pasa explícitamente) el padre del nuevo dominio). Tenga en cuenta que los nuevos símbolos nunca sobrescribirán los símbolos en el dominio actual, pero puede existir el mismo nombre en múltiples dominios.
   Desafortunadamente no puede enumerar las clases en un dominio dado (bueno, al menos no conozco ninguna forma de hacerlo), pero la solución común es requerir (como en "The Plugin Interface") la presencia de un pozo - fábrica conocida 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 (de 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 extendidas en otro dominio. Sugiero echar un vistazo a la estructura PureMVC multi-núcleo, posiblemente con tuberías para garantizar una separación estricta entre los complementos.

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

Answer 3

En respuesta a la declaración con respecto a Java como una posible arquitectura de plug-in:

Resulta de Java se ha utilizado para diseñar plug-in de sistemas de arquitectura 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 plug-in más exitosos del lado del cliente, diseñado desde el punto de vista de la longevidad histórica y la amplitud de la base de usuarios y la comunidad de continuación del 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.

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 en la entrega de sistemas de trabajo 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 la etiqueta

<mx:Module/>

para la creación de módulos que se pueden cargar de forma discreta en tiempo de ejecución.

Desafortunadamente, 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.

Answer 4

¿Ha intentado cargar sub-aplicaciones?
Hay una buena documentación para hacer esto en AIR y tuve éxito con esto 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.