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

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

Понятие мобильного веб-приложения можно трактовать по-разному. Для одних это приложение, работающее в Web и спроектированное так, чтобы корректно отображаться на мобильном устройстве, а для других — это приложение, созданное специально для конкретной мобильной ОС, которое соединяется с Web для отправки и приема данных. Чтобы разграничить эти позиции, можно воспользоваться «шкалой» от стандартных до нативных веб-приложений. Если нативные работают со скоростью «железа», то гибридные и мобильные исполняются поверх дополнительных уровней, которые расходуют вычислительные ресурсы, снижая быстродействие устройства.

Введем понятия стандартных и быстрореагирующих приложений, а также «мобильного Web». Соответствующие технологии, а также их преимущества и недостатки весьма схожи, однако здесь перечислим их по отдельности, подчеркнув, что, в сущности, это разные решения. Некоторым пользователям и разработчикам нравится адаптивный интерфейс, тогда как другие отдают предпочтение специализированным приложениям для конкретных устройств. Мобильно-ориентированные веб-сайты (например, соответствующие варианты Facebook или Google Docs) обычно предлагают пользователю возможность доступа и к стандартной веб-версии. Стандартная программа на смартфоне, вероятнее всего, будет работать медленнее, но некоторые пользователи выберут именно ее, чтобы иметь доступ ко всем возможностям сайта.

Стандартные веб-приложения

Термином «веб-приложения» обозначаются приложения, рассчитанные на исполнение в браузерах для настольных компьютеров. Они также смогут работать на мобильных устройствах, если не полагаются на специфические технологии, отсутствующие на многих мобильных устройствах (например, Adobe Flash).

Адаптивный веб-интерфейс

Приложения с адаптивным веб-интерфейсом автоматически меняют его внешний вид в зависимости от размера устройства — чаще всего при этом используется технология CSS (cascading style sheets). Дизайн может быть выбран сервером при доставке приложения, изменен на уровне клиента либо обоими способами. Смысл в том, чтобы контент из одного и того же источника отображался по-разному в зависимости от особенностей конкретного устройства. Данный вариант применим как для мобильных веб-приложений, так и для исполняемых на других видах устройств — например, на игровых консолях и телевизорах.

 

Примеры мобильных приложений

Openbravo — система планирования ресурсов предприятия с открытым кодом, предлагаемая как в виде веб-приложения, так и в форме нативного для настольных компьютеров. Один из сегментов рынка Openbravo — розничная торговля, и для нее имеется пользовательский интерфейс кассового терминала, рассчитанный на доступ с мобильных устройств. Здесь применялся адаптивный принцип — приложение должно работать на любом устройстве, а сама разработка осуществлялась с помощью инструментальной среды Enyo. На рис. А (1) можно видеть окно при отображении на экране шириной больше 800 пикселов. На рис. А (2) — тот же интерфейс на более компактном устройстве. В последнем случае режим отображения можно изменить специальными жестами или угловыми клавишами.

Компания Ludei разрабатывает игры на HTML5, CSS и JavaScript. С помощью этих технологий создается стандартное веб-приложение, которое будет работать и на различных мобильных платформах — например, игра ibasket работает в браузерах, а также в iOS, Android, Chrome, Facebook и на планшетах Amazon. Созданная в Ludei платформа CocoonJS позволяет запускать JavaScript-приложения на мобильных устройствах в качестве нативных, вне браузера.

Рис. А. Интерфейс кассового терминала на фреймворке Enyo: окно браузера и экран мобильного устройства
Рис. А. Интерфейс кассового терминала на фреймворке Enyo: окно браузера и экран мобильного устройства
Рис. А. Интерфейс кассового терминала на фреймворке Enyo: окно браузера и экран мобильного устройства

 

Мобильный Web

Термин «мобильный Web» здесь используется для случаев, когда есть специальный сайт или онлайн-сервис для доставки контента на мобильные устройства. Обычно интерфейс при этом выглядит эффектнее и работает быстрее, чем адаптивный, так как элементы (клавиши, селекторы и текстовые поля) отображаются аналогично нативным. При данном подходе может понадобиться создать несколько вариантов одного и того же сайта.

Нативные приложения

Компании, разрабатывающие мобильные операционные системы, хотят появления как можно большего числа нативных приложений для их ОС, и такие приложения разрабатываются с помощью инструментария, рекомендованного соответствующим поставщиком: например, на Objective-C и Xcode — для iOS или на Java и Eclipse — для Anroid. Для каждой ОС обычно нужен отдельный проект нативного приложения, а для этого понадобится больше разработчиков. При сугубо нативном подходе приходится также иметь в виду, что в дополнение к существующим мобильным платформам постоянно появляются все новые.

Гибридные приложения

Гибридным является мобильное приложение, «упакованное» в нативную оболочку. Такие приложения, как и нативные, устанавливаются из онлайн-супермаркета и имеют доступ к тем же возможностям устройства, но разрабатываются они с помощью HTML5, CSS и JavaScript.

Технические факторы

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

Поддержка платформ и версий

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

Возможности устройства

