воскресенье, ноября 07, 2010

Надоел логгер FD

Надоело постоянно висящее окно FlashDevelop, который я пользую только для просмотра лога Flash Player.
Хочется просто обычный логгер - легкий и под всегда рукой.
Смотрим, что есть по этой теме в гугле.

Первое, на что я западаю - ThunderBolt AS3. AIR-приложение, которое заточено как раз под нашу задачу. Качаем, ставим, смотрим.
Продвинутый интерфейс, лог фильтруется по разным категориям.
Местоположение лог-файла предлагается указать драг-дропом самого файла flashlog.txt прямо в приложение.
Всё вроде бы замечательно. Но. Как только я запустил Громовой Шуруп, логгер FlashDewelop работать отказался. По-видимому, он держит файл лога занятым, не давая другим его открывать. Да и сам болтяра показывает лог как-то не стабильно, вызывая к себе недоверие.
В общем - всё не супер.

Дальнейшие поиски приложений - логгеров ни к чему хорошему меня не привели.

Я работаю в основном на Flex Builder под Eclipse. Как хорошо было бы иметь под рукой логгер в виде плагина под эту чудесную платформу!
И, несомненно, таковой тут же нашелся: плагин для Eclipse: LogWatcher as a cross-platform Flash debugger in Eclipse.
Качаем, ставим согласно инструкции, смотрим.
Теперь рядом с закладочкой Console, у меня всегда перед глазами закладочка LogWatcher, где в реальном времени выводится содержимое лога.
Здесь можно подключиться и к другим логам, например, policyfiles.txt, что тоже может пригодиться.

В общем, получили окошко, аналогичное FD Logs, но под Eclipse, что очень радует.

Но поиски хорошего специализированного логгера еще не окончены.

вторник, марта 23, 2010

Как получить заголовки ответа сервера

Сегодня столкнулся с проблемкой. Приложение посылает запрос на сервер, и сервер отвечает только заголовками (header), в моем случае - Location http://.....
Как мне получить данные, содержащиеся в заголовке? Функции AS3 такой возможности не предоставляют. То есть - при обычной загрузке, с использованием URLLoader/HTTPService мы получаем содержимое ресурса, указанного в Location.

Однако, после непродолжительных поисков, я наткнулся на статью HTTP Authentication for HTTP/GET requests using ActionScript 3, в которой автор представляет свою библиотечку HTTPURLLoader, которая при помощи сокетов осуществляет загрузку и заголовков и данных ответа сервера.
Спасибо ему за это и низкий поклон.

вторник, марта 16, 2010

Растровый редактор

Сегодня мне понадобился редактор растрового изображения.
Поиск готовых решений не дал большого изобилия результатов. Да и не надо. Всего одна библиотека, которая попалась в наши сети превосходно решает нашу задачу:
  • The Graffiti AS3 Bitmap Drawing Library - отличный движок с открытым исходным кодом и примерами. Есть две версии - более старая 1.1 (для FP9+) и новая 2.5 (для FP10+). На странице проекта есть таблица сравнения возможностей версий.
    Я выбираю версию 1.1, поскольку мой проект для FP9. Кстати, примеры на сайте представлены для более свежей версии, но принцип использования аналогичный, поэтому первый пример легко интуитивно подстроить под свои нужды.
Параллельно напал на интересные ресурсы:
  • µSprite AS3 Vector Editor - графический AIR-редактор с богатыми функциями, способный преобразовать нарисованное в код AS3/Haxe.
  • Pixlr photo editor - онлайновый графический редактор.
  • BitmapDataUnlimited - растр без ограничения геометрического размера.

воскресенье, марта 14, 2010

Графические трансформеры

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

