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

Новый подблог "Flash-разработка. Сотрудничество"

Дублирую предисловие:

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

Итак, с этого момента, я буду выкладывать в этот блог всё, что уже не в силах взять на себя.

Надеюсь на понимание и, думаю, многим будет интересно найти здесь для себя занятие."

Блог здесь: http://racer242collab.blogspot.com/

Спасительный cacheAsBitmap и wmode=transparent

Небольшая галерейка. На фотки/иконки наводится мышь и всплывает окошко с информацией. Окошко с указателем. Представляет собой Sprite, в котором находятся указатель и Sprite с плашкой информации. Плашка выравнивается с учетом положения на экране - подравнивается края - изменением координаты x. Плашка со скруглениями, с 9Slice и с фильтром-тенью.

В нормальных условиях, всё работает замечательно. При wmode=transparent, когда флэшка выводится поверх HTML-контента, плашка выводится усеченной, не в том смещении. Протрейсил координаты - всё нормально. При запуске - ужос.

Нам известны проблемы wmode=transparent - они странны и непредсказуемы. Особенно когда на прозрачность попадают фильтры.

Интуиция срабатывает без промашки. В коде выравнивания плашки, в конце ставим строчку this._infoContainer.cacheAsBitmap=true; (_infoContainer - это окошко, контейнер для плашки и указателя, DisplayObjectContainer). Теперь всё выводится корректно.

Копипаст фильтров из CS во Flex

Хорошая это штука - "Copy Motion to ActionScript 3" - в IDE CS3 (речь идет именно об этой версии). Наверняка, все уже давно смекнули, какие выгоды она несет для Flex. Главная выгода - сокращается объем ручной работы и отладки.

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

1. В тестовом файле создаем клип образца, визуально похожего на то что у нас должно быть во flex - например, текстовое поле или кнопку. Навешиваем на нее кучу фильтров, до получения нужной нам картинки.
2. На слое с клипом кликаем правой кнопкой и выбираем "Copy Motion to ActionScript 3".
3. Вставляем куда-нибудь то, что скопировалось в буфер - например, тут же в редактор Actions.
4. Находим там блок <filters>...</filters>
5. Копипастим его себе во Flex-код, в контейнер тега нужного нам визуального компонента.
6. Заменяем filters на mx:filters и filters:BevelFilter на mx:BevelFilter. (у mx:filters может быть другой префикс - зависит от компонента)
7. Компилируем и получаем картину, аналогичную CS. Дотюниваем, если необходимо, параметры.

Мой дорогой блог...

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

Генерим облака

Вот понадобилось мне облака генерить. Изобретать велосипед не будем - прямиком в гугл.
А тут красоты всякой - видимо-невидимо.

Сразу хочу отметить полезный тул: Perlin Noise Explorer. Собственно, кто еще недопонял, что такое perlin noise, может подробно изучить это явление.

Замечательный пейзажик: Actionscript 3.0 perlinNoise method.
Облака с перспективой: Clouds.
Целый движок: Perlin Clouds and Frocessing (with an F).

Без демки, но проверены:
Generating Pseudo Realistic Clouds In Flash (AS3 + Perlin Noise)
Lets make some (perlin) noise!

Не облака:
Забавная пружинка: тут.
Нереальные игры с электричеством: тут.
Красивое облако: тут.
Земля: Papervision3D clouded planet Earth tutorial and source.
Такие вот пузыри: Actionscript 3 blobs / lava lamp effect
Древесные кольца: тут.

Да... Всё красиво, но мне, увы не подошло. Идея такова, что нужно генерировать небольшие клочки облаков, а для этого нужно на полученную текстуру наложить маску, плавно описывающую область. По всей видимости, времени не хватит. Вставлю картинками.

* * *

Решил поступить так. Берем пример Generating Pseudo Realistic Clouds In Flash (AS3 + Perlin Noise). Подстраиваем параметры таким образом, чтобы облака были редкими.
Для большой области, динамический рендер по производительности просто убийственный. Но мы генерируем крупный битмап один раз, не скупясь на качество, и затем, просто скроллим его циклически.

* * *

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

* * *

В примере, полученый клип с облаками накладывается с эффектом blendMode = "screen". Для производительности это не есть хорошо. Поэтому, в целях оптимизации, рабочий битмап делаем прозрачным, заливаем белым цветом и копируем в его альфа-канал любой из цветовых каналов сгенерированного битмапа с облаками. Точнее, для генерации perlinNoise используем один канал, который потом и копируем.

