Создание архитектуры подключаемого модуля с помощью Adobe AIR

Question

Я подумываю выбрать Adobe AIR в качестве технологии реализации на стороне клиента для будущего проекта. (Предыдущий выбор был C # и WPF, но в последнее время я был впечатлен Flash / Flex / AIR.)

Но одной из наиболее важных функций моего продукта будет его архитектура плагинов, позволяющая сторонним разработчикам расширять функциональность и графический интерфейс интересными способами.

Я знаю, как бы я проектировал архитектуру в C #: загрузчик плагинов перечислял бы все сборки в локальном каталоге "app / plugins /". Для каждой сборки он будет перечислять все классы, ища реализации интерфейса «IPluginFactory». Для каждого плагина, созданного фабрикой, я запрашивал его классы MVC и привязывал его элементы GUI (элементы меню, панели и т. Д.) В соответствующие слоты в существующей компоновке GUI.

Я бы хотел сделать то же самое в AIR (загрузка плагинов из локальной файловой системы, а не из Интернета). После прочтения этой статьи я понял, что это возможно, и что базовая архитектура (загрузка SWF-файлов в изолированные домены приложений и т. Д.) Очень похожа на ту, которую вы делали бы в .NET.

Но мне любопытно узнать о гочах.

Если кто-нибудь из вас выполнил какую-либо динамическую загрузку классов с помощью Flash Player (желательно в смешанных приложениях flash / flex и ОСОБЕННО на хосте AIR), я хотел бы услышать о вашем опыте создания инфраструктуры плагинов и о том, где вы работали в сложные ситуации с Flash Player, а также с API Flash, Flex и AIR.

Например, если кто-то задает мне этот же вопрос, но с учетом платформы Java, я определенно упомяну, что в JVM нет понятия «модули» или «сборки». Наивысший уровень агрегации - «класс», поэтому может быть сложно создать организационные структуры в системе плагинов для управления крупными проектами. Я бы также поговорил о проблемах с несколькими загрузчиками классов и о том, как каждый из них поддерживает свой отдельный экземпляр загруженного класса (со своими собственными статическими переменными).

---

Вот несколько конкретных вопросов, которые до сих пор остаются для меня без ответа:

1) ActionScript-класс «Loader» может загружать SWF-файл в домен приложения. Но что именно содержит этот appdomain? Модули? Классы? Как представлены компоненты MXML? Как мне найти все классы, которые реализуют мой интерфейс плагина?

2) Если вы загрузили плагин в отдельный домен приложения от основного приложения, существенно ли сложнее вызывать код из этого другого домена приложения? Существуют ли какие-либо важные ограничения в отношении типов данных, которые могут проходить через уровень сортировки между приложениями? Маршаллинг непомерно дорог?

3) В идеале я хотел бы разработать большую часть своего собственного основного кода в качестве плагина (главное приложение - чуть больше, чем оболочка для загрузки плагина) и использовать архитектуру плагина для включения этой функциональности в приложение. , Это вселяет страх в ваше сердце?

Answer 1

1. ApplicationDomain больше похож на пространство имен, он группирует определения классов и помещает их в иерархию: домен может напрямую обращаться к символам в своем собственном домене или в родительском домене, но не в дочернем или родственные домены (или лучше: он не может сделать это напрямую - он должен пройти через объект applicationDomain, запрашивая определение данного класса); при загрузке внешнего SWF-файла вы можете решить , где поместить новые символы: дочерний домен (по умолчанию), новый домен, подключенный к системе (с использованием нулевого значения), текущий домен, домен присоединен где-то еще (явно передавая родителя нового домена). Обратите внимание, что новые символы никогда не будут перезаписывать символы в текущем домене, но одно и то же имя может существовать в нескольких доменах.
   К сожалению, вы не можете перечислить классы в данном домене (ну, по крайней мере, я не знаю, как это сделать), но общее решение состоит в том, чтобы (как в «Интерфейсе плагинов») требовать наличия хорошо известного factory в каждом SWF, который будет возвращать либо определение (Class) плагина, либо самого плагина.