Посмотрим, чем сегодня пользуются наши братья для трансформирования визуальных объектов.
  • Первым попадается нам вот такой пример: AS3 Transform Tool for scaling, rotating components containing text controls in Flex. Всё весьма красиво, но без исходников. Зато, идет прямая наводка на прародителя этой демки, о котором и поговорим позже.
  • Замечательная старая демка, от Senocular. Есть и исходный код. Удивительно, что такая старинная разработка дает начало целому семейству трансформеров.
    Скачиваем, запускаем. Пример под CS3 AS3 FP9. Всё работает прекрасно, поигрался с настройками трансформера - превосходно.
    Есть возможность таскать, масштабировать, наклонять, поворачивать, менять положение центра трансформаций. Всё удобно и отлажено.
    Однако, просматривая отзывы к постам относительно этого движка, многие пишут что недовольны тем, что он не подходит для использования во Flex-приложении.
  • И вот, Senocular TransformTool модифицируют под Flex2: senocular.com TransformTool modification. Так же прикладываются исходники.
    В отличии от предыдущего примера, здесь трансформируются не Sprite-объекты, а UIComponent-объекты, то есть flex-компоненты.
    Создаем Flex-проект, копируем в него исходники, запускаем. Работает. Картинки модифицируются прекрасно, а вот компоненты, содержащие текст (например обычная кнопка) трансформируются не очень то корректно. Может быть это по причине того, что необходимо внедрить шрифт, а может быть нужно что-то доработать (ведь первый наш пример работает вполне себе нормально).
  • Продолжение работ над совершенствованием движка: Multiple objects using Senocular TransformTool. Так же имеется исходный код. Однако, он уже написан под Flex SDK 4, поэтому я не стал продолжать его изучение.
  • Еще один мощный движок для трансформаций под Flex: Object Handlers. Здесь множество ссылок относительно проекта - и документация ASDoc, и обучающее видео, и проект на Google Code.
    Попробовал скачать 2ю версию движка, поставил и сразу получил множество ошибок. Во-первых, половина примеров просит Degrafa, во вторых лезут еще две ошибки, которые поправить интуитивно не получается.
    Поэтому задвигаю 2ю версию и качаю последний релиз 1й версии. Здесь всё стабильно, всё работает без проблем. За исключением косяка вращения. Почему-то в примере, в разделе Rotating трансформер не имеет вращающей точки. Это легко исправляется добавлением соответствующего параметра, однако, появление активной точки для поворота сильно не обрадовало, а точнее - ее неуместное размещение рядом с правой точкой горизонтального растягивания.
    Зато всё остальное в этом проекте обещает очень многое, особенно - работа с Degrafa.
  • Еще одна интересная разработка: Distort Image Transform Tool. Здесь изображение можно произвольно трансформировать таская его за углы. Кстати, еще и под Flash 8.
  • Упомяну так же и коммерческую версию трансформера: TransformManager. Выглядит вполне себе замечательно, не сильно лучше предыдущих претендентов, но, зато более причесано. И, что впечатляет - есть возможность объединять для трансформации сразу несколько объектов.
Итак, для своей задачи, я уже выбрал себе движок от Senocular, поскольку мне нет необходимости трансформировать flex-компоненты - я буду работать исключительно с графикой. Поэтому, область графических трансформаций лучше убрать в чистый AS3-модуль и уже его вставлять во Flex в виде компонента, получающего извне данные и команды, и отдающего результирующий графический образ в виде BitmapData или контейнера с набором данных о графических объектах и их трансформациях.

четверг, марта 11, 2010

Выбираем листалку страниц для Flex-проекта

С тех пор, как впервые мы увидели этот культовый гаджет PageFlip, созданный еще для 6й версии (а может и еще ранней) FP, немало воды утекло. Кстати, здесь есть ссылка на исходник на одну из старых версий.

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

Итак, начинаем поиски.
  • Многие ссылки ведут сюда: http://www.quietlyscheming.com/blog/components/flexbook/.
    Движок FlexBook явно не нов - март 2007, хотя последний коммент в блоге датируется 2009м годом.
    Демка показывает возможности движка, а в контекстном меню flash есть ссылка на архив с исходным кодом.
    Исходный код поставляется в виде Flex-проекта, однако при импорте, FlexBuilder предупреждает о том, что версия SDK в проекте указана старая, а так же о том, что есть устаревшие свойства flex-компонентов. Кроме того, в настройках есть ссылка на не существующую библиотеку, но это лечится путем удаления некорректной строки из свойств проекта.
    Код компилируется и работает превосходно.
  • Следующий претендент: http://www.rubenswieringa.com/blog/flex-book-component-beta.
    Называется так же - FlexBook. И так же не свеж - июль 2007, зато комменты датируются мартом 2010, то есть актуальность на лицо.
    Демка так же вполне адекватная и в контекстном меню тоже есть ссылка на исходный код.
    Создаем новый Flex-проект, копируем туда код, указываем что компилить и запускаем. Никаких проблем, получаем работающую книгу. Выглядит привлекательнее предыдущего решения.
  • Коммерческая разработка: FlashPageFlip. Есть бесплатная версия - Free FlashPageFlip. Скачиваем бесплатную версию.
    Бесплатная версия не предоставляет исходников. Зато здесь есть всё, чтобы сделать книгу из заготовок. Рассчитан на 8ю версию FP.
  • Расширение Flash CS - PageTurn3D CS: здесь. Не стал ставить, хотя демка выглядит симпатично.
  • OpenSource движок MegaZine3: http://megazine.mightypirates.de/. Судя по описаниям, и демке, достаточно мощный движок. Есть доступ к SVN, есть довольно обширный API.
    Общее впечатление от демки (которую можно только скачать как Zip) безусловно очень положительное. Сам по себе скачиваемый продукт не является библиотекой. Это готовое решение, глубоко конфигурируемое, способное отображать разнообразный контент пользователя.
    Предлагается скачать SWC, но ссылка некорректная. Исходники можно скачать с SVN. Имеется форум с достаточно оживленными обсуждениями.
    В общем, при желании, можно разобраться с этой системой, хотя она, как большинство openSource-проектов, выглядит как темный лес. К тому же не предоставляется примеров использования API. Но это уже тема для отдельной статьи.