MPS, MIoC и утро испорчено

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

Но тут мозг натыкается на незнакомые сочетания букв. Таак. Мифы MPS. Явно не про мазду. MPS... MPS, что-то википедия ерунду выдает. Ладно, читаем дальше. Ну пипец, ни одной ссылки, будто и правда все всё знают, а я в мазде. Ага, это редактор. Попался, голубчик. От оно чо - Meta Programming System. Вот и википедия сразу разродилась. Ну в общем всё ясно. Шагай в будущее с MPS первой версии. Для чего оно нужно? Для создания и работы с DSL (опять неоднозначные аббривиатуры - это не про модем, это Domain-specific language - или лучше Предметно-ориентированный язык программирования). Теперь и пост про мифы можно почитать.

Что еще у нас интересного на сегодня? Ага, injun до Swiz добрался. Забавный принцип. Про паззлы понравилось, хоть никогда их и не любил - скучное занятие.
Все похвалили MIoC. Вот, спасибо, для тех кто в мазде - разшифровка (Metadata-driven autowire IoC framework для ActionScript 3). Про IoC знают многие, а вот MIoC - не думаю.

Напоследок. Случился бум Flash+Drupal. Мне так показалось, что пост Flash на Drupal произвел неизгладимое впечатление на Flex Constructor, и в течение последующих 3,5 часов он выдал Flex+Drupal=... C интеграцией flash и CMS сталкивается почти каждый flash-разработчик. На моей практике, сводится она к тому, что либо сервер диктует формат обмена данными, либо это делаю я сам. Второе чаще. Здесь же этот процесс систематизируется и ставится на рельсы, по которым очень скоро покатятся составы, полные готовых drupal-модулей для flash-сайтов, flash-приложений, flash-виджетов и flash-т.п. Идея популяризации Drupal очевидна.

Всё. Утро еще не кончилось, и мозги уже дымятся. А ведь еще завал работы...

Ух ты! Binding

Случайно столкнулся с таким вариантом байндинга:

Вот к примеру, обычно мы делаем вот так:
<someComponent someAttribute="{someValue1+'_splitter_'+someValue2}"/>

А оказывается можно и так:
<someComponent someAttribute="{someValue1}_splitter_{someValue2}"/>

Выбираем движок для просмотра Flash-панорам

Сегодня ищем движок для просмотра flash-панорам.

Для начала - немного теории панорам: Панорамная фотография, BASICS (здесь же можно найти и другую информацию про панорамное фото, софт, вьюверы).

По flash-вьюверам панорам, Гугл выдал следующих претендентов:

• Flash Panorama Player - платный, недорогой вьювер кубических панорам. Принцип прост - имя swf-файл вьювера должно соответствовать имени jpg-файлов, которые имеют соответствующие сторонам куба суффиксы.
• Ryubin's Flash Panorama Laboratory - Отличный движок, без исходников, но настраиваемый через XML.
• krpano - платный, недорогой вьювер с кучей дополнительных фич, типа эффект линз и тп.
• PanoSalado, Spincontrol - опенсорсный движок на базе PV3 и AIR-утилита для сборки виртуальных туров. Есть и исходники и документация.

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

Code-behind или mx:Script?

До некоторого времени, я выносил объемный AS-ккод из MXML-компонентов, используя тег <mx:Script/>:
<mx:Script source="includes/ComponentName.as"/>
Каких-либо логических недостатков такого метода я не наблюдал, однако столкнулся с постоянной глючностью автокомплита AS-редактора FlexBuilder. И вот, когда меня в конец это достало, решил взять на вооружение способ Code-behind.

Про Code-behind пишут следующее:
Code Behind
Building components by using code behind
Code-Behind in Flex 2
Code-behind gotcha in Flex Builder for AIR apps
Советы новичкам

В кратце, суть проста - наш MXML компонент ComponentName не базируется напрямую на основном компоненте, например, Canvas, а на компоненте-"прослойке" ComponentNameClass (также используется суффикс -Base). Код этого компонента размещается в ComponentNameClass.as. Его класс является потомком класса того самого основного компонента (Canvas) и содержит весь необходимый AS-код.

Все компоненты, которые имеются в ComponentName.mxml и к которым нужен доступ, должны быть объявлены в ComponentNameClass.as как public. Методы и обработчики событий - public или protected.

