Что нам дает 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, который решает основные задачи, и может полностью обеспечить проекты средней сложности. Все остальные потребности, разработчик может решить, используя свой веб-сервер.

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

Знакомство с 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:

• 5 копеек о Mate Flex Framework - хвалебная речь.
• Пример использования Mate Flex Framework - очень глубокая статья, которая дает много полезного, даже не только о Mate.
• Презентации Constantiner-а: "Mate framework", "Краткое введение в Mate Flex framework". Презентации хороши, но являются лишь подручным материалом докладчика. Без самого докладчика многое понять сложно.
• "Строим приложение на Mate framework + Zend_AMF".

Теперь, когда достаточно изучен хороший пример, почитаем документацию, и особенно, раздел 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 дает прочный каркас приложению, быстрый старт разработки, помогает больше сосредоточиться на логике приложения, не отвлекаясь на рутину.