Наткнулся на пост, в котором есть небольшой обзор листалок. Ничего особенного, зато дает общее представление о коммерческих продуктах.

Итак, моя задача состоит в интеграции листалки во Flex-проект. Соответственно есть два пути:
  1. Непосредственно использовать библиотеку классов
  2. Интегрировать готовое решение путем внедрения главного SWF-файла во Flex-приложение и каким-то косвенным путем управлять контентом страниц.
Я рассматриваю первый вариант и выбираю движок FlexBook от Ruben Swieringa. Всё. Буду докладывать с места событий.

суббота, января 30, 2010

Что нам дает API ВКонтакте

Соцсети уже прочно вошли в наш быт и собрали миллионы пользователей. И нашему брату флэшеру открылись новые области для творчества. В частности - Flash-приложения сетевого проекта ВКонтакте, для которых создан специальный API, позволяющий легко интегрировать приложение в систему ВКонтакте.
Итак, что же нам предлагает API ВКонтакте - давайте разберемся.

Обзор
Как обычно, для начала почитаем, что об этом пишут наши коллеги.
Однако, никаких вразумительных статей, кроме материалов в рамках самого "ВКонтакте" найти не смог. Если кто-нибудь видел таковые - пожалуйста, киньте ссылочку в комменты. Итак:
  • Первый ресурс, важный для разработчика, это, собственно раздел "Разработчикам" на самом ВКонтакте.
    Здесь нам обещают миллионы долларов, основные ссылки по теме и небольшое описание, из которого мы уже можем почерпнуть, что:
    - Приложение может иметь границы до 827х4050.
    - Приложение может иметь доступ к пользовательскому левому меню, счетчикам, обычным и SMS-уведомлениям, профилю, фотографиям, друзьям, рейтингу, аудиозаписям пользователей – и многому другому.
    - Работа по совершенствованию API ведется непрерывно.
  • Клуб Flash API
  • API ВКонтакте на flasher.ru: API приложений и сред
Возможности API ВКонтакте
Попробуем выявить возможности приложений ВКонтакте, проанализировав функции API.

Работа с пользовательскими данными
Приложение имеет доступ к следующим данным:
  • Установил ли пользователь, который просматривает приложение себе на страницу данное приложение
  • Данные по любому пользователю, на основании его ID:
    - имя,
    - фамилия,
    - псевдоним,
    - пол,
    - дата рождения,
    - город,
    - страна,
    - часовой пояс,
    - url-адреса фото малого, среднего и большого размеров,
    - известен ли его мобильный телефон,
    - рейтинг
  • Баланс пользователя на счету приложения
  • Доступ к данным пользователя, просматривающего приложение:
    - разрешить отправлять ему уведомления,
    - доступ к друзьям,
    - доступ к фотографиям,
    - доступ к аудиозаписям,
    - доступ к предложениям,
    - доступ к вопросам,
    - доступ к wiki-страницам,
    - доступ к меню слева,
    - публикация на стенах пользователей.
  • Список групп, в которых состоит пользователь с общей информацией о каждой группе.
У каждого пользователя ВКонтакте есть друзья - другие пользователи ВКонтакте. Доступные данные друзей пользователя:
  • Список друзей текущего пользователя.
  • Список друзей текущего пользователя, которые уже установили данное приложение.
Приложение может так же осуществлять следующие действия:
  • Поднять рейтинг пользователя от имени приложения
  • Если пользователь установил приложение в меню слева, приложение может задать краткое имя приложения, а так же вывести счетчик рядом с названием приложения - например, счетчик уведомлений.
  • Устанавливать и считывать строку статуса приложения.
Работа с фотографиями пользователя
Пользователь ВКонтакте может создавать множество альбомов с фотографиями в разделе "Мои Фотографии". API предоставляет широкий выбор возможностей по работе с альбомами и фотографиями.
Фотографии должны иметь формат JPG, PNG или GIF.
Приложение может получить:
  • Список фото-альбомов с общими данными о каждом альбоме.
  • Список фотографий из какого-либо альбома (или непосредственно по ID фотографии) с набором ссылок на изображения различных размеров и качества.