Вообще, конечно, это очень правильный подход. Только напрягает пара фактов - нужно возиться с объявлением класса и объявлять все компоненты, с которыми необходимо иметь дело в as-файле. Если, к примеру, я вдруг передумаю использовать в MXML вместо LinkButton (а он уже объявлен так в AS-компоненте) простой Button, получу ошибку - необходимо везде сделать замену. Выход - объявлять их дальних предков или вообще интерфейсы.

А вот интересно - есть ли средства автоматизации этого процесса? Что-то типа команды "Create Code-behind Class" или при создании MXML-компонента подобная галочка. Я не нашел...

Модули, синглтоны, Type Coercion Failed и спасение

Сегодня столкнулся с такой проблемой:

Приложение использует модули. Один из модулей содержит ComboBox.
Во время работы, подгружается то один модуль, то другой. Так вот.
При первой активации, модуль с ComboBox работает корректно. Однако, при повторной активации модуля, начинаются проблемы - при нажатии на ComboBox вылетает ошибка:
TypeError: Error #1034: Ошибка типа Coercion: невозможно преобразовать mx.managers::PopUpManagerImpl@6c0ce41 в mx.managers.IPopUpManager.

Аналогичная ошибка с компонентом List, правда немного с другими классами:
TypeError: Error #1034: Ошибка типа Coercion: невозможно преобразовать mx.managers::DragManagerImpl@6b7ec11 в mx.managers.IDragManager.

Ужасаясь перспективе просидеть в дебаге всю ночь, полез в Гугл. И тут же нашел спасение - не один я столкнулся с таким казусом:
Flex Error #1034: Type Coercion Failed: Cannot Convert Mx.managers

Вот решение (я его оформил немного поизящнее):
Нужно в коде основного приложения указать следующую строку:
import mx.managers.*;DragManager;HistoryManager;PopUpManager;

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

Записываем звук с помощью Red5

Этот пост - итог исследования "Сохраняем звук с микрофона на сервер" проведенного еще в январе. Суть проекта - конкурс колыбельных - любой желающий может зарегистрироваться и записать песню в собственном исполнении.

Как обычно бывает, с момента зарождения проекта, уходят месяцы на процесс впаривания, продажи, рисования и утверждения дизайна. И вот, наступает очередь разработчиков, и, как обычно, на flash выделяется неделя, в лучшем случае - две (какая несправедливость).
В этот раз, правда, всё было несколько иначе - разработка началась как раз примерно за неделю до моего отлета в Египет. Поэтому, пришлось сделать максимум, чтобы без меня две недели люди всё это ставили на свои рельсы. Принцип вынесения всех настроек в FlashVars решает эту проблему на раз. Главное не забыть составить подробный мануал.

Итак, мы пришли к решению, что лучше в качестве медиа-сервера использовать Red5. Процесс установки под Windows и тестирования Red5 для локальной разработки я описал здесь: Установка Red5 и всё что нужно для Red5-разработки. По сути, в этом посте изложено всё необходимое для создания минимального приложения для записи звука/видео. В качестве формата хранения звуковых данных, решили оставить FLV. Сначала планировали конвертацию FLV в MP3 на сервере, и даже были идеи как это реализовать. Но позже решили, что для нужд проекта это излишество и лишняя нагрузка на сервер. Все записи сохраняются как есть, в формате FLV, и воспроизводятся проигрывателем, который, кстати, по виду и функционалу совсем не отличается от того, что воспроизводит MP3.

С flash-частью оказалось всё слишком просто. Достаточно было использовать версию Flash 8 и AS2. За основу я взял пример из ...\Red5\swf\samples\SimpleRecorder.fla. С момента окончания разработки прошло уже около месяц и многое забылось, но вот пара важных заметок:

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

В итоге, на выходе у меня получились две версии проигрывателей звука в форматах MP3 и FLV (можно было сделать универсальный, но времени не хватило) и рекордер звука.
На локальном Red5, под Windows, это хозяйство работало на ура. Однако, когда потребовалось поставить Red5 под FreeBSD (если не ошибаюсь), у админов возникли серьезные проблемы с настройкой нашего приложения. Подробности мне не известны, знаю только, что у них всё заработало за день до моего прилета (т.е. возились 2 недели :) ).
Такова уж особенность Open Source - конфигурация представляет собой темный лес xml-файлов, а нормальные инструменты по настройке, так чтобы галочку поставил и всё заработало - отсутствуют. Вот и выбирайте - платить за софт, или платить специалистам за настройку бесплатного софта. Но, слава Богу, всё это уже не моя забота.

