Flash-разработка

Переезд на Tumblr

2012-01-09T00:21:00.002+04:00

Переезжаю на Tumblr из Blogger-а: http://racer242.blogspot.com/.

Вроде бы нет причин для переезда. Да и блог мой стал совсем неактуальным. Уже год я в него толком ничего и не писал. Висит несколько черновиков, которые и публиковать то не хочется. Причина банальна. В моей практике flash-разработчика кончилось время исследований и достижений. Сегодня моя работа базируется на отработанных годами механизмах, о которых уже давно всё сказано.
Однако, ряд событий и последние известия относительно развития самой Flash Platform, навели меня на определенные мысли. Видимо, пора обновлять свой арсенал и поднимать якоря в поисках новых и более привлекательных гаваней. Меня сильно привлекла активность моего “кормильца” Adobe в направлении переноса своих технологий и опыта на HTML5. Я верю в успех этого дела и, пока не поздно, подключаюсь. И расширяю область своих интересов от “Flash-разработки” до “Front-end-разработки”, что включает в себя и Flash, и HTML5, и всё что им сопутствует.

Переход на новый блоговый движок обусловлен не только новой направленностью моих изысканий. Пользуя tumblr как веб-, так и iPhone-приложение, я испытываю гораздо больший комфорт чем от Blogger-а. Да и эта гугловая “замкнутость на себе” немного раздражает.

Всё. Прощаюсь с милым старым Блоггером без особых сожалений. Увидимся на Тумблере http://racer242.tumblr.com/.

Zinc screensaver free

2011-07-19T22:53:00.008+04:00

Скачал последний Zinc, поставил, подтянул проект. Работает, и никаких упоминаний о пробной версии. Раньше выводил поверх контента сообщение о пробной версии и все было очевидно. А чего от него сейчас ожидать? Или это неожиданная халява?

* * *

Кстати, столкнулся с проблемой вывода на экран screensaver-а при расширении рабочего стола на несколько мониторов. Приложение растягивается на область всех мониторов, что для вывода вменяемого контента недопустимо. Полдня бился над тем, как вывести контент только на один монитор и желательно главный.

Решение простое:

1. Берем размер экрана: mdm.System.screenWidth и mdm.System.screenHeight

2. Берем координаты главной формы: mdm.Forms.getFormByName("MainForm").x и mdm.Forms.getFormByName("MainForm").y

3. Устанавливаем размер приложения по размеру экрана: mx.core.Application.application.width и mx.core.Application.application.height.

4. Если координаты формы отрицательные, то устанавливаем: mx.core.Application.application.x=-mdm.Forms.getFormByName("MainForm").x и mx.core.Application.application.y=-mdm.Forms.getFormByName("MainForm").y

* * *

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

Забавный глюк автокомплита

2011-01-22T13:34:00.003+03:00

Flash Builder Burrito. Работаю с двумерным массивом.

Автокомплит перестает работать после строки:

this.matrix[objectPosition.y, objectPosition.x]=1;

Причем автоподстановка импортов классов так же начинает глючить и плюхает импорты прямо посреди кода.

Исправляю и всё работает:

this.matrix[objectPosition.y][objectPosition.x]=1;

Flash Builder Burrito

2011-01-12T23:52:00.020+03:00

Начало года - мертвый сезон - время апгрейдов и апдейтов.

Windows 7 и весь свежий софт уже стоят, пора обновить рабочие инструменты.

Первый главный инструмент Flash Professional CS5 стоит, и вполне себе устраивает. После CS3, прогресс явно ощутим.

А вот Flash Builder, несмотря на достаточное количество нововведений, не сильно удивил. Инструментарий для кодера остался на том же уровне. Потуги создать видимость деятельности за счет нового представления веток классов в Package Explorer, честно говоря, не впечатлили.

Однако, судя по многочисленным анонсам, светлое будущее уже настает, и это - Adobe Flash Builder "Burrito". Большинство анонсов этого продукта датируется октябрем прошлого года, а значит, за три месяца мексиканская шаурма уже достаточно подрумянилась, чтобы ее попробовать.

Пока нет разделения версий самостоятельного продукта и плагина для Eclipse. Есть просто ссылка для скачивания. Однако, в Release Notes, описание установки плагина Eclipse есть. Проверим позже.

Итак, качаем и ставим.

И вот у нас появилась в коллекции продуктов от Adobe папочка "Adobe Flash Builder Burrito". Действительно, release notes не обманули. Есть каталог "utilities", в котором лежит инсталлятор плагина Eclipse. Это уже хорошо.

Забавно, в меню "Пуск>Все программы" ярлык упал прямо в корень. Запуск. Нас сразу крупно оповестили, что: либо вводи серийник, либо 60 дней знакомься. Что ж, будем надеяться что за это время выпустят новую версию и продлят нам срок.

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

Кстати, как только я создал проект для Flax SDK 3.5 (ибо планирую еще как минимум год делать приложения под FP9.0), он уже содержал ошибку - не найдена локаль ru_RU. Достаточно в настройках компилятора заменить в строке дополнительных параметров -locale ru_RU на locale en_US.

А теперь - попробуем установить плагин Eclipse. Eclipse у меня последний на сегодня, 32-х битный, 3.6.1 Helios. Там же установлен Flex Builder 3 Plugin. Посмотрим заодно, как они подружатся.

Итак, находим инсталлятор плагина: C:\Program Files (x86)\Adobe\Adobe Flash Builder Burrito\utilities\FB_Burrito_Plugin_Utility.exe. Наученные опытом, выбираем английский язык.

Выбираем папку с Eclipse. По завершении процесса установки, следуем рекомендациям и делаем модификации в eclipse.ini:

-Xms256m

-Xmx512m

-XX:MaxPermSize=256m

-XX:PermSize=64m

Теперь смотрим. При запуске Eclipse получаем экран ошибок. Это наш Flex 3 дал о себе знать. Да, это была плохая идея. Увы, надо удалить Flex 3 и заново всё установить. В общем, совсем прощаемся с Flex3...

Итак, JRE переустановлено, Eclipse распакован, повторяю установку. Кстати, Eclipse по умолчанию руссифицирован. Кому такой расклад не привычен - меняем интерфейс на английский - добавляем в eclipse.ini:

-Duser.language=en

-Duser.country=US

(Спасибо 33 коровам! И, кстати это спасает проект от ошибки неверной локали).

Итак, у нас функционирует пробная 60-дневная версия Flash Builder Burrito. Работает пока нормально, сейчас ее поднастрою и попробую в деле.

* * *

Поработал на Burrito (Flex SDK 3.5). Нововведения пока не оказали значительного влияния на рабочий процесс. Столкнулся с несколькими глюками:

Старая болезнь билдера, когда при запуске дебага, процесс повисает на ожидании подключения к дебаггеру. Побеждается просто - поставить "Запуск от имени администратора" на эклипс, и, на всякий пожарный, на дебаговый FP.
Путаница при переименовывании классов. Сильно мешает при клонировании классов, когда копипастишь класс, потом его переименовываешь. Я так и не понял откуда растет баг, но раньше такого небыло.

Зато работа с темплейтами автокомплита кода порадовала. При работе в редакторе, нажимаем CTRL+SPACE+SPACE, и получаем варианты для быстрой вставки.

* * *

Серьезный баг, здорово мешает работе.

Если пользоваться автокомплитом (content assist) во flex-коде, довольно часто окно с выбором вариантов подвисает, затем подвисает и вся оболочка. Что бы вернуться к работе нужно закрыть Eclipse и снова запустить.

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

2010-11-07T18:28:00.003+03:00

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

Хочется просто обычный логгер - легкий и под всегда рукой.

Смотрим, что есть по этой теме в гугле.

Первое, на что я западаю - ThunderBolt AS3. AIR-приложение, которое заточено как раз под нашу задачу. Качаем, ставим, смотрим.

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

Местоположение лог-файла предлагается указать драг-дропом самого файла flashlog.txt прямо в приложение.

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

В общем - всё не супер.

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

Я работаю в основном на Flex Builder под Eclipse. Как хорошо было бы иметь под рукой логгер в виде плагина под эту чудесную платформу!

И, несомненно, таковой тут же нашелся: плагин для Eclipse: LogWatcher as a cross-platform Flash debugger in Eclipse.

Качаем, ставим согласно инструкции, смотрим.

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