Приложение может осуществлять следующие действия с альбомами и фотографиями:
  • Создавать альбом (с описанием и контролем доступа к нему).
  • Редактировать данные существующего альбома.
  • Изменять порядок в списке альбомов.
  • Изменять порядок фотографий в альбоме.
  • Переносить фотографии из альбома в альбом.
  • Делать фотографию обложкой альбома.
  • Загружать фотографии на сервер ВКонтакте, на стену пользователя, на страницу пользователя.
Работа с аудиозаписями пользователя
Пользователь может загружать аудиозаписи и прослушивать их в разделе "Мои Аудиозаписи".
Аудиозапись должна быть в формате MP3, не превышать 10Мб и не нарушать авторских прав.
API предоставляет широкий выбор возможностей для работы с аудиозаписями:
  • Получать список аудиозаписей пользователя или группы с общей и подробной информацией о каждой записи.
  • Получать текст песен аудиозаписей.
  • Осуществлять поиск по аудиозаписям.
  • Загружать, удалять, восстанавливать удаленные аудиозаписи.
  • Редактировать данные аудиозаписи.
  • Добавлять аудиозапись на страницу пользователя или группы.
  • Менять порядок следования аудиозаписей.
Работа с видеозаписями пользователя
API позволяет получать список видеозаписей пользователей, групп с общей информацией о каждой видеозаписи.

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

Голоса ВКонтакте
Собственная валюта проекта ВКонтакте - голоса. Каждый пользователь, а так же приложение имеет свой платежный баланс, на котором может находиться какое-то количество голосов.
API предоставляет приложению доступ к следующим функциям:
  • Получить платежный баланс (количество голосов) приложения.
  • Получить платежный баланс (количество голосов) пользователя.
  • Перевести голоса со счета приложения на счет пользователя.
  • Перевести голоса со счета пользователя на счет приложения.
  • Перевести голоса со счета пользователя на счет другого пользователя в рамках приложения.
  • Просмотр историй транзакций по переводу голосов между пользователями и приложением
Работа с SMS
Приложение ВКонтакте может задействовать столь мощные сервисы, как отправка и прием SMS:
  • Отправка SMS-уведомления. При этом со счета приложения списывается 0.1 голоса.
  • Просмотр списка SMS-сообщений, полученных от пользователей приложением.
  • Просмотр истории SMS-уведомлений, посланных приложением.
Отправка SMS-сообщения бесплатна (стоимость обычного SMS-сообщения). Отправка осуществляется на телефон +7 921 000 00 07, а чтобы приложение получило свое сообщение, API предоставляет возможность установить приложению префикс, который пользователь должен указать в начале своего SMS-сообщения.

Работа с сервисом "Предложения"
С помощью сервиса "Предложения", пользователь получает возможность создать свое уникальное предложение. Это предложение смогут увидеть все пользователи ВКонтакте -этот сервис независим от личной странички. Любое предложение начинается со слов "Хотели бы Вы", далее следует сам текст, а в конце уже стоит вопросительный знак. Пользователи могут посматривать предложения других пользователей, принимать чужое предложение нажатием варианта «Да, конечно» или отказываться нажатием варианта «Нет».
Итак, функции для работы с предложениями:
  • Редактировать, открыть для общего доступа, и закрыть предложение пользователя, просматривающего приложение.
  • Просматривать, искать предложения пользователей.
  • Принимать и отклонять предложения пользователей.
  • Просматривать ответы на предложение пользователя.
  • Получать список ответов на предложения, принятые пользователем.
  • Удаление и пометка о прочтении ответов пользователей.
Работа с сервисом "Вопросы"
Аналогичный предыдущему сервис, позволяющий задавать вопросы и получать на них ответы от других пользователей. В API так же есть всё необходимое для управление этим сервисом из приложений.

Работа с Wiki-страницами
Пользователям предоставляется система редактирования страниц, которая позволяет участникам групп совместно создавать бесконечное количество страниц с перекрестными ссылками. Таким образом, пользователи могут создавать в группах библиотеки или мини-энциклопедии. Кроме того, пользователи могут использовать особую wiki-разметку для оформления страниц.
Приложения имеют возможность работать с Wiki-страницами:
  • Получать текст и полную информацию о wiki-странице.
  • Редактировать и сохранять текст и настройки wiki-страницы.
  • Получать список wiki-страниц в группе.
  • Транслировать wiki-разметку в html-разметку.
Организация чата
API позволяет создавать в приложении чат, используя очередь сообщений - 127 сообщений. Для этого предусмотрены функции добавления сообщения в очередь и просмотра всей очереди сообщений.

