Перевод

Настоящий доклад выпущен компанией Three Pillar Global и опубликован на её сайте.
Перевод мой.

Разработка мобильных приложений — ключевой компонент услуг, предоставляемых нашей компанией. Мы создаём как нативные, так и веб-приложения для нескольких крупных клиентов, таких как PBS и Carfax, а также других серьёзных издательских компаний. В настоящем отчёте рассматриваются различные факторы, которые необходимо учитывать при выборе мобильной стратегии, а также приводится ход наших рассуждений при принятии решений в работе с клиентами, перечисленными выше.

Для начала зададимся вопросом — почему вообще это имеет значение?

Для ответа необходимо взглянуть на мобильный рынок и фрагментацию устройств.

За последние 18 месяцев мобильный рынок быстро эволюционирует. В 2010 году (см. диаграмму ниже) рыночная доля RIM упала почти на 15%, в то время как Android поднялся с 5.2% до 28.7%. Впереди нас ждут ещё более кардинальные изменения, особенно, в связи с началом продаж iPhone крупнейшим коммуникационным ритейлером Verizon и недавним альянсом между Microsoft и Nokia.

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

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

В приведённой ниже таблице обсуждаются плюсы и минусы каждого подхода. Существует также гибридный подход — использование фреймворков вроде PhoneGap, которые позволяют выполнять приложения на HTML5/CSS3 внутри контейнера, представляющего собой нативное приложение. Такие решения также дают возможность доступа к аппаратным возможностям конкретных устройств с помощью HMTL5 и JavaScript. Мы исследовали этот подход и приняли решение не использовать его из-за проблем с быстродействием получающихся приложений. Кроме того, доступ к аппаратным возможностям (камера, акселерометр, геотаргетинг и т.д.) вскоре будет обеспечиваться и мобильными веб-браузерами. Тем не менее, существуют классы приложений, которые могут использовать гибридный подход, и при выборе мобильной стратегии необходимо рассматривать и его.

 

Нативное мобильное приложение

Мобильное веб-приложение

Охват

Мобильный рынок фрагментирован. Для того, чтобы охватить всех пользователей, необходимо создавать приложения для iPhone, Android, Blackberry, Symbian, Windows Phone. Это сопряжено со значительными издержками.
Наши клиенты приняли решение создавать приложения для устройств на базе iOS и Android, которые вместе составляют до 55% американского рынка мобильных устройств.

Мобильные веб-приложения имеют гораздо более широкий охват. Однако, рынок мобильных браузеров также фрагментирован, и существует более 60 различных версий браузеров. Использование платформ для разработки мобильных веб-приложений, таких как Sencha Touch, JQuery Mobile или Sproutcore, позволяет снизить необходимость проверки работоспособности приложения во всех браузерных движках.

Пользователь- ский интерфейс

Модель разработки нативных приложений предполагает более или менее единый подход к интерфейсу пользователя и обеспечивает комфортный и насыщенный user experience.

User experience веб-приложений обычно менее богат. Однако, мы использовали Sproutcore, мощный JavaScript-фреймворк, основанный на разработанной Apple платформе Cocoa. Sproutcore позволяет веб-приложениям выглядеть и управляться примерно так же, как десктоп-программы. Это достигается ценой сложных программных ухищрений, так что может страдать производительность приложения. Нам пришлось провести несколько оптимизаций, чтобы такие опции, как скроллинг, работали гладко и без задержек.

Доступ к аппаратным возможностям

В целом, если вам необходим доступ ко всем аппаратным функциям устройства, мобильное приложение — наилучший выбор. Помимо этого, производительность и экономичность расходования аккумулятора у нативных приложений гораздо выше.
В приложении для Carfax мы сканируем номерной знак машины с помощью Zbar, бесплатной библиотеки, обеспечивающей ввод с камеры устройства. Помимо этого, было необходимо обеспечить возможность ввода номера с клавиатуры. Поскольку номер содержит цифры и буквы, мы создали отдельную клавиатуру, чтобы пользователю не было необходимости переключаться между режимами работы стандартной клавиатуры. Таким образом, в данном случае нативное приложение — наилучший выбор.

В спецификацию HTML5 входит API для геотаргетинга. Однако, доступ к камере или акселерометру не предусмотрен. Впрочем, ситуация меняется, и через 1-2 года веб-приложения, скорее всего, получат доступ ко всем аппаратным функциям.
Для разработки издательских приложений мы решили использовать мобильный веб. Таким приложениям не нужны камера, акселерометр и другие аппаратные функции.

Поддержка

Для обновления нативного приложения необходимо заново пройти процедуру принятия его в App Store, а затем заставить пользователя загрузить новую версию. Из-за этого может возникнуть необходимость поддержки нескольких версий приложения.

Обновления веб-сайта вступают в силу немедленно после внесения изменений.

Фрагментация

