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

    Сегодня нам бы хотелось немного рассказать о частном случае применения технологии 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, Михаил Стеценко. Удачи!
    Online Science Classroom
    0.00
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 37

      +1
      Adobe AIR технология идеально подходит для очень быстрого создания первой версии. Если приложение начало продаваться, тогда можно думать о других платформах.

      С другой стороны, если Вы можете реализовать программу на более «серьезной» платформе, то выбор очевиден.

        +2
        в общем случае, согласен
        хотя сложно себе представить, чтобы у ребят из Amanita Design не хватило денег на переработку Машинариума на другую технологию, когда он был в топе американского appStore
        таки нет, оставили на Flash :-)
          +2
          Работает? Не трогай!
          +1
          Для быстрого создания первой версии приложения на флэше подходит вот такой BaaS сервис. У них там есть SDK для Flex/Air клиентов и куча разных фич, в том числе запись/проигрывание медиа файлов с сервера.
          +2
          Пока не нашёл
          поэтому
          Грабли №


          Для ведущего аналитика Главного программиста Online Science Classroom у Вас просто изумительный подход к изучению платформы:)
            0
            в моём понимании, если технология не позволяет сделать нечто, что позволяют другие технологии — это её недостаток
            «пока не нашёл» — это просто уточнение, что вчера или сегодня утром могли дописать native extension для AIR SDK под iOS, которое позволяет определять аппаратные идентификаторы устройства, а я ещё не в курсе. Возможно, но очень маловероятно
              0
              во-первых, на iOS очень негативно относятся к определению каких-либо идентификаторов устройств, недавно вообще запретили приложениям запрашивать UIDID устройства (сделано специально чтобы не соотносили устройство с владельцем для безопасности)

              во-вторых, Вы говорите, что технология не позволяет сделать нечто, что позволяют другие технологии — но при этом даже не попытавшись разобраться, плюс имея Native Extensions Вы властны сделать всё то, что могут делать другие технологии на платформе. Тут больше вопрос Вашей лени как Ведущего программиста Online Science Classroom и нежеланию писать код:)
                –1
                тем не менее, все системы анализа статистики для iOS приложений эти идентификаторы используют — www.slideshare.net/Apps4All/2-2-05 (слайд 6) — это необходимо для расчёта эффективности рекламных компаний, знать, откуда пользователь пришёл
                и не вижу, какой от этого вред конкретному пользователю

                а написание кода — не самоцель, код решает конкретные задачи, имеющие цену (может быть будет точнее сказать, приносящие прибыль)
                писать самим Native Extensions для решения этой задачи просто нерентабельно, она того не стоит
                но если бы это был не flash, мы бы просто взяли готовую бесплатную SDK от Flurry и имели задачу решённой без дополнительных затрат
                это я и называю относительным недостатком технологии
                  +2
                    –3
                    конечно поверю, спасибо за ссылку, хотя уже видел
                    «Requirements – Adobe Air SDK 3.1 or later, XCode IDE, iOS SDK 5.0 or later, Android SDK 2.2 or later, Java SDK, Flurry Analytics iPhone SDK and Flurry Analytics Android SDK, Apache Ant»
                    увы, у нас вся фирма сидит под Windows, не в моих силах перейти на MacOS ради одной компоненты
                    а если попадётся ссылочка на определение Macadress или iOS advertiser identifier без XCode, буду просто счастлив

                    хотя, чует моё сердце, всё равно скоро не выдержу и пересажу разработчиков на маки, будем под XCode билдиться
                      0
                      Знаете, есть доля разумности в том, что разрабатывая под iOS имеет смысл иметь Mac:) С другими SDK Вам так же понадобился бы Mac для того, чтобы скомпилить приложение под iOS с Flurry.
                        0
                        согласен с Вами, это то, что мы сделаем в ближайшее время
            +2
            Спасибо Adobe Air за непрекращающийся праздник в отзывах.
              0
              да, под Android это реальная проблема
              наша служба поддержки уже вздрагивает, когда письма с Google Play приходят
              сколько не пиши в описании «Для приложения необходим Adobe Air 3.5+», не помогает :-(
              по-прежнему часть устройств, которые не поддерживают Air, видят это приложение
              удаляем из списка поддерживаемых устройств — появляются новые. чёртовы ох уж мне эти гуглофоны! :-)
              в этом случае нативная технология, на мой взгляд, более актуальна чем на iOS
                +1
                А как же captivate runtime? На Android можно так же как и под ios вшить рантайм в приложение!
                  0
                  Насколько я понял, речь о том, что часть девайсов (всё на ARMv6, например) AIR просто не поддерживает.
                    0
                    Я подумал про райнтайм, ориентируясь следующими словами автора:
                    наша служба поддержки уже вздрагивает, когда письма с Google Play приходят
                    сколько не пиши в описании «Для приложения необходим Adobe Air 3.5+», не помогает :-(

                    Возможно неправильно растолковал слова автора.
                      0
                      да, именно это и имел в виду. AIR вшить можно, но это ничего не даст
                      0
                      А с версии air 3.7 рантайм вшивается в любом случае.
                  0
                  А зачем нужна кнопка «закрыть приложение» в Андроиде? Корректное поведение это сохрание состаяние и остановка всех активных процессов (в первую очередь цикл отрисовки) при уходе Activity в бекраунд («onPause»).
                    0
                    просто возможность для пользователя завершить процесс приложения, если он хочет
                    В Adobe Air это реализовано через NativeApplication.exit, которое не работает под iOS и работает под Android
                    может не завершать, просто перевести в фоновый режим
                    Event.DEACTIVATE в таком случае, конечно, обрабатываем
                      +1
                      Насколько я помню, гайдлайны советуют этого не делать, что бы не давать пользователю ложное ощущения, что он должен сам заниматься закрыванием приложений.
                        0
                        так и есть, очень вероятно, что скоро откажемся от этой кнопочки
                        хотя некоторые приложения, в том числе Navitel Navigator for Android, до сих пор дают пользователю такую возможность. Может быть, просто инерция мышления разработчиков, привыкших к Windows
                          +2
                          Навигаторы — как раз один из немногих примеров, когда такая кнопка да имеет смысл — потому, как большинство навигаторов продолжают работать и выдавать голосовые инструкции даже когда их Activity не находится сверху. А приложения которым на фоне делать нечего, просто должны перестать жрать процессор и быть готовыми умереть в любой момент по требованию системы.
                            0
                            согласен
                    0
                    Эир хорош для всяких таких приложений, книжек и т.п. Но очень пх для динамичных игр. Плавали, знаем.
                      0
                      По поводу разного размера экрана устройств и векторной графики флеша.

                      1. Делаем всю графику в векторе. Меньший вес, возможность получить нужного качества BitmapData в рантайме.
                      2. При первой загрузке приложения запускаем кеширование под размер устройства. Для этого используем BitmapData.draw(object:DisplayObject):void.
                      3. Сохраняем все картинки на диск устройства. Сам не пробовал — но думаю тут проблем не должно быть.
                      4. Далее при последующих стартах приложения — грузим заранее подготовленную битмап графику. И рисуем ее либо через CPU или же через GPU.

                      Конечно для такого простого проекта как в данной статье — смысла нет так заморачиваться.

                      Кстати в Adobe Flash SC5.5 Появилась возможность при компиляции переводить выбранные MovieClip в битмап. Т.е. в редакторе вектор — компилируем — в SWF — а там битмап.

                      По поводу разных пропорций экрана — можно сделать умный скейл. Конечно придется ручками писать. Например для кнопок использовать aligment. А фон растягивать с помощью scale9grid.

                        +1
                        Мда… 55 долларов за обертку над API Facebook. Вот к чему приводят платные IDE.
                          0
                          Странная статья в общем-то. По факту было использовано все готовое и студенты второго курса, а автор в это время искал грабли :)

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

                          Решил посмотреть другие ваши приложения, но на установке приложения (микромир) аппарат завис). После перезагрузки я его запустил, в фоне это приложение потребляет до 25% CPU.

                            0
                            спасибо за обратную связь, нам очень важно мнение пользователей
                            видимо, речь идёт об Android-версии? что за баг со звуком? с какими кнопками сложности?
                            может быть, есть идеи по монетизации?
                            пишите сюда или на support@osc-apps.com, будем очень благодарны
                            увы, некоторые наши старые приложения не в лучшем состоянии, готовим апдейты по мере возможностей

                            по стилю статьи — согласен, слишком увлёкся метафорами и прочей красочностью, из-за этого видимо пострадала смысловая часть. Надеюсь, что-то полезное всё-таки удалось донести. Если ещё раз напинают за неудачный речевой оборот — перепишу в научном стиле, безлично и формально
                              0
                              Да, андроид, выдал, что мол неполадки со звуком диалог, хотя потом и работал. Кнопки лишь слегка подсвечиваются при нажатии, поэтому не очевидно, что произошло нажатие.
                            +2
                            > библиотечка ShineMP3Encoder, спасибо автору Gabriel
                            Bouvigne. Работает, правда, долго (грабли №1). Минутный трек кодируется секунд
                            15 на iPad3, к примеру.

                            Во-первых, это все равно быстрее реалтайма, а значит можно кодировать на лету.
                            Да, я в курсе что библиотека этого не умеет, так как сам ее потом патчил для
                            этого.
                            Но вы занимаетесь программированием или нажиманием в красивые кнопочки? Или код
                            на сишке слишком страшен?
                            Что же касаемо производительности, то библиотека портирована достаточно грубо,
                            есть чего оптимизировать.

                            > Не нравится — пишите encoder сами. Какие ещё сроки релиза?!

                            А какой енкодер? У меня ffmpeg по дефолту собран с 368 кодеками, и это без
                            всеми любимого mp3 и других распространенных енкодеров. Я бы очень хотел
                            посмотреть, как адоб добавляет поддержку codec2 или тому подобных вещей.

                            Не сочтите за грубость, но вы сами виноваты. Во флеше ЕСТЬ встроенные енкодеры,
                            к примеру всем набивший оскомину nellymoser, появившийся во флеше где-то около
                            2000 года. Но там он используется как компонент мультимедийного фреймверка и
                            закодированные пакеты сразу отправляются по RTMP. Вы же вышли за пределы
                            фреймверка, сочли что лучше знаете платформу — страдайте сами, раз такие умные.

                            Между прочим, то что вы имеете событие для получения несжатого звука — это
                            вообще нереально круто, до 10й версии вы и этого не могли получить.

                            > а для ВКонтакте нету — пишем сами

                            Ну все правильно. Мировые бренды имеют спрос, а мелкий сайтик-клон никому в
                            _мире_ не нужен. Вы бы еще хотели интеграцию с гостевушкой Васи Пупкина.

                            Между прочим, когда мне говорят о интеграции моего продукта в социальные сети,
                            то я или дропаю весь заказ, или заказчик убирает свои желания. Но это так, мои
                            особенности. Ну не люблю я ковырятся в говне, извините.

                            > сложно отследить факт установки нескольких наших приложений с одного
                            устройства и эффективность кросс-рекламы.

                            Генерируйте уникальные приложения. Безграничные возможности.

                            > Но есть небольшая сложность — ваше приложение запускается на устройствах с
                            разными характеристиками экрана

                            Эту проблему за вас решили еще лет 10 назад, если не больше. Вспомните телефоны
                            с поддержкой java, какие разные там были экраны! Да что экраны, там каждая
                            вторая клавиатура работала по своему. И ничего, делали таблицы для девайсов,
                            получали максимум инфы о телефоне и подставляли нужные данные. Все
                            работало. Может быть просто говно из купертино всех развратило?

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

                            > А как тормозит векторная анимация, это надо видеть

                            А еще надо представлять как работает векторная графика вообще.
                            Хоть на десктопе, хоть на мобилке. Именно за это флеш так и не любили, что
                            дизигнеры насуют 30 слоев вектора с 150% fps в настройках проекта, а потом
                            топовые машины дичайше тормозят от мелкого баннера.

                            И да, это не значит что векторная графика всегда тормозит. Я делал векторные
                            карты, вот уж где множество элементов в векторе — работало шустро, а все
                            благодаря кешированию.

                            > я уж молчу про blitting.

                            Если человек не знает что это такое, то ВОН ИЗ ГЕЙМДЕВА.

                            > то можно сделать базовый размер сцены под iPhone — 960 на 640, соответственно
                            получив вертикальные «уши» на iPad и горизонтальные на iPhone 5

                            Настройки сцены? Не, не слышали…
                            Зато придумали оригинальный костыль, молодцы. Бегом патентовать!

                            > C вами был главный программист Online Science Classroom

                            Наймите уже ПРОГРАМИСТА
                              0
                              А что за «говно из купертино»? Если это iPad, например, то в чём его «говённость»? Не продукт РОСНАНО, конечно, но вполне конкурентноспособен. Да, кстати, можно сказать, что я не знаю, что такое blitting — на практике не использую, но из геймдева не уйду и не просите. )
                                0
                                Если вы не знаете, что такое blitting, я бы посоветовал вам заниматься чем-то другим, кроме программирования, в геймдеве. Локализацией, например.
                                  0
                                  > А что за «говно из купертино»?

                                  Я про «ойфон», но и «япады» тоже не далеко ушли.
                                  Когда-то давно программисты писали код для разных телефонов, адаптировали
                                  написанное практически под каждый девайс. Где-то использовались проприетарные
                                  расширения, где-то свои особенные трюки и магия. К примеру, на некоторых
                                  девайсах надо было ОБЯЗАТЕЛЬНО выставить низкое энергопотребление GPS, дабы
                                  получить к нему доступ. На других девайсах нужно было дрючить подсветку 10 раз
                                  в секунду, дабы экран был яркий и не засыпал. Или, если девайс все равно
                                  засыпал, то на экран добавляли видеоплеер размером в 1 пиксель и крутили там
                                  черный ролик 32х32 пикселя. У каждого была своя ОС, свой набор железа, своя
                                  клавиатура и свои лампочки. И все это работало по-своему. Одни маппинги
                                  клавиатуры чего только стоят, многие уже наверное позабыли времена, когда жмешь
                                  вверх, а персонаж, к примеру, начинает стрелять или идет вниз. Обратишься порой
                                  к несуществующему классу — девайс эксепшена не покажет, он целиком
                                  перезагрузится. Делали целые анализаторы железа, дабы изучить начинку девайса
                                  максимально безопасным образом, а только потом непосредственно начать работу.

                                  вот тут пришел «ойфоня».
                                  Лейауты? ОЙ, ДА ОЙФОН ОДИН, РАЗМЕЧАЙ ПИКСЕЛЯМИ!
                                  Поддержка железа? ОЙ, ДА ЖЕЛЕЗО ВСЕ СТАНДАРТНОЕ!
                                  Клавиатура? ДА ТАМ НЕТУ КЛАВЫ, ВСЕ КЛЕВО!
                                  В результате новоявленные «розроботчики» считают, что существует только один
                                  экран, одна конфигурация железа и только один процессор, писать переносимо —
                                  это для них нонсенс, который не имеет смысла.

                                  И тут значит пришел поганенький Андроид.
                                  И сразу начались кучи проблем от поганенькой ОС.
                                  Где-то оно дико тормозит — виновата тормозная ОС, чего ж с опенсосу взять?
                                  Тут и китайцы, которые делают разное железо с разными кнопками — никаких
                                  стандартов!
                                  Да и размены экранов у всех разные!
                                  Ой, а некоторые девайсы вообще нельзя ни телефоном, ни планшетом назвать!
                                  НО МЫ ИМ ВСЕМ НЕСТАНДАРТНЫЕ ВЕЩИ ПООТКЛЮЧАЕМ! БУДУТ УВАЖАТЬ БРЕНДЫ И
                                  ПРОИЗВОДИТЕЛЯ СВОЕГО!

                                  Вот только не совсем ясно, что такие люди вообще делают в разработке софта и
                                  почему они не драют улицы.

                                  > blitting — на практике не использую, но из геймдева не уйду
                                  А я думал что времена векторной безтекстурной framestick-графики закончились годах в 80х.
                                    0
                                    Весёлая логика — устройства на iOS говно потому, что есть фрагментация на android. Остроумно :)
                                    Про 80-е не скажу, потому, что писать игры начал только в начале 90-х — для zx80 — организация видеопамяти там и без blitting была креативнее ваших сравнений платформ :)
                                0
                                как и обещал, переработал стилистику статьи, чтобы она меньше раздражала уважаемых читателей, особенно специалистов в области рассматриваемой технологии
                                а то уже и Apple досталось за компанию :-)

                                Only users with full accounts can post comments. Log in, please.