Сохранение игровых рекордов
API предусматривает специальные функции для сохранения результатов игры пользователя и получения списка результатов.

Показ рекламы
API предоставляет возможность показывать в приложениях рекламу:
  • Показ таргетированной рекламы. (Пользователи могут создавать рекламные сообщения, которые показываются на страницах ВКонтакте. Приложение, показывающее рекламу зарабатывает голоса).
  • Показ прямых объявлений приложений. (Разработчики могут рекламировать свои приложения в других приложениях. При этом голоса так же начисляются на баланс приложения).
Работа с переменными
Для хранения данных, API предоставляет каждому приложению 4096 уникальных переменных по 255 байт.
Причем, переменные распределяются по следующим диапазонам:
  • Глобальные переменные: могут использоваться для данных, которые общие для всех экземпляров данного приложения, например, это таблица рекордов игрового приложения.
  • Переменные пользователя: эти переменные уникальны для каждого пользователя данного приложения и могут служить, к примеру, для сохранения игры пользователя.
    Примерно к половине переменных предоставляется доступ другим пользователям. Часть переменных является зарезервированной для разных нужд.
  • Переменные сессии: при работе с переменными, в запросе можно задавать идентификатор сессии (сеанса или комнаты). Таким образом, переменные этого диапазона будут общими для всех пользователей, которые в данный момент просматривают приложение. Соответственно, приложения могут осуществлять многопользовательское общение в реальном времени - чаты, многопользовательские игры и прочее.
  • Переменные, содержащие временные данные, которые уникальны для текущего просматриваемого приложения, и при его закрытии пропадут.
Однако, количество переменных не велико - всего по 1024 переменные на диапазон, и это без учета зарезервированных переменных.

Работа с удаленным сервером разработчика
Приложение ВКонтакте является обычным Flash-приложением и обладает одним большим недостатком. Его нельзя считать защищенным от взлома. Точнее говоря, затраты на взлом flash-приложения не столь велики как, к примеру взлом сервера. Существует достаточное количество программ SWF-декомпиляторов, при помощи которых можно легко получить исходный программный код, выяснить логику приложения и подтасовать запросы к API.
Поэтому, некоторые функции, которые были перечислены выше, работают только с удаленного сервера разработчика, минуя flash-приложение, а именно:
  • Работа с рейтингом пользователя
  • Вывод короткого статуса пользователя в приложении на его главной странице
  • Отправка уведомлений пользователя (только пользователям, которые установили себе данное приложение)
  • Работа с голосами (платежные операции)
  • Установка счетчика на приложение и работа с строкой статуса приложения
  • Отправка и просмотр SMS-уведомлений
Таким образом, чтобы иметь возможность осуществлять эти операции, приложение должно не напрямую обращаться к API, а запрашивать свой специально предусмотренный сервер-прослойку, который в свою очередь будет общаться с API ВКонтакте и выдавать приложению полученные данные.
А вообще, конечно, для крупных проектов, работающих в формате приложений ВКонтакте, безусловно, именно этот специальный сервер и должен являться "мозгом", отрабатывающим всю логику приложения. Flash-приложение в этом случае всего лишь "тонкий клиент", который лишь красиво отображает результат работы сервера.

Локализация приложений
Разработчики приложений имеют возможность переводить свои приложения на более чем 50 языков, используя платформу переводов ВКонтакте. В данный момент платформа на этапе тестирования и применима только для приложений с большим количеством пользователей.

Использование Flash-контейнера приложения
Альтернативный способ внедрения flash-приложения в страницу ВКонтакте - через Flash-контейнер.
Flash-контейнер предоставляет следующие возможности для приложения:
  • Открытие окон установки приложения, настроек, приглашения друзей и ввода голосов для оплаты услуг.
  • Получение событий об успешной установке приложения пользователем, изменении настроек и баланса пользователя внутри приложения.
  • Динамическое изменение размера окна приложения.
Другие возможности
  • Открытие приложения на весь экран.
  • Субдомены vkontakte.ru и короткие имена в url приложения.
Особенности API ВКонтакте
Итак, мы ознакомились со всеми возможностями, которые предоставляет API ВКонтакте. Хочется выделить особенности (скорее недостатки) API, с которыми мне пришлось столкнуться:
  • Взаимодействие с API происходит путем HTTP-запроса к php-скрипту. При этом, частота запросов не должна превышать 3х запросов в секунду. Такой механизм накладывает серьезное ограничение на динамику приложений, особенно многопользовательских.
    Проблема частично решается использованием новой функции API "execute", которая позволяет выполнять последовательность функций за один запрос к API.
  • Объемы сохраняемых данных приложения довольно скромны.