* * *

Неплохая статья в тему:
Урок. Вебкамеры с Flex 3. Часть 2

mx:Pause vs flash.utils.Timer. Flex

Декларативность MXML - огромное достоинство Flex.
Легкое определение переменных в MXML значительно упрощает разработку:

• позволяет легко и наглядно определять их свойства и обработчики событий
• автоматически делает переменные Bindable
• позволяет их связать с другими переменными и выражениями
• делает наглядным код

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

Например, класс flash.utils.Timer невозможно представить в виде MXML. Компилятор выдает ошибку "Неправильное количество аргументов". Всё от того, что конструктор этого класса содержит один обязательный параметр. Как его указать, и возможно ли это, увы, я не понял.

Но есть простое решение - использовать другой класс, хорошо подходящий по своему функционалу - mx.effects.Pause:

<mx:Pause
id="somePause"
duration="2000"
effectEnd="somePause_effectEndHandler(event)"
/>

. . .

//Стартовать задержку
this.somePause.play();

. . .

private function somePause_effectEndHandler(event:EffectEvent):void {
//Обработать окончание задержки
}

ASDoc in MXML. Правильно комментируем MXML.

MXML для Flex-разработки имеет первостепенное значение. Однако, воспринимая его как порождение XML, до некоторых пор, я не считал его языком программирования или чем-то в этом духе.
Теперь, уже достаточно сроднившись с MXML, понимаю, что есть необходимость правильно его комментировать. Просматривая листинги MXML, глаз так же нуждается в разделении блоков, как и при чтении AS-кода.
Если с AS-кодом всё давно ясно (я его использую везде где надо и где необязательно), то вот с MXML хотелось бы разобраться. И поможет нам в этом статейка "ASDoc in MXML - Functional and Design Specification". Выделим основные мысли из нее.

Основные положения

В настоящее время не существует способа документировать MXML-компоненты. (Кстати, в лайфдоках про это вот что сказано: Documenting MXML files). Компилятор asdoc не обрабатывает комментарии в MXML-файлах. Но число компонентов, разрабатываемых на базе MXML неуклонно растет, поэтому поддержка в asdoc файлов MXML очень бы помогла разработчикам при создании документации.

ASDoc комментарий

Для того, чтобы ASDoc-комментарий был обработан asdoc-компилятором, необходимо указать 3 тире после <!:
<!--- asdoc comment -->
Для сравнения - обычный комментарий начинается с 2-х тире.

Комментирование MXML-компонентов и компонента уровня класса

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

<?xml version="1.0"?>

<!-- Standard MXML comment: events\myComponents\MyButton.mxml -->

<!---
The class level comment for the component.
This tag supports all ASDoc tags, and does not require a CDATA block.

@see mx.container.VBox
-->
<mx:VBox xmlns="http://ns.adobe.com/mxml/2009" xmlns:mx="library:adobe/flex/halo" >

<!--- Comment for button -->
<mx:Button id="myButton" label="This button has comment"/>

<!--- This comment doesn't belong to any component and will be ignored -->

</mx:VBox>

Комментарии перед тегами Script, Metadata будут игнорироваться. Перед тегами Definition, Library, Private и внутри их, комментарии так же будут игнорироваться.

Итог

В статье приводятся примеры использования ASDoc комментирования в различных его применениях. Рассматривать их подробно я не буду - всё достаточно прозрачно.

Вывод таков - MXML комментировать надо. И для этого уже существует прототип (если я правильно понял) стандарта, которого и следует придерживаться.

Дружим Flex с Flash. Заметки: загрузка, внедрение, шрифт. Flex

Закончился очередной дидлайн. После крупных проектов, которые делаются за 3-4 дня практически с нуля, остаются ощущения, схожие с состоянием после автобусного тура: в голове каша, мельком что-то увидел, урывками что-то запомнил, надо разобрать фотки. Теперь настало время немного отдышаться и закрепить полученный опыт.

Для начала, несколько заметок:

• Перенос строки в строках MXML: символ &#xd; - мелочь, а приятно.
• Загрузка сложных Flash-приложений в SWFLoader должна производиться в выделенный домен приложения, т.к. могут быть конфликты классов:

<mx:SWFLoader autoLoad="false" id="swfLoader" source="application.swf" />

. . .

