Belarusian Adobe Flash Platform User Group

Сегодня мой последний рабочий день в компании Креатек, и в роли flash/flex разработчика.

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

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

Я давно поглядывал и пощупывал другие технологии: Java, Scala, Erlang. Они, как все новое, казались клевыми и манящими. Чему-то нашлось применение в текущей работе, чему-то нет.

Наконец, осенью я принял решение уйти от флэш платформы и заняться Scala или Erlang. И так уж вышло, что уход от флэш платформы значил и уход из Креатек. Ибо компании в первую очередь нужна поддержка уже готовых продуктов, нежели эксперименты с новыми технологиями.

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

И вот, наконец, я свободен :)

Чуть было не собрался переезжать в Питер, но нашлась для меня подходящая работа здесь, в Минске :) Я иду работать в компанию Diesel Puppet, которую основал мой друг -- Леша Логинов. В прошлом он тоже был флэш разработчиком :)

Компания молодая, лишь недавно стартовавшая. Занимается играми для мобильников и социальных сетей. Я там буду делать сервера для игр, преимущественно на Erlang. Разумеется, есть амбициозные планы захватить мир.

Вот это именно то, что мне надо:

• молодая комания, не закостеневшая в старых проектах и процессах
• амбициозные планы по захвату мира
• Erlang

А что касается этого блога, то сюда я больше не буду писать. Он весь посвящен флэш разработке. Поскольку я закрываю тему флэш разработки, то мне кажется правильным закрыть вместе с ней и этот блог. Я, конечно, буду и дальше писать, но уже о других технологиях и других инструментах. Писать буду в гуглоплюс и в свой новый блог yzh44yzh.metalkia.com.

Пасиб всем, с кем я работал :)

Привет всем, с кем я буду работать :)

Скорее всего это мой последний пост про флэш разработку :) Через 2 месяца я буду full time Erlang разработчиком, и мысли мои будут занимать сервера, базы данных, high load и тому подобные вещи. С флэшем я расстаюсь, скорее всего, навсегда. Но еще 2 месяца, пока я доделываю некоторые дела и передаю проекты, я флэш-разработчик :)

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

Вот об одной из проблем флэш плеера под линуксом и пойдет сейчас речь.

Когда наш ActionScript код пытается захватить веб-камеру и передать поток с нее на сервер через NetStream, флэш плеер должен запросить у пользователя разрешение. И для этого он показывает диалог "Enable camera/microphone access" с кнопочками "Allow" и "Deny".

С этим диалогом была давняя проблема под маком -- он не реагировал на нажатия на кнопочки мышью. Но реагировал на клавиатуру, так что можно было табом поставить фокус на кнопку, и пробелом ее нажать. Под маком Адоби, наверное, это пофиксили. А может и нет, я как-то не в курсе.

Под линуксом же диалог раньше работал нормально. Потом с какой-то версии стал тупить, не сразу срабатывать. А недавно (с 11-й версии), диалог вообще перестал реагировать и на мышь, и на клавиатуру. Так что стало невозможно пользоваться флэш приложением, если оно захватывает камеру. Ну и разрабатывать такие приложения тоже стало невозможно.

Мое нежелание провести эти последние два месяца под виндой вынудило меня искать выход. И выход был найден. Установить настройку через стандартный диалог флэш плеера невозможно, но можно изменить ее прямо в том месте, где она хранится. Если знать где. А я вот знаю :)

Нужно зайти в каталог ~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/. Там для каждого домена будут хранится отдельные настройки. Допустим, нас интересует localhost. Тогда открываем каким-нибудь hex-редактором (например, ghex2) файлик #localhost/settings.sol. Он небольшой, так что найти нужные места в нем не трудно, даже не зная формата AMF.

Находим байты 61 6C 6C 6F 77 -- это строка "allow". После нее идет 01 00. Меняем на 01 01. Дальше находим байты 61 6С 77 61 79 73 -- это строка "always". После нее тоже идет 01 00. Тоже меняем на 01 01. Это мы сейчас для двух свойств с именами "allow" и "always" поменяли значения с false на true.

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

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

До сих пор я всегда пользовался 32 разрядными дистрибутивами линуксов, ибо для 64 разрядных нет дебаг-версии флэш плеера. Релиз версия вроде бы есть, но проку от нее флэш разработчику мало. (А я так и остался флэш разработчиком, угу).

Но вот по недосмотру поставил 64 разрядную Убунту. Соотвественно, стандартная манипуляция:

• Download the Linux Flash Player XX.X Plugin content debugger;
• заспаковать tar;
• положить libflashplayer.so в ~/.mozilla/plugins;

не помогает.

Внезапно FF сам предложил установить флэш плагин, когда я открыл страничку с флэшевыми баннерами. Я удивился, но согласился :) И FF давай качать какие-то либы, запускать некий flash plugin installer производства Adobe (стремно было давать чему-то, сделанному в Adobe, рутовые права, но пришлось :) Ну и в итоге он поставил и попросился рестартануться. Рестартанул -- флэш работает, баннеры крутятся, мигают, вызывают омерзение, как им и положено :) Разумеется, работает релиз версия, не дебаг.

Полез глядеть, чего и куда он поставил. А получилось там такое: в папочке /usr/share/ubufox/plugins два симлинка:

libflashplayer.so -> /usr/lib/flashplugin-installer/libflashplayer.so
npwrapper.libflashplayer.so -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so

Ага, клева. Я смело и решительно подменил /usr/lib/flashplugin-installer/libflashplayer.so на дебаг-версию libflashplayer.so, рестартанул FF -- и вуаля, работает дебаг версия!

