This post is also available in: Английский
Выбор технологии разработки должен основываться на множестве факторов. Одним из важнейших показателей является стоимость разработки и дальнейшей поддержки. Наш опыт показывает что до определенного уровня сложности приложения использование Adobe AIR экономически более выгодно. После определенного уровня сложности стоимость разработки и поддержания приложения на базе Adobe AIR становится сопоставима и даже больше, чем разработка отдельных Native приложений. Связано это с рядом причин среди которых: ограничения рантайма, отсутствие доступа к части системного API (необходимость разрабатывать Native Extensions, что требует хорошего уровня Native разработки, т.е. опять нужны опытные Native разработчики), ошибки рантайма (которые не всегда можно обойти при помощи Native Extensions), различия в работе рантайма в разных платформах.
В своих проектах мы используем оба подхода. На мой взгляд оба подхода весьма интересны и дают возможность достичь качественного результата. Впрочем обратное тоже верно, разработать приложение плохо можно также при помощи любой технологии. Чтобы не ограничивать разработчиков видео сервисов Adobe решили в новом релизе Adobe Access 4.0 выпустить Native версии библиотек для работы с защищенным контентом в iOS и Android. Тем не менее работать с видео значительно проще в стандартном Flash окружении, где доступен очень функциональный OSMF фреймворк и отлажены механизмы работы с мультимедиа контентом, выстроена стройная архитектура. В случае реализации видео приложения на базе AIR Вам скорее всего не удастся избежать необходимости использования Native Extensions. Они необходимы для снятия ограничения рантайма, а иногда даже исправления некоторых его недочетов. Также Native Extensions вполне можно использовать для оптимизации производительности приложения (хотя требуется это крайне редко).
Использование механизма Native Extensions несет в себе некоторые сложности, по крайней мере вначале. Прежде всего сборка Native Extension’а и проекта, его использующего — далеко не тривиальная задача. Этот процесс включает в себя компиляцию Native кода, разархивацию Flash библиотеки (SWC), подстановку множества путей, сборку новой Flash библиотеки с встроенным Native кодом, ручную правку XML метаданных приложения в манифесте. Кроме того, все эти действия нужно делать вручную, т.к. на данный момент никакой интеграции с Flash Builder нет (и нет информации о том, что это когда-нибудь будет). Поэтому сразу стоит подготовить набор скриптов для очистки проекта и сборки Native Extension.
Для себя я сделал два скрипта: очистки проекта (clean.sh) и сборки (compile.sh), использующие единый скрипт конфигурации (config.sh) с путями.
Пример config.sh
1 2 3 4 5 6 7 8 9 | #!/bin/bash adt_directory=/Applications/Adobe\ Flash\ Builder\ 4.6/sdks/4.6.0/bin root_directory=~/Documents/DENIVIP\ Media/Project_Directory library_directory=${root_directory}/AndroidANELib native_directory=${root_directory}/Android/bin signing_options="-storetype PKCS12 -keystore ./keyfile.p12" dest_ANE=InAppANE.ane extension_XML=${library_directory}/src/extension.xml library_SWC=${library_directory}/bin/InAppANELibrary.swc |
Пример compile.sh
1 2 3 4 5 | #!/bin/bash source "config.sh" unzip "${library_directory}/bin/InAppANELibrary.swc" -d "${library_directory}/bin" cp "${library_directory}/bin/library.swf" "${native_directory}/library.swf" "${adt_directory}"/adt -package ${signing_options} -target ane "${dest_ANE}" "${extension_XML}" -swc "${library_SWC}" -platform Android-ARM -C "${native_directory}" . |
Пример clean.sh
1 2 3 4 5 6 | #!/bin/bash source "config.sh" rm "${library_directory}/bin/catalog.xml" rm "${library_directory}/bin/library.swf" rm "${native_directory}/library.swf" rm "${native_directory}/InAppPurchaseANE.jar" |
Использование Native Extensions требует хорошего понимания архитектуры Native приложений. Если Вы используете Android Native Extensions, то без общих знаний по архитектуре приложений под ОС Android и их взаимодействия будет очень сложно. Начать изучение стоит с официальной документации и внимательно изучить принципы работы Activity, Intent, Receiver, Service. Взаимодействие с системными ресурсами требует от приложения специальных разрешений (permission), возможности принимать intent в сервисе (service) и прочее. Аналогичное верно и для iOS приложений.
Далее приведен список наиболее полезных на наш взгляд Native Extensions для AIR приложений под Android
- Системный регулятор громкости (Volume ANE) — очень полезная штука, т.к. AIR управляет лишь относительной громкостью внутри видео плеера.
- Интерфейс взаимодействия с InApp Purchase механизмом (InApp Purchase ANE) — нужен в случае необходимости поддержки возможности оплаты из приложения (разовые покупки, подписки)
- Интерфейс с сервисом push уведомлений (C2DM service ANE) — нужен для отправки сообщений в приложение при помощи C2DM сервиса
- Интерфейс для взаимодействия с системными уведомлениями (Notifications ANE) — необходимо для вывода системных уведомлений
Список полезных Native Extensions на странице Adobe.
Создавая видео сервис под мобильные устройства также следует уделить приличное количество времени оптимизации видео контента (того, для чего все затевается). Ресурсы мобильных приложений ограничены по сравнению с персональными компьютерами и для достижения оптимального восприятия сервиса пользователями необходимо следовать некоторым правилам подготовки видео контента. В Интернете много ресурсов по оптимизации видео под мобильные устройства. Недавно на сайте Adobe Developers Connection был опубликован замечательный мануал от Maxim’а Levkov’а на тему оптимизации видео под iOS устройства. Аналогичный мануал по оптимизации видео под Android.
В одной из ближайших статей мы рассмотрим вопросы оптимизации Android приложений на базе AIR технологии. Оставайтесь на связи!