Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям

«Windows или Linux? iOS или Android? Какую систему предпочесть разработчику приложений?» — Подобные вопросы никогода не будут обсуждаться в постах блога Intel. Это непродуктивно, неэтично, да и вообще — оффтопик. Но есть одна тема, на первый взгляд «из той же серии», но на самом деле вполне достойная обсуждения. Именно поэтому я решила перевести статью о выборе между нативными и веб-приложениями, написанную Michael Mahemoff — бывшим сотрудником Google и основателем облачного сервиса подкастов player.fm ^[1]. Давайте поговорим об этом. Или, хотя бы, почитаем.

Когда я сообщил друзьям и коллегам, что Player FM в дополнение к браузерному веб-приложению скоро будет иметь нативное приложение под Андроид, они не сразу смогли уложить это в голове. Ведь я был известен не просто как сторонник веб приложений, но как сторонник очень горячий — «веб победит нативные приложения» — именно эту идею я отстаивал на конференции Google IO 2011 ^[2], поэтому люди, естественно, предполагали, что я не сменю свою точку зрения. Если уж не чистые мобильные веб-приложения, исполняемые в браузере, то, по крайней мере, это должны быть нативные приложения на основе HTML5.

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

Возможность действовать как агент, а не просто приложение

«Приложение» — это преуменьшение для многих программ, исполняемых сегодня на смартфонах. Подумайте о платежных системах, использующих geofencing ^[3], так, что вы можете совершать покупки, даже не дотрагиваясь до своего телефона. Утилиты для фитнеса, отслеживающие положение, автоматически делающие снимки, мониторящие ваш пульс без вмешательства пользователя. Агрегаторы, заранее загружающие медиа, предвидя запросы пользователя. Весь этот софт действует больше как интеллектуальные агенты, чем традиционные приложения. Они дополняют наши чувства и способности, используя железо, софт и облачные сервисы для предоставления нам «персонального ассистента» в режиме 24x7.
Этот класс приложений, естественно, вырастает из парадигмы нативных десктопных приложений, которые всегда использовали комбинацию фоновой обработки, механизма прерываний и прямого доступа к железу. По контрасту, парадигма веб-приложений — документо-центрична. Архетипичное веб приложение в основе визуально, находится в своей собственной песочнице и завершается, как только пользователь закрывает соответствующее окно браузера.
Превращение веб приложения в интеллектуального агента означает имплантацию всех этих новых возможностей в модель веб-документов, что более неопределенный процесс, чем, скажем, добавление нового меню или компонент канвы.
Chrome — единственный, перешедший с фоновых страниц к фоновым приложениям, а теперь и к пакетным (packaged) приложениям, ни одно из которых не совместимо с другими браузерами и ОС. Подобные «подковерные» функции несут в себе риск фрагментации, на борьбу с которой могут потребоваться годы упорного труда.

Доступ к многим «видам (поверхностям)» отображения

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

Отсутствие повсеместного доступа в Интернет

Печальная реальность: даже в 2013 мобильные приложения не могут просто предполагать, что они всегда будут в зоне быстрого интернета постоянного подключения. Это дает нативным приложениям естественное преимущество, так как они загружаются однажды и дальше работают в оффлайне. У современного веб стека также имеются оффлайн технологии, но они остаются незрелыми и сильно фрагментированными. Например, для сохранения самого приложения может использоваться App Cache API, но определение Jake Archibald «App Cache is a Douchebag ^[4]“ из одноименной статьи ^[5] — это справедливое описание текущей ситуации. Этот API, конечно, может работать — как показал Jake на примере поддерживающего оффлайн режим сайта Lanyrd, но все еще остается довольно проблематичным для веб коммьюнити, соответственно, планирующего пересмотр всей концепции ^[6].
Что же касается данных, то здесь имеется целый зоопарк возможностей и ни одного явного победителя. Веб-хранение данных просто в осуществлении и портировании, но имеет небольшой объем и временами бывает медленным. Веб SQL — известный, но не поддерживаемый Firefox и IE. Индексные базы данных поддерживаются бОльшим числом браузеров (по крайней мере, их последними версиями), но не работают на двух особенно важных: Safari и встроенным браузере Android. И это просто структурированные данные, а теперь представьте себе хранение объемных медиа файлов, — и вы попадете в мир проприетарных API с еще большей фрагментацией и полным отсутствием поддержки во многих браузерах.

Фоновое управление памятью.

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

Внешний вид

Известный аргумент HTML 5, а также HTML5 UI „написано один раз, работает повсеместно“ был более убедительным, когда у платформ еще не было сильной визуальной „персональности“. В те дни это было всего лишь принятие желаемого за действительное. Android, Windows и BlackBerry, не говоря про iOS, — это платформы с характерным внешним видом, имеющие взыскательных пользователей, которым действительно не наплевать на него. Поэтому, хотя HTML5 и помогает переиспользованию в некоторых областях (не забывайте про вышеупомянутые проблемы с фрагментацией), для создания отличного приложения пользовательские интерфейсы потребуют кастомизации.
При этом, неизбежно сохранение явных признаков, выдающих природу вашего приложения, а также значительное количество работы по оптимизации приложений, которой можно избежать в нативных платформах.

Доступность находимость для пользователей (discoverability)

Но довольно технических вопросов. Если что и имеет значение для большинства разработчиков, то это находимость приложений для пользователей. И эта медаль имеет две стороны. В пользу веб-приложений говорит то, что поисковики в Интернете — это величайший из когда-либо изобретенных, канал дистрибуции, что само по себе является хорошим аргументом за присутствие в сети. Кроме того, поделиться таким приложением элементарно — каждый может открыть URL на любом устройстве. Однако, пока поисковые машины не возьмутся всерьез за индексирование приложений, основной канал распространения — это магазины. А выпуск приложения имеет гораздо больший вес, чем факт, что какой-то веб-сайт вдруг стал мобильным. (В случае Player FM нам повезло получить обзоры от LifeHacker, Tested и других без малейшего нажима с нашей стороны, но очень трудно поверить в то, что даже интенсивное „размахивание флагами“ заставило бы их написать о том, что вебсайт случайного стартапа стал мобильным приложением.)
»Нативные приложения против веб-сервисов" -это не вопрос. Большинству сервисов требуются и нативные приложения и присутствие в сети. Настоящий же вопрос -это как построить эти нативные приложения? “HTML5-нативные” (с использованием PhoneGap ^[7]) против “чисто нативных”. Если у вас — специфический сервис, например, специализированное бизнес-приложение, то HTML5 может быть идеальным, удобным способом построить приложение быстро и обеспечить портируемость. Но если вы хотите действительно обеспечить отличные впечатления пользователей от вашего продукта, то нативные приложения пока еще правят бал.

Автор: vikky13

Источник ^[8]