Причина фрагментации — различия в аппаратных параметрах мобильных устройств, а также в операционных системах и даже в различных версиях одной и той же OS. Разработчикам нативных приложений необходимо обеспечить работу приложения на всех поддерживаемых устройствах и платформах, а в отсутствие определённых возможностей у конкретного устройства или платформы приложение, тем не менее, должно работать, пусть и в ограниченном варианте.
В случае PBS нам пришлось разрабатывать iPad-приложение, позволяющее пользователю просматривать (частично или полностью) видео на устройстве. Приложение также определяло ближайшую станцию телевещания на основе геотаргетинга. Поскольку целью разработки был iPad, мы решили создать нативное приложение. Случай с Carfax оказался более сложным — была необходима поддержка Android и iPhone и нескольких форм-факторов и версий каждой платформы. Кроме того, для сканирования номеров был нужен непрерывный автофокус камеры, более того — мы намеревались использовать вспышку. Поэтому мы разработали нативное приложение. Первоначально приложение проверяло, поддерживает ли камера непрерывный автофокус и есть ли вспышка. Если непрерывный автофокус не поддерживался, кнопка сканирования отключалась. Если вспышки не было, отключалась кнопка управления вспышкой. Однако, огромное разнообразие устройств на этих платформах сделали тестирование совместимости очень сложным процессом.

Хотя для мобильных браузеров фрагментация также характерна, почти 85% браузеров для смартфонов используют Webkit, открытый движок, применяемый в устройствах на базе Android, iOS, Symbian и BlackBerry. Единственные браузеры, не имеющие в основе Webkit, — Opera и Mozilla.
Однако производители могут разрабатывать для своих устройств собственные браузеры, основанные на модифицированном Webkit. В результате Webkit-браузеры отличаются друг от друга, поэтому веб-приложения приходится тестировать для всех возможных комбинаций OS/браузер. Как было сказано выше, использование готовых программных библиотек, проверенных и работающих в большинстве браузеров, снижает необходимость в широком тестировании.

Производи- тельность

Нативные приложения оптимизированы под архитектуру устройства и используют аппаратное ускорение. Для таких приложений, как игры со сложной 2D- и 3D-графикой или с высоким уровнем интерактивности, нативное приложение — единственный вариант.

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

Расходы на разработку

Опытные разработчики нативных приложений сейчас пользуются большим спросом, что повышает расходы на разработку. Кроме того, различные мобильные платформы имеют совершенно разные программные модели и API. Поэтому необходимо разрабатывать (и поддерживать) отдельные приложения для каждой OS (и даже для разных версий одной и той же OS). Это приводит к существенному росту затрат.

Разработчики веб-приложений встречаются гораздо чаще. Однако, как было сказано выше, для создания богатого user interface мы использовали Sproutcore, мощный, но сложный фреймворк. Мы решили пожертвовать лёгкостью разработки ради совершенства интерфейса.

Монетизация

Нативные приложения могут использовать платёжные механизмы, предоставляемые апп-стором. Однако, доходом придётся делиться с владельцем магазина. Например, Apple забирает себе 30% продажной стоимости приложения.

Веб-приложения могут использовать собственные платёжные системы. Это особенно полезно для приложений, основанных на подписке, издатели которых которые уже располагают платёжной инфраструктурой и не хотят делиться доходами.
По этой причине наши клиенты-издатели решили создавать мобильные веб-приложения, предоставляющие им полный контроль над дистрибьюцией и стоимостью подписки.

Мы перечислили факторы, оказывающие влияние на решение о выборе мобильной стратегии для той или иной организации. Важно отметить, что два рассмотренных подхода не являются взаимоисключающими. Например, организация может начать с нативного приложения, охватывающего большинство пользователей (например, для iOS и Android), а затем создать мобильное веб-приложение — для пользователей других устройств.

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

Фото в начале статьи: Mobile by Martin Taylor.

 
 
 
Рейтинг
(1 голос)
Последнее изменение: 6 мая 2011 года
 
 

0 нет комментариев добавить свой

Прокомментировать

Поля, отмеченные (*) обязательны для заполнения.

Отвечая на новость об уходе Стива Балмера с поста директора Microsoft, Кевин Келлехер рассуждает о разных подходах к оценке роли Балмера в достижениях и неудачах Microsoft и о том, какой компания может стать без него.

Десять коротких правил, изложенных Элмором Леонардом в статье в New York Times от 16 июля 2001 года. Позже они были изданы отдельной книжечкой.

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

Максим Зубов подсказал инфографику, выложенную на imgur.com. Автора не знаю, к сожалению. Тема — респонсив-дизайн и почему это так здорово. Я перевёл и выложил.

Джон Митчелл, редактор сайта ReadWrite, делится рекомендациями по устранению вредных технологических привычек. Считаю его «зароки» крайне разумными и полезными. Статья в моем переводе.

Общемировые продажи планшетов бьют все рекорды. Это наверняка станет хорошей новостью для издателей и производителей контента. Статья Хеймиша Маккензи (PandoDaily) в моем переводе.

В своем посте на блоге Reuters Феликс Салмон отстаивает ту точку зрения, что привязка контента к тому или иному устройству или платформе — неправильный и малоэффективный подход. Читайте статью Феликса в моем переводе.

Будущее веба — в респонсив-дизайне и адаптивных веб-приложениях. Я написал об этом три дня назад, а сегодня наткнулся на колонку Игоря Фалецки на Forbes.com, где он говорит о том же и почти теми же словами. Не удержался и опубликовал его статью здесь. Перевод мой.

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

Пейволл сегодняшнего дня — это не барьер и не стена, а скорее, пропуск к дополнительному комфорту и легкости потребления контента на всех платформах и устройствах. Статья Хеймиша МакКензи (Pando Daily) в моем переводе.

За исключением контента, права на которые принадлежат другим авторам, материалы этого сайта распространяется по лицензии Creative Commons.

НЕМНОГО ОБО МНЕ

Я Александр Шнайдер, управляю сложными проектами в области цифровых медиа.

Узнайте обо мне подробнее или напишите мне.