Разработка под iOS: Создание Certificate и Provisioning файлов в Windows
Отличный скринкаст о создании файлов Certificate и Provisioning в Windows. Эти файлы необходимы для разработки мобильных приложений для iPhone, iPad, iPod Touch, в том числе Air приложений, которые мы пишем с помощью Flash Professional CS5 или Flash Builder 4.Ссылка:
Developing iOS Applications on Windows
Learn how to set up your development environment to build iOS apps on Windows.
Вместе с автором видео мы за несколько минут получим на руки файлы, необходимые для разработки приложения. Подробно показаны все шаги: установка на компьютер программы OpenSSL и работа с ней, заполнение всех форм на сайте в разделе iOS Provisioning Portal, создание тестового приложения и его запуск на реальном устройстве.
Разумеется всю эту информацию можно прочитать на сайте Adobe Flash Platform. Более того, эти страницы фигурируют в самом видео. Но тут уж кому как больше нравится.
P.S.
Не перестаю мысленно и вслух благодарить тов. SeeD'а всякий раз, когда вспоминаю свои первые шаги в разработке AIR приложений под iOS.
- +12
- Zebestov
Комментарии (37)
Хоть насколько высок спрос, конкуренция, конверсия, какие есть сложности, нюансы?
Вот читал недавно, что Андроид маркет дает в 10 меньше денег чем iTunes.
Никаких сложностей в продажах нет. Одна трудность — это правильно писать код, чтоб он был оптимизирован и не разбрасываться ресурсами, как это любят делать рисовальщики баннеров, где 240х400 баннеры жрут 50% компа и содержат в себе 2000х2000 джепеги ))))
Пропихивать как посоветуете? Я планирую создать сетку из нескольких игр и приложений которые друг друга продвигают. Ну и, конечно, реклама, блоги, форумы, социалки.
Т.е. iPad1, iPad2, iPad3, iPhone 3gs, iPhone 4, 4s и какие-то iPod touch не помню именно )
Версия прошивки не ниже 4.0 но желательно не ниже 4.3 для новых версий Air
На сегодня официально доступна Air 3.2 которая поддерживает Direct ускорение что дает возможность юзать 3D
В среднем для iOS чтоб писать — надо много research делать :) Я этим занимался около полу года )
А на деле всё равно на чем делать. Главное в конце получить swf файл который скормлен должен быть ADT упаковщику, который сделает IPA файл для размещения на девайсе.
А что скачивать, где и для чего — я уже не буду рассказывать ) Тут стоит понимать много моментов. На это надо время…
Лично я уже делал in-app покупки, узнавалку UDID, работу с графическим процессором. Остается тому, кто будет делать — научиться собирать это всё дело ну и конечно же шарить в Objective-C надо )
А всякие Game Center и т.д. — работают нативно. Значит если флеш поддерживает нативные расширения то и сделать можно всё будет. Это сто процентов )
Вот немного платного.
Подойдет любая IDE, если хочется разбираться с adt. Если же хочется работать с расширениями в два клика, то пока вроде только Flash Builder так дружелюбен.
The Packager for iPhone compiles ActionScript 3.0 bytecode into native iPhone application code.
но это ни о чем не говорит — они как то конверят байт код в исполнимый бинарник — но внутри они могут просто встроить этот байткод+виртуальную машину которая его выполняет:
На Unity3D сделано более грамотно. Там этот «движок» занимает как-то 5-6 мб, что хорошо для производительности. И всё остальные DLL файлы (да да, именно наши знакомые PC *DLL) догружаются уже по мере загрузки движка. Что позволяет усилить производительность.
На Air сделано немного не так. Там Core так называемый занимает 10 мегабайт и всё что выше — это уже Ваше приложение. Но тоже ничего не мешает создать код игры и включить в Core, как обычно. А ресурсы делать внешними. Ведь приложения, где всего 1 файл 50 мегабайт — получит краш или дикие тормоза.
2. Нативные расширения есть не на любой вкус. Их вообще не так много, как хотелось бы. Но основные нужны они покрывают — покупка в игре, связь с фейсбуком, геймцентром, поп-ап уведомления.
3. Stage3D отлично работает 1 в 1 как родной 3D у девайса. Метод отображения Air точно такой же как и у Flash для 3D — пишется Direct, хотя есть CPU и GPU.
4. На практике свой убедился, что если много анимаций в мувиклипах, где есть вложенные слои в который Bitmaps в таймлайне двигаются — надо использовать GPU для быстрой работы.
Если приложение не игровое и не требует много графики — лучше всего CPU ставить. Пример — mp3 плеер, обработчик фото. Причем для обработки фото лучше всего использовать Native Extension и в него\из него работать с ByteArray. Всё же нативно фотки обрабатываются куда быстрее.
Если мы решили 3D делать, чем я сейчас занимаюсь, то ставим Direct. Сейчас прямо под Direct собрать из Flash CS5.5 нельзя, надо немного похитрить. Но в версии Flash CS6 это будет сделано.
Не знаю как в FB4.6, но во Flash CS5.5 можно наглядно смотреть своё приложение в работе прямо во флеше. Это сильно ускоряет разработку.
5.
Более 1000 спрайтов и 60 fps это правда. Даже 2000 спрайтов и 59 fps тоже правда. Но суть заключается в том, что эти спрайты размещаются на 3D в виде surfaces, по-этому с обычными MovieClip такое не получится. Если это 2D игра — можно использовать любой готовый для этого движок. К примеру Starling, Nd2d…
Учитывая тот факт, что 3D работает за счет аппаратного графического чипа — высвобождается основной процессор для физики. По-этому я, в качестве примера, скажу про Alternativa3D. У меня удалось собрать приложение с кубиками, где они падают, разваливаются и т.д. Отличная производительность, 100 000 полигонов из которых 4000 участвуют в физическом мире.
6.
Как уже писал выше — создается нативный исполняющий файл. Но в случае Air (Flash) — в нем встроен так же код приложения. Банально если смотреть hex редактором — можно найти для глаза знакомые abc исполняющие файлы.
В общем-то тема развивается. Я официально принимаю участие в бета тестировании новых версий Air и могу сказать, что в версии 3.4 будет просто провыв. Хотя он уже в 3.3 есть, но пока доступно для всех на скачивание в виде релиза — 3.2 которая начала поддерживать Stage3D
А не подскажешь как лучше оптимизировать под AIR 3.2 флексовсое приложение в котором будет анимация — TweenLite некоторого кол-ва растровых объектов (10-20 шт.)?
Если картинки не больше 2048х2048 то можно вообще не париться.
И TweenLite лучше заменить на TweenMax. Он почему-то живее работает.
Так же изучи вопрос cacheAsBitmapMatrix… Он позволяет не нагружая железяку — делать alpha, scale, rotate, skew и т.д. куда шустрее, чем без него )
Еще важный момент. Если картинки это jpeg (условно) и каждая по пол метра ( аля background ) клади их внешними файлами и загружай после загрузки приложения. Это серьезно сделает прирост к производительности.
Если у тебя эти картинки будут часто появляться — идеально не удалять их, чтоб не делать постоянно addChild, а исключать их из рендера (visible = false) и когда тебе будут снова нужны — просто делаешь им visible = true
Пример — слайд шоу. Чтоб каждый раз не грузить проц загрузкой, декодированием — ты просто делаешь visible = false и изображение не принимает участие в нагрузке графического процессора.
Так же можешь изучать вопрос Jpeg XR файлов ))) Но сразу говорю — мало что найдешь по инету. 8 из 10 человек даже не знают что это такое и для чего.
Этот формат позволяет загружаться в память девайса быстрее, шустрее декодируется и обрабатывается, чем png/jpeg
Но я не знаю что за приложение у тебя. Может это тебе предлагаю по воробьям из гаубицы стрелять, когда тебе и рогатка подойдет )
Можешь в приват мне написать со ссылкой на свое приложение. Я гляну и скажу норм будет рубить или надо оптимизировать.
Ну и еще — золотое правило. Если ты делаешь мультиэкранное приложение (под 480х320, 960х640, 1024х768, 2048х1536) то для каждого разрешения у тебя должна быть отдельная картинка. Или одна самая большая но ты её будешь через BitmapData резать на маленькую.
Надо избегать таких ошибок, как загрузка рисунка больше, чем экран устройства с последующим уменьшением. А то видел кучу проектов, где просят оптимизировать игру. Открываю — там графика персонажа примерно 2048х2048 и человек её масштабирует вниз до 256х256 при том, что еще ставит и allowSmoothing что дополнительно жрет ресурс и задают вопрос «почему оно тормозит» :) Я пытаюсь объяснить, что не надо так делать — на что слышу ответ типа «ну так на компе у меня же нормально всё» ))))
Спасибо!
Например, расширение которое шарит изображение хорошо работало когда собирал APK ANT`ом, но когда его же стал использовать через Flash Builder 4.6 с встроенным функционалом сборки расширений, то Gmal перестал аттачить картинку.
А главный облом, это с расширением лицензирования, создание которого подробно и пошагово описано на adobe.com. Оно у меня заработало, но когда выложил на маркет, то у части юзеров при покупке программы оно не срабатывало. Представляете каково это получать гневные письма кастомеров, комменты и наблюдать падение драгоценного рейтинга.
Пришлось оперативно делать обновление без этого расширения.
Относительно Андроида — пробуй собирать с включенным в проект runtime, вроде если его включаешь в рантайм (нативное расширение) то его не надо лицензировать.
А на счет in-app под андроид — тема не сильно развивается ибо приоритет на рынок iOS :)
10 будет движок занимать, остальное графика и звук. Но вообще, для очень жаждущих — можно стрипать файл компиляции. Но для этого надо много экспериментировать. Можно вырезать целые наборы библиотек. Я до 7 мегабайт опускал легко виртуальную машину
В мемориз )
По делу — C:\Program Files (x86)\Adobe\Adobe Flash CS5.5\AIR2.6\lib\aot вот тут лежит всё, чтоб вырезать ненужные части кода из приложения
К примеру можно вырезать midi фрейморв, геймцентер, адресную книгу, телефонию, видео, iAd и много другого говна. Но надо потом переподписывать приложение вручную )
короче говоря геммора много но он работает )