2. Вам просто нужно как-то получить ссылку на объект (фабрику), тогда это просто еще один объект. Маршаллинга нет: домен - это просто логическое разбиение пространства имен (это ветвление дерева системного домена).
3. Нет :) Но имейте в виду: это может легко превратиться в ад для GC, где неиспользуемые домены не могут быть выгружены из-за распространения ссылок в другом домене. Я предлагаю взглянуть на многоядерную платформу PureMVC, возможно, с каналами для обеспечения строгого разделения между плагинами.

Кстати, Flash Player также представляет собой концепцию домена безопасности, но я на самом деле никогда не касался этого, поэтому я не знаю, какие здесь есть возможности.

Answer 2

Лука Теттаманти уже дал хорошие ответы на ваши конкретные вопросы, поэтому я просто предложу некоторую дополнительную информацию по общей теме:

Я реализовал простой API плагинов для приложения Flex с использованием класса ModuleManager (и других элементов в пакете mx.modules). Суть этого является то, что вы подклассы плагины из ModuleBase и использовать ModuleManager в хост-приложении, чтобы загрузить их. Затем у вас есть плагины, реализующие общий интерфейс (например, IMyAppPlugin), и вы используете фасад для представления и реализации интерфейса с хост-приложением, которое могут использовать плагины (например, MyAppFacade implements IMyAppFacade.) Всякий раз, когда плагины загружаются, вставьте в них эту ссылку на фасад.

В теме «Обзор модульных приложений» в справке Flex 3 содержится полезная информация (в подразделе «Домены модулей» обсуждаются домены приложений в контексте модулей.) выдержка:

"По умолчанию модуль загружается в дочерний домен текущего домен приложения. Вы можете указать другой домен приложения с помощью свойство applicationDomain объекта ModuleLoader class. "

В теме «Использование класса ApplicationDomain» более подробно рассматривается тема доменов приложений, и вам обязательно следует прочитать ее, если вы еще этого не сделали.

Answer 3

Вы пробовали загружать суб-приложения?
В AIR есть хорошая документация для этого, и я справился с этим за несколько часов. Тем не менее, та же реализация является другой историей во Flex из-за нарушения изолированной программной среды между субприложением и основным приложением. Я провел недели, стуча головой в стену.

Answer 4

Ответ на утверждение относительно Java как возможной архитектуры подключаемого модуля:

Оказывается, Java использовалась для разработки систем с архитектурой плагинов в течение многих лет. Что касается клиентской части, структуры управления модулями Equinox OSGi, вероятно, являются наиболее известными. В какой-то момент Eclipse IDE реорганизовал свою архитектуру плагинов поверх Equinox OSGi. Eclipse IDE является, пожалуй, одной из самых успешных систем на основе плагинов на стороне клиента, которая еще не разработана - с точки зрения исторического долголетия, а также широты пользовательской базы и последующего сообщества разработчиков плагинов. Они также предлагают свою архитектуру плагинов в качестве основы для разработки произвольных клиентских приложений - Eclipse RCP.

Мне просто пришлось вставить это, потому что, хотя Java и позиционировался как, возможно, очень слабый выбор для этого, на самом деле он намного более успешен, чем любая другая языковая / исполняющая среда, на сегодняшний день в предоставлении рабочих систем такого типа - особенно по сравнению с C # .NET, которая, конечно, имеет хорошие врожденные возможности для модулей. Отчасти иронично, но у вас это есть.

Что касается Adobe AIR, я занимаюсь разработкой проекта, который разрабатывается для AIR. В нашем случае расширяемость нашего модуля всегда будет доставляться с веб-сервера, а не из локального каталога. Flex имеет

<mx:Module/>

тег для создания модулей, которые можно загружать дискретно во время выполнения.

Увы, разочарованием в AIR является отсутствие каких-либо API классов для запуска других приложений. Вы можете загрузить URL-адрес для загрузки чего-либо в браузере пользователя по умолчанию, но вы не можете запустить, скажем, Excel. И Java, и C # имеют API для запуска других приложений в качестве внешних процессов.