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

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

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

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

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

Но мне любопытно узнать, что произошло.

Если кто-либо из вас выполнил любую динамическую загрузку классов с помощью флеш-плеера (желательно в смешанных флеш-флеш-приложениях и ESPECIALLY внутри хоста AIR), мне бы хотелось услышать о ваших впечатлениях о создании вашей плагиновой структуры и о том, в сложные ситуации с флэш-плеером, а также с флеш-флемом и API-интерфейсом AIR.

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

ApplicationDomain больше похож на пространство имен, он группирует определения классов и помещает их в иерархию: домен может напрямую обращаться к символам в собственном домене или в родительском домене, но не в дочернем или sibling domains (или лучше: он не может сделать это напрямую - он должен проходить через объект applicationDomain, задавая определение данного класса); при загрузке внешнего swf вы можете решить, куда положить новые символы: дочерний домен (по умолчанию), новый домен, подключенный к системе (с использованием null), текущий домен, домен, прикрепленный где-то в другом месте (явно передающий родительский элемент новый домен). Обратите внимание, что новые символы никогда не будут перезаписывать символы в текущем домене, но одно и то же имя может существовать в нескольких доменах.
К сожалению, вы не можете перечислить классы в заданном домене (ну, по крайней мере, я не знаю, как это сделать), но общим решением является требование (как в "Интерфейсе плагина" ) наличия хорошо известного factory в каждом swf, который вернет либо определение (класс) плагина, либо сам плагин.
Вы просто получили ссылку на объект каким-то образом (factory), а затем это просто другой объект. Там нет сортировки: домен это просто логическое разбиение пространства имен (это ветвление дерева в системном домене).
Нет:) Но будьте осторожны: он может легко превратиться в ад для GC, где неиспользуемые домены не могут быть выгружены из-за распространения ссылок в другом домене. Я предлагаю взглянуть на многоядерную структуру PureMVC, возможно, с помощью труб для обеспечения строгого разделения между плагинами.

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

Ответ 3

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

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

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

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

<mx:Module/>

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

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

Ответ 4

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