Здесь можно подключиться и к другим логам, например, policyfiles.txt, что тоже может пригодиться.

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

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

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

2010-03-23T15:07:00.006+03:00

Сегодня столкнулся с проблемкой. Приложение посылает запрос на сервер, и сервер отвечает только заголовками (header), в моем случае - Location http://.....

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

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

Спасибо ему за это и низкий поклон.

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

2010-03-16T23:07:00.003+03:00

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

Поиск готовых решений не дал большого изобилия результатов. Да и не надо. Всего одна библиотека, которая попалась в наши сети превосходно решает нашу задачу:

The Graffiti AS3 Bitmap Drawing Library - отличный движок с открытым исходным кодом и примерами. Есть две версии - более старая 1.1 (для FP9+) и новая 2.5 (для FP10+). На странице проекта есть таблица сравнения возможностей версий.
Я выбираю версию 1.1, поскольку мой проект для FP9. Кстати, примеры на сайте представлены для более свежей версии, но принцип использования аналогичный, поэтому первый пример легко интуитивно подстроить под свои нужды.

Параллельно напал на интересные ресурсы:

µSprite AS3 Vector Editor - графический AIR-редактор с богатыми функциями, способный преобразовать нарисованное в код AS3/Haxe.
Pixlr photo editor - онлайновый графический редактор.
BitmapDataUnlimited - растр без ограничения геометрического размера.

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

2010-03-14T19:07:00.010+03:00

Сегодня займусь подбором хорошего инструмента для трансформации изображения.

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

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

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

Итак, для своей задачи, я уже выбрал себе движок от Senocular, поскольку мне нет необходимости трансформировать flex-компоненты - я буду работать исключительно с графикой. Поэтому, область графических трансформаций лучше убрать в чистый AS3-модуль и уже его вставлять во Flex в виде компонента, получающего извне данные и команды, и отдающего результирующий графический образ в виде BitmapData или контейнера с набором данных о графических объектах и их трансформациях.

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

2010-03-11T00:50:00.011+03:00

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

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

Нас интересуют наработки с открытым исходным кодом и желательно для Flex.

Итак, начинаем поиски.

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

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

Итак, моя задача состоит в интеграции листалки во Flex-проект. Соответственно есть два пути:

Непосредственно использовать библиотеку классов
Интегрировать готовое решение путем внедрения главного SWF-файла во Flex-приложение и каким-то косвенным путем управлять контентом страниц.

Я рассматриваю первый вариант и выбираю движок FlexBook от Ruben Swieringa. Всё. Буду докладывать с места событий.

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

2010-01-30T15:55:00.027+03:00

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

2010-01-06T22:05:00.000+03:00

Вступление.

Этот пост начал свое существование 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-разработка. Сотрудничество"

2009-10-14T16:44:00.003+04:00

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

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

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

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

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

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

2009-10-13T12:22:00.004+04:00

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

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

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

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

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

2009-10-05T10:26:00.006+04:00

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

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

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

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

2009-10-01T18:01:00.003+04:00

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

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

2009-07-28T13:28:00.013+04:00

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

Сразу хочу отметить полезный тул: 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 и утро испорчено

2009-07-27T09:39:00.011+04:00

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

Но тут мозг натыкается на незнакомые сочетания букв. Таак. Мифы 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

2009-06-04T19:26:00.005+04:00

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

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

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

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

2009-06-04T11:02:00.006+04:00

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

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

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

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

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

Code-behind или mx:Script?

2009-06-03T11:45:00.012+04:00

До некоторого времени, я выносил объемный 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 и спасение

2009-05-16T01:02:00.004+04:00

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

Приложение использует модули. Один из модулей содержит 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

2009-04-05T18:41:00.011+04:00

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

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

2009-03-22T17:55:00.006+03:00

Декларативность 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.

2009-03-19T18:48:00.007+03:00

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 тире после <!:

Для сравнения - обычный комментарий начинается с 2-х тире.

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

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

<?xml version="1.0"?>




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


<mx:Button id="myButton" label="This button has comment"/>



</mx:VBox>

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

Итог

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

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

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

2009-03-05T16:17:00.022+03:00

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

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

Перенос строки в строках MXML: символ  - мелочь, а приятно.
Загрузка сложных 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 марта!