Стоит так же упомянуть о статье "Партнерская модель между ВКонтакте и разработчиками приложений", в которой есть много чего интересного для разработчика приложения:
  • Информация о том как можно заработать и как потратить голоса.
  • О том, что при обнале голосов ВКонтакте забирает половину средств на свои благородные цели.
  • А так же об аренде серверов в дата-центре ВКонтакте (на самом деле у партнеров).

Итог
Flash-приложения ВКонтакте обладают достаточно мощным API, который решает основные задачи, и может полностью обеспечить проекты средней сложности. Все остальные потребности, разработчик может решить, используя свой веб-сервер.

Разработка таких приложений всё более актуализируется, поскольку помимо возможности заработать на монетизации за счет показов рекламы, приложения ВКонтакте сами по себе могут являться мощнейшим инструментом вирусной рекламы.

среда, января 06, 2010

Знакомство с Mate

Вступление.

Этот пост начал свое существование 7 месяцев назад. Именно тогда я решил взять на вооружение Mate Flex Framework. Но злостный непрекращающийся дидлайн никак не давал мне закончить статью. Год выдался трудным и на работе и дома (в конце ноября у нас родился 3й ребятёнок). Сейчас, на праздниках (Всех с Новым Годом и Рождеством!) появилась свободная минутка, чтобы оглянуться назад.

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

Забегая вперед, хочу с удовольствием отметить, что освоение прошло успешно и пол-десятка проектов были запущены на каркасе Mate.

Теоретическое знакомство с Mate

Наконец-то у меня появилось время копнуть Mate.
И начну я с того, чтобы удостовериться в правильности выбора.

  • Мне, как Flex-разработчику, Mate в первую очередь интересен тем, что это фреймворк, базирующийся на Flex.
  • Очень хочется меньше кодить, но иметь при этом наглядный и прозрачный код.
  • Понятная документация, обучение и примеры. Теперь посмотрим, какие фреймворки сравнивают и что о них думают:
    - Здесь - presentation сравниваются Cairngorm, Mate и PureMVC. Забавно, что количество доводов "против" для Mate меньше чем для остальных.
    - Довольно объемная статья: FrameworkQuest 2008, а точнее, заключительная часть исследования фреймворков. Почти во всех качествах, Mate выигрывает.
  • Последним аргументом будет личный опыт. Приступим к тестовому проекту.

Для начала посмотрим видео: Mate Helloworld. Впечатления позитивные. Всё довольно очевидно и изящно. Здесь рассказывают про Mate на примере работы с простейшим сервисом при использовании AMFPHP. Мне это дело так понравилось, что я решил немедленно себе поставить эту штуку - но об этом позже.

А пока - продолжаем изучать Mate. Читаем про Mate на Go!Verla Flex Blog:

Теперь, когда достаточно изучен хороший пример, почитаем документацию, и особенно, раздел Tags.

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


Неудачно перехожу от теории к практике

Пока изучал Mate, решил испробовать на реальном проекте (проект небольшой многослойной карты с маркерами и с подгрузкой данных). Подготовил все компоненты к виду Model/View и... всё получилось само собой, но только без Mate. На байндинге и событиях. Делаем вывод - Mate не для простых проектов. Точнее, не имеет смысла его использовать в простых проектах. Хотя, в примерах числятся очень простые приложения типа "Weather Widget".

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

Кстати, хочу отметить, что мое решение ничуть не проиграло бы Mate-решению. Чисто-Flex-разработка обладает богатым набором возможностей, и вовсе не обязательно всем сломя голову пересаживаться на Mate. Но попробовать, точно, стоит.


Создаю проект Mate

Но меня просто переполняет желание освоить этот фреймворк. Попробую начать с нуля.
Для начала, создаю проект (обычный). В папку libs скачиваю свежий SWC.

Теперь хорошо бы создать структуру пакетов (проще говоря, папок) проекта. После обзора примеров, выявляется устоявшаяся структура:

Основной пакет проекта помещается в папку:
src/[org, com, ru, ....]/[name, company-name, nick-name, ...]/[project name]

В проекте содержатся следующие пакеты:

  • business. Классы, которые определяют модель поведения приложения. Это классы, которые как правило наследуются от EventDispatcher или не наследуются совсем. Они выполняют различные действия по инициализации, обработке данных и пр.
  • events. Классы событий. Назначение их понятно - передача команд и данных.
  • extensions. Классы, представляющие собой расширения классов Mate. Собственно, расширяют функционал Mate для конкретных целей приложения. Таковых, в средне-обычном проекте вообще не бывает.
  • maps. Здесь размещаются карты событий EventMap. Содержат обработчики событий EventHandlers, Injectors.
  • views. Классы и компоненты, представляющие UI и всё что с ним связано - в общем, занимаются вводом и отображением данных.
  • vos. Классы объектов данных (Value Object). Это классы, наследники EventDispatcher, с набором bindable-свойств, представлюящих данные объекта. VO не должны ничего делать кроме как получать и выдавать свои данные.

Само собой разумеется, что каждый волен пользоваться собственной структурой. Но по мне, так лучше присоединиться к общественности и следовать какому-то общему правилу. Хотя бы самому обобщенно общему. Для лучшего понимания собственного и чужого кода.

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

Первое Mate-приложение

А о чем будет наше приложение? После некоторых изысканий, я окончательно убедился, что фреймворк рассчитан на работу с данными.

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

И тут подвернулся как раз подходящий проект - еще одна интерактивная карта с подгружаемыми данными маркеров и списка объектов. Ну теперь нужно не облажаться и все-же применить новое учение.

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

1. Создаем все Views

Их у меня получилось два:

  • первый - вывод карты с маркерами (LayerView.mxml),
  • второй - списки информации по объектам карты (InformationView.mxml).

Экраны оформляю так, чтобы все детали ушли в компоненты, а полученные компоненты "плавали на поверхности".

Таким образом, InformationView содержит компоненты:

  • InformationPanel - панель списка объектов карты
  • RouteSelectionPanel - панель выбора варианта маршрута

Каждый из них имеет dataProvider, в который передается список данных объектов карты informationDataProvider и список маршрутов routesDataProvider.

А LayerView содержит компоненты:

  • LayerContent - графическое содержимое карты (имеет selectedRoute - текущий вариант маршрута - ID клипа, который выводится на карте в данный момент)
  • MarkerSet - слой с множеством маркеров (имеет dataProvider)

Всё это лежит в папке views.

2. Создаем VO

Теперь создадим объекты данных, которые будут выводить наши views. Это обычные потомки EventDispatcher с Bindable-свойствами:

  • InstitutionVO - объект, описывающий организацию (дом) на карте (id, название, координаты маркера)
  • RouteVO - объект, описывающий маршрут на карте (id клипа, название маршрута)

Размещаем их в папке vos.

3. Создаем файлы данных

Имея представление о данных, которые мы выводим, можно создать XML-файл с данными. Данные будем получать по HTTP-запросу, и нам не важно, будет ли их кто-то генерировать или это будет простой XML файл. Сейчас главное, чтобы наше приложение их получало, обрабатывало и выводило. Создаю в src папку data, в которой размещаю XML-файл с данными. Структуру выбираю произвольно - так как мне удобно - тех-требований на формат обмена данными нет, поэтому их диктую я сам. URL файла данных приложение получает через переменные FlashVars (без подробностей).

4. Создаем поставщиков данных

InformationDataProvider - так я его назвал. Он получает загруженные данные, обрабатывает их и размещает у себя. Собственно, этим занимается его метод aquire(data:XML), который помещает данные в полях:

  • information:ArrayCollection - список объектов InstitutionVO,
  • routes:ArrayCollection - список объектов RouteVO.
В случае ошибки при разборе данных, или сервер возвратил информацию об ошибке, поставщик генерирует событие, информирующее об ошибке - SettingsEvent.SETTINGS_ERROR. В случае успеха - событие успешного получения данных SettingsEvent.SETTINGS_SUCCESS.

События из классов, не являющихся компонентами приложения, нужно генерировать через специальный, предусмотренный в Mate, класс Dispatcher. Тогда они будут отрабатываться в картах событий EventMap.
Размещаем его в папке business.


5. Создаем события и карты событий

В папке maps создаем InjectionMap.mxml, в котором размещаем теги Injectors, связывающие information (из InformationDataProvider) и informationDataProvider (из InformationView и LayerView), и аналогично для routes - routesDataProvider. Как только InformationDataProvider получит данные и установит их в information и routes - они тут же попадут по средством связывания (binding) в соответствующие поля InformationView и LayerView и будут отображены их компонентами в окне приложения.

Другая карта событий - MainEventMap.mxml - содержит обработчики событий. Такие инструменты как HTTPServiceInvoker и т.п. прекрасно заменяют рутинные классы отправки/получения данных. Обрабатываются все основные FlexEvent-события, которые позволяют обрабатывать инициализацию приложения и его готовность к работе. Чтобы событие улавливалось картой событий, оно должно иметь параметр по умолчанию bubbles:Boolean=true.
Итак, наша карта событий улавливает в контейнере EventHandlers событие FlexEvent.APPLICATION_COMPLETE и отправляет HTTP-запрос (HTTPServiceInvoker) на получение конфигурации. Не забываем указать resultFormat="e4x", чтобы полученные данные были представлены в виде XML. В разделе обработчиков resultHandlers помещаем MethodInvoker с вызовом нашего метода aquire, у которого resultObject указан в аргументах. В раздел faultHandlers помещаем обработчики ошибки запроса.