private function creationCompleteHandler(event:Event):void {
swfLoader.loaderContext=new LoaderContext(false,new ApplicationDomain());
swfLoader.load();
}

• Если внешнее приложение подгружается в SWFLoader, есть вероятность, что в какой-то момент SWFLoader потеряет stage, что может пагубно отразиться на функциональности этого приложения. Если приложение где-то внутри обращается к stage и не обрабатывает его недоступность, то будут генерироваться ошибки. Побороть этот недостаток я не смог - только устранив все "не защищенные" stage из внешнего приложения.
• Внедрение шрифтов. Гораздо надежнее внедрять шрифт непосредственно из TTF файла. Внедрение из файла SWF, в котором, в свою очередь, внедрен необходимый шрифт лучше оставить для тяжелых случаев несовместимостей с Flex. Дело в том, что почему-то, внедренные в SWF разные стили (normal, bold) шрифта не корректно "извлекаются" Flex-ом. Он не дает назвать разные стили разными именами (как это можно сделать в первом случае), теряет одно из начертаний (жирный шрифт просто не выводится). Возможно, это из-за особенностей конкретных шрифтов, но первый метод срабатывает гораздо стабильнее.

@font-face
{
fontFamily: "Century Schoolbook";
fontWeight: normal;
fontStyle: normal;
src: url("file://./assets/fonts/CENSCBK.TTF");
unicodeRange:
U+0020-U+0040, /* Punctuation, Numbers */
U+0041-U+005A, /* Upper-Case A-Z */
U+005B-U+0060, /* Punctuation and Symbols */
U+0061-U+007A, /* Lower-Case a-z */
U+007B-U+007E, /* Punctuation and Symbols */
U+00FC-U+00FD,
U+0410-U+042F, /* Cyrillic Upper-Case A-Z */
U+0430-U+0451; /* Cyrillic Lower-Case a-z */
}

@font-face
{
fontFamily: "Century Schoolbook Bold";
fontWeight: bold;
fontStyle: normal;
src: url("file://./assets/fonts/SCHLBKB.TTF");
unicodeRange:
U+0020-U+0040, /* Punctuation, Numbers */
U+0041-U+005A, /* Upper-Case A-Z */
U+005B-U+0060, /* Punctuation and Symbols */
U+0061-U+007A, /* Lower-Case a-z */
U+007B-U+007E, /* Punctuation and Symbols */
U+00FC-U+00FD,
U+0410-U+042F, /* Cyrillic Upper-Case A-Z */
U+0430-U+0451; /* Cyrillic Lower-Case a-z */
}

• Внедрять клип из внешней SWF так, чтобы работали его фреймовые скрипты можно следующим образом:
  source="@Embed(source='assets/Index.swf')"
  При внедрении отдельного символа, его фреймовые скрипты и скрипты всех вложенных объектов теряются:
  source="@Embed(source='assets/Index.swf'#Index)"
  Игра с параметром mimeType не помогает.

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

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

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

Прекрасный момент - праздник еще не настал, а дидлайны уже позади! Отдыхать и набираться сил.

И конечно, наших прекрасных женщин поздравляю с праздником 8 марта!

Модули vs. компоненты. Flex

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

Ну, условно, у себя я уже могу выделить две стадии (не считая робкого потрагивания и любопытного пощупывания):

• Код представляет собой голый MXML, на котором и построено всё приложение. Крупные вспомогательные структуры классов и обильные инклюды. В решении относительно сложных задач (либо совсем простых) я полагался только на pure AS проекты и компоненты.
• Приложение делилось на компоненты (MXML компоненты), каждое окошко, каждый функционально законченный экран были компонентами. Обильное использование компонентов значительно упростило разработку приложений и внесло строгость и порядок, несмотря на довольно пространный список в Components -> Custom.
  Кроме того, такой подход значительно ускоряет разработку, уже засчет того, что визуальный редактор теперь не должен перерисовывать каждый раз всё приложение (а делает он это отнюдь не быстро).

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

Руки так и зачесались попробовать создать модуль в FB. Открываю проект, создаю New->MXML Module. Открывается новый файл mxml, в который я добавляю, к примеру, кнопку, и текстовое поле. Сохраняю. В окошке Components->Custom появился новый компонент, по имени модуля.
Проведем эксперемент. Перетащим его в окно основного приложения. Всё как с обычным компонентом. Компилирую. Замечательно: скомпилировалось два swf - один с именем приложения, другой - с именем модуля.
Для любопытства, копируем один только swf приложения и запускаем: видим кнопку и текстовое поле. Как я и предполагал, наш модуль включен в состав swf приложения как обычный компонент.
Запустим swf модуля. Сразу получаем ошибку "Не удалось найти класс mx.core::SpriteAsset." И не мудрено - модуль не содержит классов, включенных в основное приложение.
Но нам-то от модуля нужно что? Чтобы он не был включен в приложение, а подгружался в процессе работы приложения. Хотя, возможность использовать модуль как обычный MXML-компонент тоже надо отметить.

Ознакомимся вкратце с документацией: Creating Modular Applications. Здесь всё, на достаточно понятном языке, достаточно подробно разжевывается.

Итак. Нас интересовали загрузка модуля и ее мониторинг.
Пожалуйста, смотрим: Loading and unloading modules. За загрузку отвечает класс ModuleLoader. Любопытно, что это наследник VBox. Непонятно, почему именно VBox, а не, к примеру, HBox. Уж я-то вообще ожидал увидеть в этой роли SWFLoader. Ну да ладно. Убираем из кода приложения модуль и вставляем ModuleLoader. Кстати, он присутствует в палитре компонентов Layout.
Вписываем в свойство url имя файла модуля. И что особенно приятно, визуальный редактор сразу отобразил содержимое модуля. Вводим имя другого модуля - пожалста! Отображается другой модуль. Запускаем - всё замечательно отображается и работает.
Теперь по поводу мониторинга. Смотрим Using ModuleLoader events. ModuleLoader генерирует следующие события: setup, ready, loading, unload, progress, error, и urlChanged. Но позвольте! Если progress мы наблюдаем в этом списке, то почему нет open и complete? Что помешало вместо loading генерировать open, а вместо ready - complete?
При таком раскладе, если я использую ProgressBar в режиме mode="event", загрузка успешно мониторится, но ProgressBar не генерирует событие complete, что в некоторых случаях было бы полезно. Ну что ж, никто не мешает нам устранить этот недостаток, создав своего потомка ModuleLoader. Дело поправимое.

Есть еще один компонент, управляющий загрузкой модулей: ModuleManager. Этот класс, как нам обещают, предоставляет больше возможностей по управлению загрузкой модулей чем предыдущий. Но при этом, как утверждается, техника его использования является менее абстрактной чем работа с ModuleLoader.
Да, разработчики Flex не перестают меня удивлять. ModuleManager наследуется от Object и содержит всего два статических метода, что ввело меня в небольшой ступор. Однако, после изучения предложенных примеров, всё встало на свои места. Метод ModuleManager.getModule возвращает объект, удовлетворяющий интерфейсу IModuleInfo, уникальный для каждого управляемого модуля. Этот объект, в дальнейшем, можно использовать для загрузки модуля (метод load) и мониторинга событий загрузки, а затем, для инстанцирования модуля (через свойство factory).
Более подробное изучение этого класса, погружает нас в глубины Flex, что в мои планы пока совсем не входит. Вот уж, другими словами и не скажешь - все намного менее абстрактно. И больше подходит для решения специфических задач.

Ну-с, добро пожаловать в мир модульных приложений. Начинаем действовать!

* * *

Впечатления. Работа с модулями не разочаровала: стабильно и надежно. Единственные проблемы, с которыми я столкнулся:

• Внедрение шрифта. CSS с внедрением TTF-шрифта определяется в главном приложении. Подгружаемые модули успешно используют эти шрифты. Но, возникла проблема с внедряемыми SWF, в которых используется другой шрифт. При вводе в динамические поля, ничего не отображалось. Тогда я внедрил этот шрифт в модуль. Шрифт стал отображаться. Но, что интересно, когда я собрал Release Build, шрифт опять перестал отображаться. Пришлось оставить Debug-версию модуля. Но это повлекло за собой следующую проблему.
• Если основное приложение собрано в Release Build, оно некорректно подгружает модуль, собранный в Debug Build. Я думаю, что вообще, по-отдельности модули лучше не обновлять. Я обратил внимание, что размер SWF-файла модуля даже при небольших изменениях, при перекомпиляции заметно меняется. Поэтому, следует, наверное, соблюдать осторожность при компиляции и обновлении модулей.

В цинковом гробу. Перетаскиваемые окошки

Волею судеб, свалился мне проект такой. Есть несколько флэшек, так называемых виджетов, которые нужно одеть в Zinc так, чтобы еще и под Mac OSX работали.

Во-первых, сразу зарекаюсь - Мак только для мак-девелоперов. Без меня. Такого количества проблем я уже давно не встречал. Возможно, основным виновником их является Zinc, который я смело могу назвать УСЛОВНО кросс-платформенным.

Что сказать про Zinc 3.0? Под красивым брендовым дизайном, симпатичной оболочкой, красивыми заголовками скрывается довольно ограниченный функционал, убогая документация и море непонятностей, глюков и граблей.

В данном посте, приведу один пример, как простая задача решается через "заднее место".
Нужно, чтобы окошко нашего виджета перетаскивалось мышкой за специальную панельку. В документации, нам рассказывают про это так: Creating a Draggable Form. И что мы получаем? Да полный отстой. Мышь теряет окошко, потом, при наведении вдруг опять подхватывается, уже без нашего на то соизволения, в общем, ужас. Как это победить? Нужно повесить 3 обработчика мыши на панельку и сделать это вот как:

dragNDropRenderer.buttonMode = true; dragNDropRenderer.useHandCursor = true;
dragNDropRenderer.addEventListener(MouseEvent.ROLL_OVER, rollOverHandler);
dragNDropRenderer.addEventListener(MouseEvent.ROLL_OUT, rollOutHandler);
dragNDropRenderer.addEventListener(MouseEvent.MOUSE_UP, mouseUpHandler);

. . .

private function rollOverHandler(event:MouseEvent):void {
mdm.Forms.getFormByName("MainForm").startDrag();
}

private function rollOutHandler(event:MouseEvent):void {
if (!event.buttonDown) {
mdm.Forms.getFormByName("MainForm").stopDrag();
}
}

private function mouseUpHandler(event:MouseEvent):void {

var renderer:DisplayObject = DisplayObject(event.target);

if (!renderer.getBounds(renderer).contains(event.localX,event.localY))
mdm.Forms.getFormByName("MainForm").stopDrag();
}

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

Другие баги - почему под MacOX криво работает LocalConnection, или не открываются Zinc-ом новые окошки, и не распарсивается полученный с сервера XML, мне еще предстоит выяснить. Чувствую, это будут "приятные" сюрпризы.

* * *

В обработчик отпускания мыши добавлена проверка на отсутствие мыши в области панели.

* * *

Продолаются жалобы. Под MACOX не удалось (под Windows всё Ок) передать на сервер запрос с GET-параметрами (URLRequest). Запрос проходит, параметры не передаются. Не имел возможности выяснить, виновен ли в этом Zinc или админы сервера. В итоге, стали передавать параметры через POST, что сразу дало положительный результат.

* * *

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

* * *

Всё. Финиш. Zinc и MacOX - больше несовместимые понятия. Делаю полноэкранное приложение. В окне приложения, справа, где-то на 1/4 ширины, существует "мертвая" зона, в которой мышь перестает оказывать воздействие на интерактивные flash-элементы. Нет, нельзя сказать что совсем не оказывает. После 5-10 нажатий, кнопка срабатывает. Но это же бред. Элементраный пример - делаем во flash плашку размером с экран (1280x800), вставляем SWF в гроб, билдим и наблюдаем эту границу. Кошмар. Под Windows и под MacOX в Safari работает превосходно.
Сделать многооконное приложение с Zinc также не получилось - опять же проблемы с мышью. Интерактив не откликается.

Как отображать шрифт без сглаживания (bitmap text) во Flex

Flex имеет некоторые ограничения в работе с внедренными шрифтами.
Если во Flash CS, мы можем просто так взять, да и указать тип рендеринга шрифтов "Bitmap text" (без антиалиасинга) и иметь полноценное отображение текста с неполной прозрачностью, наклоном и т.п., то во Flex мы можем только управлять параметрами сглаживания шрифта, или не внедрять шрифт совсем (тогда о прозрачности не может быть и речи).

Но если мне, всё-таки, нужен именно несглаженный полупрозрачный шрифт?
Проблема решается, как и многие другие во Flex, через "одно" место.
В лайфдоках, находим такую статейку: Embedding fonts from SWF files. Здесь рассказывается вообще о внедрении шрифта с использованием Flash CS. Пользуясь таким методом, можно внедрить любой шрифт, поддерживаемый Flash CS.