Необходимо учесть, какие вам понадобятся функции устройства. Если приложению нужен доступ к камере, сканеру штрихкодов, файловой системе или периферийному Bluetooth-устройству, то лучше воспользоваться нативным или гибридным подходом. Новейшие браузеры поддерживают аппаратное ускорение векторной графики, но пока еще не могут в полной мере пользоваться собственными графическими возможностями устройства и другими функциями, доступными через нативный API.

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

У нативных приложений более функционально богатые и привлекательные пользовательские интерфейсы, быстрее реагирующие и более интерактивные, а у веб-приложений могут быть сложности с доступом к аппаратным функциям устройства. Гибридные приложения дают разработчику больше свободы, позволяя коду HTML обращаться к нативным API, но необходимость учета применения веб-технологий делает пользовательский интерфейс внешне не совсем соответствующим «родному».

Быстродействие

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

Обновления

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

Нетехнические факторы

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

Таблица 1. Критерии выбора между подходами — нативным, гибридным и Web
Таблица 1. Критерии выбора между подходами — нативным, гибридным и Web

 

Распространение

Мобильные приложения просто распространять, но трудно рекламировать — вне онлайн-супермаркета их найти нелегко, поэтому если нужно привлечь внимание пользователей, то предпочтительнее нативное или гибридное приложение. Когда вы ориентируетесь на потребителей или геймеров, можно сэкономить на маркетинге, если распространять приложение через онлайн-магазин соответствующей платформы. Тем не менее с ростом объема приложений в таких магазинах добиваться известности все сложнее. Если же приложение рассчитано на узкую аудиторию пользователей (например, служащих предприятия), то можно воспользоваться его частным магазином приложений. При этом следует учесть, что у общедоступных магазинов приложений есть свои ограничения, — скажем, нет возможности влиять на политику управления магазином.

Цикл согласования

Процесс создания мобильных приложений может конфликтовать с методологиями скорой (agile) разработки, подразумевающими частый выпуск обновлений и непрерывную обратную связь с пользователями. При выборе нативного или гибридного подхода нужно иметь в виду, что частью проекта разработки станет процесс согласования, а если отклонений не будет, то время на согласование обычно минимально. Ситуация также облегчается, если вы разрабатываете приложение только для какого-то конкретного смартфона или пользуетесь локальным магазином приложений предприятия.

Монетизация

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

Фреймворки

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

Таблица 2. Инструментальные среды для создания мобильных веб-приложений
Таблица 2. Инструментальные среды для создания мобильных веб-приложений

 

Нативные

Существуют фреймворки, позволяющие создавать приложения на языках и фреймворках веб-разработки и исполнять их на различных мобильных платформах в качестве нативных. В частности, Appcelerator Titanium позволяет создавать такие приложения на JavaScript, а Rhodes — на Ruby.

Гибридные

Для создания гибридных приложений шире всего применяется технология PhoneGap, позволяющая разрабатывать на HTML5 и соответствующих фреймворках. Можно также упомянуть фреймворк для создания пользовательских интерфейсов Sencha Touch, поддерживающий только iOS и Android, однако достаточно популярный среди разработчиков.

HTML5

При выборе фреймворка HTML5 для конкретного проекта, помимо определения круга поддерживаемых устройств, нужно протестировать каждую из доступных библиотек, чтобы воспользоваться оптимально отвечающей привычным вам методам разработки. Выбор фреймворков HTML5 довольно велик (табл. 2), и они будут совершенствоваться, получая новые возможности и поддержку все новых устройств. Но вместе с тем будет расти и объем кодовой базы фреймворков, что плохо скажется на их быстродействии и трафикоемкости. Для преодоления этих проблем будут применяться различные подходы, основанные на сегментировании специализации фреймворков. Например, фреймворк JQuery Mobile позволяет задействовать только те модули, которые нужны для конкретного проекта.

***

Сегодня рынок мобильных устройств — это фактически монополия платформ iOS и Android плюс незначительная доля Blackberry, Windows Phone и Symbian, но модели устройств уходят с рынка быстро, а аппаратные и программные технологии активно развиваются, стремительно изменяя ситуацию на рынке. Например, Firefox OS — эту платформу поддерживают крупные операторы сетей мобильной связи, а поскольку приложения для нее основаны на HTML5, то их ассортимент может вырасти достаточно быстро.

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

Итак, существует несколько видов мобильных приложений, но у большинства из них есть общая черта — использование HTML5. Сегодня эта технология становится стандартом веб-разработки, но до зрелости ей еще далеко. Возможно, «дежурным» инструментом создания мобильных веб-приложений HTML5 еще не стал, но похоже, осваивать его уже пора всем.

Николя Серрано, Хосуне Эрнантес, Горка Галлардо ({nserrano, jhernantes, ggallardo}@tecnun.es) — сотрудники университета Наварры (Испания).

Nicolas Serrano, Josune Hernantes, Gorka Gallardo, Mobile Web Apps, IEEE Software, September/October 2013, IEEE Computer Society. All rights reserved. Reprinted with permission.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF