Community

10 дней на Андроиде. День 8. Блеск и нищета native приложений

Чтобы эффективно использовать экосистему -- тот взаимосвязанный набор программного обеспечения, железа, сервисных приложений и инструментов, который мы именуем словом Андроид, полезно понимать преимущества и недостатки так называемых native, или в буквальном переводе "родных" приложений.

 

Общепринятое определение в данном контексте требует уточнения. Для мобильных платформ "родным" или native приложением считают такое, которое упаковано в уникальный для платформы формат, например apk в случае Android, и не предусматривает возможности запуска на другой платформе, даже если написано на кросс-платформенном языке программирования, например Java.

Как правило, альтернативой "родным" приложениям считают "веб" приложения, однако, строго говоря это не совсем правильно. Следует понимать что по определению веб-приложениями являются все те, которые используют веб-технологии, включая клиент-серверную модель взаимодействия с native клиентом.

Чтобы избежать терминологической путаницы, будем сравнивать native приложения с браузерными, в которых клиент сделан по технологии HTML/CSS/JS и работает в браузере вашего устройства. Нюансы, связанные с работой плагинов, оставим для отдельного исследования.

Нужно понимать, что существует класс native приложений, которые используют компонентные технологии таким образом, что фактически являются обертками для браузера. Яркий пример - Одноклассники.ру. Программа не делает практически ничего сама - просто открывает окно браузера, скрывая при этом URL. Достаточно наглядный пример смешения, которое уже произошло, и которое будет происходить все дальше и глубже с освоением разработчиками технологии HTML5 вообще и ее режима offline в частности.

Другой, гораздо более положительный пример native приложения, - Фейсбук. Он хоть и использует ленту в разметке очень близкой к HTML, причем с урезанными возможностями, тем не менее умеет отображать уведомления в строке статуса, интегрировать контакты и отправку новостей, работает с камерой и gps приемником. С другой стороны, его функциональность сильно проигрывает в той части, где в браузерной версии она хорошо развита. Например, для редактирования профиля вас просто отправят на сайт.

Что касается браузерных приложений, то очень интересным примером новых возможностей является Crome Web Store. Оказывается, поиграть в Angry Birfs вполне можно в оффлайне через Chrome. Познавательно также взглянуть на примеры от Mozilla. Не надо думать что это далекое завтра, - многие вещи уже работают в ваших смартфонах, к примеру новый native клиент Линкедин - не что иное как браузерная обертка типа Одноклассников, только сделана на высоком профессиональном уровне.

Итак, попробуем перечислить сильные и слабые стороны каждого подхода.

Характеристика
 Native
 Browser
Сферы преимущественного использования
 Игры, развлечения
 Социальные сети, шоппинг
Способы получения прибыли
 Продажа через маркеты, реклама
 Реклама, подписка
Реализация принципа "нескольких экранов" - работа с одними и теми же данными на ПК, планшете, смартфоне и даже телевизоре
С использованием облака, требует специальных усилий
 Автоматически - вся информация хранится в облаке
Доступ к аппаратуре
 Полный, посредством платформно-зависимых API
 Базовый, расширения HTML5 - в стадии стандартизации
Производительность
 Бескомпромиссная, возможность использования машинного кода для критических участков
 Ограниченная производительностью браузеров - интерпретаторов
Выразительные способности
 Неограниченные
 Как правило ограничены HTML/CSS, хотя HTML5 позволяет рисовать произвольную 2D/3D графику
Сегментирование внутри платформы
 Высокое, правильный подход требует от разработчика учета многообразия аппаратных конфигураций
 Низкое, как правило особенности аппаратуры абстрагируются на уровне браузера
Охват аудитории
 Средний. Необходимо разрабатывать две мобильных версии (iOS, Android) и одну настольную (Windows)
 Максимальный. Safari, Chrome, Mozilla, Opera перенесены на большинство современных платформ.
Стоимость разработки*
 Скорее высокая
 Скорее низкая
Стоимость сопровождения*
 Скорее высокая
 Скорее низкая
Время и сложность публикации изменений
 Высокие
 Низкие
ROI*
 Разработка дороже, но продажи и CTR выше
 Продажи ниже, но шире охват аудитории и динамичнее развитие
Активность пользователей*
 Пик в момент публикации, затем постепенно падает
 Растет с момента публикации
Чаще используемая модель разработки*
 Аутсорсинг
 Внутри компании
Способ кросс-платформенной разработки
 Использование кросс-платформенных инструментов наподобие MoSync, MobiAccess
 Оптимизация приложений под особенности браузеров вручную или с использованием appMobi, PhoneGap, appcelerator

*В оценках проще-сложнее, дороже-дешевле использованы материалы исследования Global Intelligence. http://www.globalintelligence.com/insights-analysis/white-papers/native-or-Web-application-how-best-to-deliver-cont

Наметилась тенденция "оборачивания" HTML5 приложения в обертку, превращающую его в native, и обеспечивающую переносимость ядра между платформами.

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

Мое личное мнение - не существует универсального решения. Большинство компаний выпускают продукты и в native, и в браузерном форматах. Тем более что надстройки-обертки во многих случаях позволяют на 80% использовать один и тот же HTML. Поэтому выбираем то, что нам удобно. Например Facebook удобно читать на http://m.facebook.com, но при этом полезно иметь установленное приложение, через которое можно публиковать фото, синхронизировать контакты и получать уведомления в строку статуса.

Celebrating diversity :)