Однако, здесь не сказано ни слова про внедрение шрифта Bitmap text (без антиалиасинга). И вообще, в документации Flex, про это как-то совсем ничего нет. А ведь это странно и непонятно - Flex-приложения как раз направлены на отображение данных, а всем известно, что данные отображаются лучше несглаженным шрифтом. К чему тогда все эти эффекты с фэйдом и прочими трансформациями, если невнедренный шрифт их не отображает.

Нам на помощь приходит статья всеобщего друга всех флэшеров GSkinnerа Bitmap Fonts in Flex (via Flash). Правда, в ней всё несколько усложнено, но, подозреваю, что это из-за того, что писалось это для Flex 2. Ну а мы то уже на Flex 3, поэтому всё немного проще. Идея в том, что шрифт, внедренный как Bitmap text, меняет название в некую неприглядную форму, типа "Tahoma_12pt_st".

Итак, к чему мы пришли (опишу вкратце мои действия):

1. Создаем SWF-файл fonts.swf (можно любой другой). Версия Flash 9, ActionScript 3.0. Во всех статьях создается файл версии Flash 8, но, почему-то, у меня такой файл Flex не подцеплял/ - не может оттранскодить.

2. Создаем текстовые Dynamic-поля, в каждое из которых добавляем хотя-бы один символ нужного нам начертания. Соответственно, если все начертания нам нужны, то будет 4 текстовых поля: Normal, Bold, Italic, Bold Italic.

3. Устанавливаем размер шрифта, который мы будем использовать в Flex-приложении. Дело в том, что в приложении, корректно может быть отображен только один размер внедренного шрифта - тот который мы сейчас укажем. Если указать другой размер, шрифт некрасиво размажется. Я указываю 12.

4. Указываем в Embed... диапазоны, которые нам надо внедрить.
Кстати, можно пойти другим путем и, вместо текстовых полей, создать в библиотеке 4 символа-шрифта (New font...) и всё будет точно так же, за исключением того, что шрифт внедрится весь - без ограничений, что плохо для объема.

5. Компилируем и добавляем в папку проекта.

6. В CSS файле проекта (я отвел для этого специальный файл fonts.css) указываем следующий код:

/* CSS file */
@font-face {
src: url("file://./assets/fonts.swf");
fontFamily: "Tahoma_12pt_st";
fontStyle: normal;
fontWeight: normal;
}

@font-face {
src: url("file://./assets/fonts.swf");
fontFamily: "Tahoma_12pt_st";
fontStyle: normal;
fontWeight: bold;
}

@font-face {
src: url("file://./assets/fonts.swf");
fontFamily: "Tahoma_12pt_st";
fontStyle: italic;
fontWeight: normal;
}

@font-face {
src: url("file://./assets/fonts.swf");
fontFamily: "Tahoma_12pt_st";
fontStyle: italic;
fontWeight: bold;
}

7. Теперь, мы можем в любом стиле указать:

Text.Regular {
fontFamily: "Tahoma_12pt_st";
fontSize:12px;
fontAntiAliasType:normal;
}

Важно указать параметр fontAntiAliasType:normal. Если этого не сделать, шрифт в некоторых случаях будет отображаться размыто, а если это выделяемый текст - при его выделении будет твориться что-то невообразимое.
Ну и конечно, не забыть уточнить размер шрифта - иначе всё поедет.

8. Ну и собственно, применяем этот стиль к компоненту:

<mx:Text
width="100%"
styleName="Regular"
>
<mx:htmlText><![CDATA[<b>Максимальный</b> размер загружаемого файла — 3 Мб. Допустимые форматы: GIF, JPG, BMP, TIFF, PNG.]]>></mx:htmlText>
</mx:Text>

Если нам понадобится шрифт другого размера - уж не поленитесь, повторите всё со второго пункта - так уж положено.

* * *

Да, забыл добавить про то, что здорово помогает в разборках со шрифтами такой кусочек кода (взят из статьи):
var fontList:Array = Font.enumerateFonts(false);
for (var i:uint=0; i<fontList.length; i++) {
trace("font: "+fontList[i].fontName);
}


Прогресс-бар на любой вкус. Flex

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

Скинирование позволяет заменить лишь изображения не залитой и залитой полос. Ну а если мне не нужна полоса?
Порыскав по интернету, пришел к выводу, что все усиленно заморачивались на проблему подмены предзагрузчика flash/flex-приложений, а вот видоизменить ProgressBar, почему-то никому не понадобилось.

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

Продолжение следует...