Pull to refresh

Кроссплатформенная разработка на Adobe Air: частный случай

Reading time 3 min
Views 27K
Сегодня нам бы хотелось немного рассказать о частном случае применения технологии flash в версии Adobe Flash CS6 + Adobe Air SDK 3.5 для разработки iOS/Adnroid приложения, описанного в нашем предыдущем посте.
image

С технической точки зрения, это приложение воспроизводит набор звуков, анимаций, управляемых акселерометром, позволяет сохранять записанный звук. Позволяет совершать запросы к API распространённых социальных сетей — например, «написать о приложении на стене» (поскольку приложение на русском языке, нас в первую очередь интересовали Facebook и Вконтакте), и сохранять информацию о действиях пользователя в приложении в базу данных. Поддерживает встроенные покупки в App Store и Google Play.

image

Технология Adobe Air позволяет различными средствами реализовать все описанные выше функции.

Подгрузка и воспроизведение mp3-файлов — с помощью средств пакета flash.media.
Анимации с акселерометром — с помощью пакета flash.sensors.Accelerometer.

image

При записи и сохранении звука мы столкнулись с тем, что класс Microphone от Adobe Air возвращает в SampleDataEvent сырые данные. Получается 6 Мб в минуту. Для их кодирования можно использовать библиотеку ShineMP3Encoder (автор Gabriel Bouvigne). Работает, правда, долго. Минутный трек кодируется секунд 15 на iPad3, к примеру.

image

А вот на Android производительность вполне приличная.

Все крупные социальные сети предоставляет разработчикам библиотеки для работы с их API. Чаще всего они написаны на нативе. К счастью, во flash существует механизм native extensions, расширяющий функциональность Adobe Air за счёт подключения компонент, написанных не на as3.

image

Их можно купить в разных местах, в том числе прямо у Adobe для некоторых задач. Например, для Facebook такая компонента есть,

image

а для ВКонтакте нет, очевидно вследствие его малоизвестности за пределами России.

image

Встроенные покупки есть, а определение device id или Mac устройств, которые зачастую используются как идентификатор пользователя в системе сбора статистики, нет. Эту функциональность необходимо реализовывать самостоятельно с помощью механизма Native Extension.

Несколько слов о качестве графики.
Интуитивно понятно, что идеальное качество графики будет, если разрешение растровой картинки совпадает с разрешением экрана устройства. Но есть сложность — приложение запускается на устройствах с разными характеристиками экрана. Для iOS ещё можно сделать наборы картинок и подставлять их в зависимости от типа устройства (ну, 5-6 наборов картинок). Конечно, это утяжеляет приложение. Ещё сложнее дело обстоит с многообразными устройствами на базе Android. Эта проблема и способы её решения прекрасно известна разработчикам iOS/Android, можно упомянуть только о специфическом для Adobe Air способе решения.

Adobe Flash — мощный редактор векторной графики. Можно было бы предположить, что отрисованный во Flash вектор корректно отмасштабируется на любой размер экрана, но увы, качество графики оставляет желать лучшего. Да и с нагрузкой на процессор от векторной анимации бывают сложности. Эмпирическим путём установлено, что импорт растровой графики с настройкой Allow Smoothing даёт оптимальный результат. Действительно, Adobe Air сглаживает с приличным качеством, и не нужно 5 наборов картинок. Не забываем выставить Resolution High в настройках публикации проекта.

image

Как это ни странно звучит, в этом случае приходится рисовать в векторном редакторе графику, потом её растеризовать и импортировать обратно. Вообще Adobe Flash предоставляет ряд механизмов обеспечения процесса растеризации, начиная со Sprite Sheets и заканчивая blitting.

Несколько слов про размеры сцены для iOS. Если нецелесообразно кастомизировать интерфейс отдельно для iPhone и iPad, можно сделать базовый размер сцены под iPhone — 960 на 640, соответственно получив вертикальные «уши» на iPad и горизонтальные на iPhone 5 (при Aspect Ratio Landscape, конечно). Для Android с его безумным многообразием устройств оптимальный размер сцены выбрать настолько сложно, что можно оставить 960 на 640, хотя это, видимо, не оптимальное соотношение высота/ширина экрана для Android-устройств.

image

В этом приложении не было больших анимаций и видео, поэтому с оптимизацией быстродействия воевать не пришлось.

Приложение, о котором шла речь, было реализовано одним программистом за две рабочие недели (программная часть). 4088 строчек кода на as3. Анимации рисовали дольше. И портировано на Android за пару часов — добавили кнопку «закрыть приложение», для которой в iOS нет места, перебили ссылки, поменяли интерфейс встроенных платежей и настройки публикации.

image image

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

Будем благодарны за любую конструктивную критику и хорошие идеи.
C вами был главный программист Online Science Classroom, Михаил Стеценко. Удачи!
Tags:
Hubs:
+22
Comments 37
Comments Comments 37

Articles

Information

Website
osc-apps.com
Registered
Employees
Unknown
Location
Россия