Flex пока еще не отпускает меня, и приходится с ним возиться. Для начала, надо отметить, что Flex фреймворк в целом хорошая штука. Местами даже изящная штука (это я следую американскому стилю, которому меня научил Яков Файн: сперва похвалить, потом поругать).

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

Давеча я убрал maven/flexmojos из своих проектов, и заменил их ручной конфигурацией проекта в IDEA и ant скриптами. Надо сказать, что так проще и лучше. Во всяком случае, для меня этот вариант явно комфортнее.

Теперь, в отличие от варианта c flexmojos, проект действительно легко подымается с нуля на машине нового разработчика, сразу собирается и запускается. Все swc зависимости лежат прямо в папке libs в самом проекте. А все настройки IDEA комитятся в репозиторий вместе с кодом проекта (ну почти все, кроме workspace.xml).

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

У нас есть ряд модулей (swc библиотек), которые написаны на чистом AS, не имеют никаких зависимостей от Flex SDK, и используются во многих проектах. Несмотря на то, что зависимостей нет, compc все равно старательно сует внутрь swc файла кучу классов из sdk. В результате модуль получается привязанный к конкретной версии sdk. И попытка использовать его в проекте с другим sdk может давать непредсказуемые эффекты, вплоть до того, что проект просто не соберется.

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

Я вот, в силу ограниченности моего интеллекта, в упор не понимаю, нахрена вообще нужно пихать классы из flex sdk внуть swc модуля. Пусть даже он имеет зависимости от них (а тем более, если не имеет).

Еще надо отметить, что mxmlc и compc имеют хренову тучу опций, большая часть из которых нафиг никому не нужна. А еще они имеют двойной синтаксис описания этих опций: в виде аргументов командной строки и в виде xml-узлов в flex-config файле. Разобраться со всей этой ботвой не просто.

Нужной опции -- не включать ничего лишнего, нет. Я не нашел. Поправьте меня, если я ошибаюсь. ИМХО, это и не опция должна быть, а поведение компилятора по умолчанию.

Ладно, опции нет, а flexmojos все-таки умеет это делать. Изучив flex-config файлы, которые генерирует flexmojos, я понял, в чем фишка. Нужно все зависимости, в т.ч. зависимости от flex sdk, подключать через external-library-path. И flex библиотеки тоже.

Однако вот еще нюанс: подключать нужно swc файлы, а библиотеки в составе flex sdk лежат в виде swz файлов. В виде swc файлов они есть в артефактах flexmojos. Оттуда я их и взял. Где еще их можно взять, не знаю. Разве что собрать самому из сорцов flex sdk. Видимо разработчики flexmojos так и делают.

В итоге получается такое:

	<exec executable="${compc}">
		<arg value="-debug=true"/>
		<arg value="-external-library-path=${libs}/playerglobal-11.swc"/>
		<arg value="-external-library-path=${libs}/framework-3.5.0.12683.swc"/>
		<arg value="-external-library-path=${libs}/flex-3.5.0.12683.swc"/>
		<arg value="-external-library-path=${libs}/Mate_09_1.swc"/>
		<arg value="-source-path=./src"/>
		<arg value="-include-classes"/>
		<arg value="com.flashdevs.yzh.log.Connector"/>
		<arg value="com.flashdevs.yzh.log.DebugConsoleLogTarget"/>
		<arg value="com.flashdevs.yzh.log.MateLogTarget"/>
		<arg value="-output"/>
		<arg value="${basedir}/../classes/debug-console-log-target.swc"/>
	</exec>

Подробнее тут.

В результате небольшой модуль из 3х классов превращается в аккуратный swc файл размером 5Kb, а не в монстра в 300Kb, которого не ко всякому проекту подключишь.

Ну и зависимости: playerglobal-11.swc, framework-3.5.0.12683.swc, flex-3.5.0.12683.swc, Mate_09_1.swc лежат в папочке libs внутри самого проекта.

Я, наконец, сделал это :)

btw, если вы знаете, как эта задача решается стандартными средствами, подскажите плз.

Ну вот дошли руки попробовать публикацию с кодеком H.264

Тема гуглится, но до конца, пошагово, нигде толком не описано. Поэтому пишу тут:

1. Скачать playerglobal.swc версии 11.0 тут http://www.adobe.com/support/flashplayer/downloads.html
   внизу страницы искать Download the playerglobal.swc to target the 11.1 APIs (.swc, .329KB)
2. Во Flex SDK создать папку frameworks/libs/player/11.0 и положить туда playerglobal.swc.
   (Изначально там есть только frameworks/libs/player/10.2/playerglobal.swc)
3. В настройках проекта подключить нужный Flex SDK и указать версию флэш плеера 11.0
4. Написать обычный код публикации, и кроме прочего, добавить в код
   

   
   var h264Settings : H264VideoStreamSettings = new H264VideoStreamSettings();
   h264Settings.setProfileLevel(H264Profile.BASELINE, H264Level.LEVEL_2);
   nsPublish.videoStreamSettings = h264Settings;
   

5. Добавить опцию компилятора -swf-version=13
   Коварный момент в том, что без этой опции все скомпилируется, но в рантайме выдаст ошибку:
   VerifyError: Error #1014: Class flash.media::H264VideoStreamSettings could not be found.

Фича работает и действительно дает лучше качество. Проверил на 4х медиа серверах: FMS, Wowza, Erlyvideo, Red5 -- работает везде.

Документация по H264VideoStreamSettings