Теги с картами событий InjectionMap и MainEventMap обязательно помещаем в корне приложения.

Заметки

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

Столкнулся со следующими проблемами:

1. id в Request. Если я хочу передать в HTTPServiceInvoker, в Request переменную id - у меня проблема. В MXML id - это имя инстанцируемого объекта. В обсуждении предлагается использовать для этих целей параметр _id, но это не помогает - с запросом отправляется чепуха. Выход - не именовать так переменные (даже сильно поругался из-за этого с сервер-разработчиком).
2. source в EventHandlers. Переменные с именем source ведут как-то странно в обработчиках событий. Несколько раз ловил в них не действительное значение, а что-то вроде строки "Event". Непонятна причина такой особенности, поэтому, опять-таки, лучше избегать таких имен.
3. События. Не сильно проблемная особенность, но все же - нельзя модифицировать параметры конструктора события - добавлять и менять порядок следования параметров.

* * *

Работая с flex-модулями (Module), убедился, что Mate следует использовать очень осторожно. Лично я так и не понял, как сделать так, чтобы модуль выгружался и убивался GC.
Взаимодействие модулей с главным приложением производится успешно, однако, выгруженные модули продолжают ловить события.
Следуя инструкциям и собственным экспериментам, я постарался сделать модули как можно более автономными и создал следующую структуру:
1. Каждый модуль имеет свои карты событий. По возможности, я старался сделать их локальными (LocalEventMap). Однако, карты, которые работают с событиями главного приложения не могут являться таковыми, да и вообще - не очень то с ними всё сложилось.
2. События, которые используются и основным приложением и модулями выделены в отдельный пакет. Обработка и отправка событий в/из модуля вынесены в отдельные карты событий.
3. Перекрыл класс Module - каждый модуль при удалении из Stage подчищает в своих картах событий все возможные связи.

После таких действий, выгруженные модули теряют интерес к событиям приложения, однако, сомневаюсь, что они удаляются из памяти - есть угроза утечки памяти. Виновен ли в этом я, или Mate или вообще Flex - сказать трудно. Остается полагаться на то, что смена модуля не столь частая операция (я использую flex-модули в качестве "страниц" flash-сайта), чтобы съесть всю память во время просмотра сайта.

* * *

Общее впечатление

Mate упрощает разработку, но усложняет логику.
Многие вещи лучше визуализируются, работа с событиями выносится в отдельные блоки, повышается наглядность, а связность кода уменьшается. Превосходно решается задача отделения представления от логики - задача любого фреймворка, особенно для flash.
Возможность легкого надстраивания приложения - огромный плюс Mate. Если работа с событиями в приложении изначально организована правильно, добавлять новые программные возможности легче простого. Я без труда добавил возможности дип-линкинга SWFAddress, или встроил приложение в Zinc.

Однако, есть и обратная сторона. Логически связанные сущности разрываются, когда выносятся в карты событий. Рабочий процесс приложения рассредоточивается по файлам разного формата, в картах событий методы вызываются непривычным способом, имена их указываются как строки, а аргументы - как массивы, что мешает автокомплиту и компилятору помогать и контролировать процесс разработки. Да и на читабельности и понятности кода это сильно сказывается, и не в лучшую сторону. Я вообще молчу об удобстве отладки такого приложения. Всё построено на связывании (binding) и событиях, а всем известно - это злые враги дебагера.

При попытке как-то сохранить связность сущностей, я стараюсь группировать классы в обособленные пакеты, общающиеся друг с другом посредством общих событий. Это помогает сохранить логически стройное представление сущностей, но увеличивает количество файлов. Зачастую, файлы при этом просто дублируются, лишь с заменой имен событий и переменных. Особенно это касается бурного размножения классов событий. В итоге, простой проект выглядит красиво, но сложный - громоздко. С другой стороны, простое приложение легче сделать красивым чем сложное, которое в любом случае будет громоздким и потребует больших умственных затрат.

Итак, Mate - превосходный инструмент. Не скажу, что он сильно ускоряет разработку. Время, сэкономленное на рутине, легко тратится на вспухание мозга, пытающегося объять логику, заключенную в куче файлов, а так же на ловлю своих же багов (а иногда и багов Mate). Но, должен отметить, что всё зависит от опыта разработчика и правильного проектирования приложения.
И главное - как и любой другой фреймворк, Mate дает прочный каркас приложению, быстрый старт разработки, помогает больше сосредоточиться на логике приложения, не отвлекаясь на рутину.