Знакомство с MVCS фреймворком Robotlegs

Diestro — Sun, 14 Feb 2010 18:28:04 +0000

Впервые об этом фреймворке я услышал на BURAFPUG, прошедшем 6 февраля 2010 г. После некоторого изучения документации я пришел к выводу, что Robotlegs действительно очень интересный фреймворк.

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

Robotlegs это MVCS фремворк реализующий паттерн MVC с добавлением еще одного элемента – Services, использующегося для реализации взаимодействия с «внешним миром», будь то Web-сервисы, файловая система, базы данных, взаимодействие с другими Flash-приложениями через Local Connection и т.п.

Внедрение зависимостей (Dependency Injection)

Современные фреймворки, базирующиеся на паттерне MVC теми или иными способами поддерживают реализацию принципа Inversion of Control (Ioc) или Dependency Injections (DI). Robotlegs также основан на этом принципе.

Для чего нужно использование паттерна Dependency Injection? ООП приложение состоит из классов. Классы могут получать доступ к другим классам имея ссылки на них. Они взаимодействуют друг с другом, используя эти ссылки. Смысл Dependency Injection – уйти от высокой связанности приложения, заменив описание взаимодействия между конкретными классами на интерфейсы. Т.е. класс X будет использовать не класс Y а реализациею его интерфейса I. В результате мы получаем низко связанное приложение, классы которого знают только о интерфейсах для работы с другими классами. Например в приложении для работы с почтой мы будем работать с интерфейсом IMailLoader, вызывая метод load(), а не с конкретной реализацией класса IMAPMailLoader. В этом случае IMAPMailLoader будет легко заменить на POPMailLoader,реализующий интерфейс IMailLoader или на любой другой класс реализующий нужный интерфейс.

В Robotlegs DI реализован с помощью SwiftSuspenders. Это легковесный DI фреймворк для реализации этого паттерна посредством метатегов [Inject].

Работая с Robotlegs с классом наследуемом от Context (о нем я расскажу ниже) мы имеем доступ к переменной injector. Это экземпляр класса, реализующего функционал фреймворка SwiftSuspenders. injector – это менеджер внедряющий нужный экземпляр класса в классы нашего приложения.

Возвращаясь к примеру с почтовым сервисом реализация DI с помощью Robotlegs выглядит следующим образом:

1 2	//Когда запрашивают интерфейс IMailLoader вернуть экземпляр класса IMAPMailLoader injector.mapClass(IMailLoader, IMAPMailLoader);

Для того чтобы фреймворк внедрил то что мы описали выше, в нашем классе достаточно будет написать:

1 2	[Inject] public var mailLoader:IMailLoader;

В результате переменная mailLoader будет содержать экземпляр класса IMAPMailLoader.

Если же мы напишем:

1 2	injector.mapClass(IMailLoader, IMAPMailLoader, "IMAP"); injector.mapClass(IMailLoader, POPMailLoader, "POP");

В нашем классе мы можем задать name, для инстанцирования нужной нам реализации:

1 2	[Inject(name="POP")] public var mailLoader:IMailLoader;

В результате переменная mailLoader будет содержать экземпляр класса POPMailLoader.

Создавая карты с помощью injector можно также внедрять конкретные экземпляры классов (mapValue), классы «одиночки» (mapSingleton) и пр. Подробнее об этом написано в документации Robotlegs.

Немножко разобравшись с реализацией DI в Robotlegs перейдем к реализации MVCS архитектуры.

Контекст

Сердцем фреймворка Robotlegs является класс Context, от которого собственно и наследуется наш главный класс приложения. В этом классе задаются основные связи между компонентами приложения.

Карты команд

С помощью commandMap задается какую команду нужно вызывать при возниковении того или иного события.

1	commandMap.mapEvent(MyEvent.SOME_HAPPENED, MyCoolCommand, MyEvent);

Карты отображения

Так же как и PureMVC в Robotlegs для взаимодействия с view-компонентами используются посредники, называемые медиаторами. View-компоненты и их медиаторы сопоставляются с помощью mediatorMap.

1	mediatorMap.mapView(MyAwesomeWidget, MyAwesomeWidgetMediator);

Интересной особенностью медиаторов является их автоматическое инстанцирование только в случае добавления view-компонента, связанного с этим медиатором, в список отображения,что впрочем можно отключить во время задания правила для mediatorMap. Существует еще и viewMap, о котором в официальной документации не сказано ничего, но насколько я понял он используется для «внедрения» view-компонентов в классах приложения, т.е. является полным аналогом прямого использования injector.

Карты внедрения (иньекций)

Здесь описываем все классы или их экземпляры, которые необходимо «внедрять» в классы нашего приложения посредством использования метатега [Inject]. В частности здесь мы описываем наши классы с данными и сервисами необходимыми для реализации MVCS:

1 2	injector.mapSingleton( ApplicationModel ); injector.mapSingletonOf( IGalleryImageService, GalleryImageService );

Все классы описанные с помощью commandMap и mediatorMap автоматически подготавливаются фреймворком для «внедрения» в классы приложения.
Таким образом в нашем главном классе приложения перед запуском мы конфигурируем все необходимые компоненты и взаимодействия.

События

Для системы событий Robotlegs использует «родные» события Flash-плеера. Для их распространения внутри фреймворка используется следующий синтаксис:

1	dispatch(new ContextEvent(ContextEvent.STARTUP));

Чтобы слушать события используется следующий синтаксис:

1	eventMap.mapListener(dispatcher, ContextEvent.STARTUP, startupHandler);

Либо как уже было сказано выше во время конфигурации приложения можно указать на какое событие должна запускаться та или иная команда:

1	commandMap.mapEvent( ContextEvent.STARTUP, StartupCommand, ContextEvent);

Распространять и слушать события могут далеко не все фигуранты фреймворка. Кратко рассмотрим «Актёров» Robotlegs (MVCS).

Модель и сервисы (M и S)

Я позволю себе объединить описание этих двух составных частей фреймворка в одном месте, так как оба этих компонента должны наследоваться от класса Actor. Для фреймворка не имеет значение модель это или сервисы, это просто «Актер», наделить их функционалом должен уже разработчик.

Для того чтобы иметь доступ к модели или классу сервиса из других классов фреймворка достаточно будет написать [Inject] перед объявлением переменной. Например если класс с данными называется ApplicationModel, то в классе, где необходимо будет его использовать, достаточно написать:

1 2	[Inject] public var myModel:ApplicationModel;

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

Наследники класса Actor могут посылать события приложению используя метод dispatch.

Отображение (V)

Как правило каждый компонент отображения в Robotlegs состоит из двух элементов – cобственно компонента отображения и элемента, являющегося частью фреймворка – медиатора. Медиатор является посредником между компонентом отображения и фреймворком. Его основная задача информировать приложение о действиях пользователя и наоборот – изменять элементы отображения в соответствии с изменениями в приложении.

Медиатор должен наследоваться от класса Mediator. Элемент отображения связанный с медиатором доступен в переменной viewComponent. Медиатор имеет доступ к dispatch() и eventMap, а это значит что он может как распространять так и слушать события внутри приложения.

Для инициализации медиатора крайне не рекомендуется пользоваться конструктором. Для этого существует метод onRegister(), который необходимо переопределить и писать код инициализации в нем.

Для доступа к модели достаточно внедрить класс модели с помощью метатега [Inject] , так как это было описано выше.

Контроллер (С)

Функционал контроллера реализуется в Robotlegs посредством вызова команд. Класс команды должен наследоваться от класса Command. Команда создается только на время выполнения и после выполнения попадает в Garbage Collector. Команда появляется как результат возникновения события. Код, который должен выполнить команда должен быть помещен внутри переопределенного метода execute(). Сопоставления команд событиям происходит в commandMap Контекста приложения. Тот же самый commandMap доступен и внутри любой из комманд.

Доступ к модели организуется так же как и в классах отображения.

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

1 2	[Inject] public var event:MyCustomEvent;

Команда может также посылать события приложению используя метод dispatch.

Кратко резюмируя хотелось бы сказать что реализация Robotlegs действительно очень интересная и заслуживает внимания. В чем то она похожа на PureMVC, об этом же говорит и автор Robotlegs. Однако в Robotlegs иначе организована система событий, не нужно писать switch/case в обработчиках событий, как это реализовано в PureMVC. Достаточно подписаться на нужное событие и назначить метод обработчик, так как мы это привыкли делать со стандартными событиями Flash. По другому организовано и взаимодействие между компонентами приложения. В отличии от PureMVC в Robotlegs для доступа к другим компонентам приложения уже не используются retrieveProxy, retrieveMediator и т.п., а используется метатег [Inject].

Firebug для Flash

Diestro — Fri, 29 Jan 2010 17:16:38 +0000

Поковырявшись сегодня в аддонах для Firefox нашел пару полезных расширений для Firebug, позволяющих упростить жизнь Flash-разработчику.
Само собой для работы каждого из них необходим установленный Firebug.
Итак:

Flashbug
Данное расширение позволяет увидеть все “трейсы” на новой панели “Flash Console” плагина Firebug. Плагин имеет “Policy log”, позволяющий увидеть лог сообщений безопасности Flash-плеера. Для открытого в данный момент ресурса также можно увидеть сохраненные Shared objects. Flashbug так же дает возможность увидеть отсылаемые данные AMF в панели Net (Сеть):

AMF в Firebug

Для своей работы требует debug версии Flash-плеера.
На сайте автора можно подробнее почитать о расширении. Но почему то кажется что активность автора спала и доработку своего детища он отложил в долгий ящик. Будем надеяться на лучшее. Тем не менее это достойная замена FlashTracer’у, которым я пользовался до этого.

FireFlash
Посредством FireFlash Console API позволяет отображать объекты, массивы, XML и другие данные через Firebug console. Очень удобное и мощное средство для дебага и логинга. Позволяет группировать выдаваемые сообщения, есть механизмы запуска и остановки таймера для определения времени работы скрипта. На сайте автора расширения есть подробное описание API, примеры и видео помогающее понять как это работает.

Ложное срабатывание MOUSE_MOVE на Stage в MacOS

Diestro — Thu, 14 Jan 2010 06:26:57 +0000

Эх, где же та самая кроссплатформенность.

Разрабатываю свои проекты я под Windows, поэтому для отлавливания бага, проявляющегося только под MacOS пришлось заимствовать макбук.

Выяснилось что Flash-приложение открытое в любом из браузеров подвисает во время потери фокуса самим браузером (переключение на другое приложение). Причина зависания – в момент потери фокуса приложением, содержащим Flash-контент, на Stage флэшки приходит событие MOUSE_MOVE, содержащее какие-то немыслимые координаты курсора (x:-100500,y:-100500). Соответственно подвешенный на это событие обработчик, занимающийся отрисовкой шлейфа мыши, входил в безумно длинный цикл и Flash-приложение подвисало.

Еще раз повторюсь это происходит только под MacOS, под Windows “ложного” срабатывания MOUSE_MOVE не происходит.

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

Блог Diestro » ActionScript 3.0