Споры о мобильных приложениях
Введение
Мобильные приложения и HTML5 — две самые популярные технологии на данный момент, и они во многом совпадают. Веб-приложения запускаются в мобильных браузерах, а также могут быть переупакованы как собственные приложения на различных мобильных платформах. Благодаря широкому спектру поддерживаемых платформ в сочетании с мощью мобильных браузеров разработчики обращаются к HTML5 как к решению «напиши один, запусти много». Но действительно ли это жизнеспособно? По-прежнему существуют веские причины для перехода на нативную версию, и очевидно, что многие разработчики действительно идут по этому пути. Эта статья представляет собой дискуссию о нативном и веб-приложении.
Богатство функций
Суть: Native может больше.
Мы можем разделить мобильную функциональность на два измерения: восприятие самого приложения и способ его подключения к экосистеме устройства. Например, для Android это такие функции, как виджеты и уведомления. Native превосходен в обоих измерениях.
С точки зрения удобства использования нативные приложения могут больше. Они могут легко получить события смахивания, даже мультитач, для тех платформ, которые его поддерживают. Обычно они могут воздействовать на нажатие аппаратных клавиш, таких как кнопка поиска Android и регуляторы громкости. Они также могут получить доступ к оборудованию, например GPS и камере. А с разрешения пользователя некоторые платформы предоставляют беспрепятственный доступ к операционной системе. Просто попробуйте определить, сколько заряда осталось с помощью HTML5!
Однако это больше, чем просто опыт использования приложения. Операционная система, такая как Android, предоставляет приложениям различные способы взаимодействия с пользователями и другими приложениями. У вас есть активные виджеты на главной странице. У вас есть уведомления, которые отображаются в строке состояния устройства. И у вас есть намерения, которые позволяют вашему приложению объявлять себя предоставляющим общую услугу, которая иногда может потребоваться другим приложениям.
Контрапункт: встроенные функции могут быть расширены, и Интернет в любом случае догоняет их.
Это правда, что многие функции приложения просто недоступны для приложения HTML5. Независимо от того, насколько хороши ваши навыки веб-фу, если ваше приложение застряло в песочнице без API камеры, оно не будет делать снимки в ближайшее время! К счастью, вам не обязательно находиться в этой песочнице. Если вам действительно нужно ваше веб-приложение для фотографирования, вы можете создать собственное приложение со встроенным веб-представлением, которое обеспечивает большую часть пользовательского интерфейса. Именно так работает платформа PhoneGap с открытым исходным кодом: она заполняет пробел, предоставляя собственные функции в виде веб-сервисов, которые веб-представление вызывает с помощью стандартного сетевого API. Когда вы создаете подобное гибридное приложение, вы также можете подключиться к таким функциям платформы, как виджеты, уведомления и намерения.
Создание гибридного приложения, нативного и веб-приложения, вряд ли является идеальным решением. Это усложняет работу и применяется только к веб-приложениям, завернутым в нативные приложения, а не к традиционным веб-сайтам, доступным из мобильного браузера. Но, возможно, это понадобится ненадолго. Веб-стандарты быстро развиваются, и современные мобильные браузеры не отстают. Например, автономное хранилище, геолокация, графика на холсте и воспроизведение видео/аудио широко поддерживаются, например, среди современных смартфонов. Начинает поддерживаться даже камера — начиная с Android 3.1 можно снимать фотографии и видео с использованием веб-стандартов. А последняя версия браузера iOS поддерживает WebSocket для двусторонней потоковой передачи, а также определение ориентации устройства.
В целом мобильная связь развивается. Но Интернет также развивается, и быстро. Только среди настольных браузеров пять основных производителей браузеров развивают стандарты и добавляют функции молниеносными темпами. Хотя перенос этих функций на мобильные устройства — непростая задача, многие из них уже появились в мобильных браузерах.
Нативная технология — быстро меняющаяся цель, но веб сокращает разрыв.
Производительность
Точка: Native работает быстрее.
Нативные приложения не сталкиваются с барьерами времени выполнения в Интернете. Они работают практически идеально и могут воспользоваться преимуществами повышения производительности, такими как ускорение графического процессора и многопоточность.
Контрапункт: сегодня среда выполнения веб-страниц намного быстрее, а большинству приложений эта скорость все равно не нужна.
Было бы преуменьшением сказать, что в последние годы Интернет стал быстрее. V8, движок JavaScript, поставляемый с Chrome, на момент своего запуска стал крупным достижением в области веб-производительности, и с тех пор он стал только быстрее:
Механизмы графического рендеринга также ускорили работу Интернета, и теперь начинает происходить аппаратное ускорение. Взгляните на «лежачий полицейский», обеспечиваемый аппаратным ускорением холста:
Кроме того, новый API Web Workers делает возможным многопоточность, и современные веб-разработчики также могут использовать ряд библиотек, оптимизированных для производительности, и хорошо изученные методы оптимизации производительности. Хотя большинство из них начали свою жизнь в настольной сети, они по-прежнему актуальны для мобильных устройств, и мобильным устройствам уделяется повышенное внимание, например, у гуру производительности Стива Соудерса есть страница, посвященная инструментам повышения производительности мобильных устройств .
Пока еще не все достижения для настольных компьютеров доступны на всех мобильных платформах, но тенденции показывают, что они уже в пути. Также важно отметить, что большинство мобильных приложений не являются новейшими 3D-играми, а в основном основаны на информации: новости, почта, расписания, социальные сети и т. д. Посетите несколько сайтов со своего мобильного телефона, например GMail, Amazon, Twitter, и вы можете подтвердить, что производительность мобильного Интернета более чем адекватна. Что касается игр, то базовые из них уже реализуются с помощью 2D-холста, а WebGL начинает появляться на мобильных устройствах — см. Firefox 4. Пока он не получил широкого распространения, существует растущее семейство фреймворков, которые компилируют приложения WebGL в собственные приложения, которые могут использовать преимущества OpenGL. , например ImpactJS .
Опыт разработчика
Точка: Native легче разрабатывать.
В собственных приложениях используются надежные языки программирования (например, Java, Objective C, C++), которые были разработаны для разработки сложных приложений и имеют проверенную репутацию. API были разработаны с нуля для поддержки имеющейся платформы. Вы можете легко отлаживать приложения в эмуляторах настольных компьютеров, которые обеспечивают точное представление целевого устройства.
Что делает веб-разработку особенно трудной, так это огромное разнообразие браузеров и сред выполнения. Когда ваше приложение запускается, нет гарантии, что функция X будет доступна. И даже если это так, как браузер это реализует? Стандарты открыты для интерпретации.
Контрапункт: Интернет часто легче разрабатывать, особенно если он ориентирован на несколько устройств.
Давайте сначала займемся основной технологией. Это правда, что веб-стандарты изначально были задуманы в эпоху, когда в основе Интернета лежали документы, а не приложения, а JavaScript был создан и развернут всего за 10 дней! Но они оказались гораздо более способными, чем предполагалось: веб-разработчики научились использовать хорошие стороны и укрощать плохие, используя шаблоны, которые теперь понятны для масштабируемого дизайна. Более того, стандарты не стоят на месте, и такие усилия, как HTML5, CSS3 и EcmaScript Harmony, улучшают опыт разработчиков. Предпочитаете ли вы C++, Java или JavaScript, это вопрос религиозных дебатов, а также зависит от вашей устаревшей кодовой базы. Но в наши дни мы, безусловно, можем назвать JavaScript серьезным соперником.
Обратной стороной фрагментации браузера/среды выполнения является тот факт, что все эти среды вообще существуют. Разработайте приложение для Android на Java, и вы столкнетесь с полным портированием на Objective C для поддержки iOS. Разработайте веб-приложение один раз, и оно будет работать на Android и iOS, не говоря уже о WebOS, BlackBerry, Windows Mobile и… ну, в любом случае, это теория. На практике вам придется что-то настраивать для каждой платформы, если вы действительно хотите получить правильный опыт. Но вам придется сделать это и в нативной версии для большинства мобильных операционных систем — существуют разные версии и разные устройства.
Хорошей новостью является то, что «фрагментация» всегда была такой в сети, и существуют хорошо известные методы борьбы с ней. Самое главное, что принцип прогрессивного улучшения побуждает разработчиков сначала ориентироваться на базовое устройство и добавлять уровни специфичности для конкретной платформы там, где это возможно. Мантра обнаружения функций также помогает, и в наши дни у нас есть поддержка библиотек, таких как Modernizr , для поддержки адаптивного веб-дизайна. При разумном использовании этих методов вы сможете охватить подавляющее большинство устройств, даже устаревшие «функциональные телефоны», даже такие форм-факторы, как часы и телевизоры, независимо от марки и ОС. Посмотрите нашу демонстрацию мульти-UI на Google IO 2011, где мы ориентировались на различные форм-факторы (многофункциональный телефон, смартфон, планшет, настольный компьютер, телевизор) с общей кодовой базой логики и разметки.
Смотреть и чувствовать
Суть: Native соответствует внешнему виду платформы.
Одной из определяющих особенностей любой платформы является ее внешний вид. Пользователи ожидают, что элементы управления будут представлены последовательно и ими можно будет управлять одинаково. Существуют определенные идиомы, которые варьируются от платформы к платформе, например, что происходит, когда пользователь выполняет «длительное удержание» (продолжает касаться элемента в течение нескольких секунд)? Платформы имеют стандартные идиомы для таких вещей, и вы не можете удовлетворить их все с помощью одного приложения HTML5.
Кроме того, внешний вид платформы управляется собственной библиотекой программного обеспечения платформы, виджеты которой воплощают тот внешний вид, который ожидают пользователи. Вы получаете ожидаемый внешний вид «бесплатно», просто используя собственный набор инструментов.
Контрапункт: Интернет имеет свой собственный внешний вид, и вы также можете настроить веб-интерфейс для тех платформ, которые вам интересны больше всего.
Как объяснялось в предыдущем разделе, способ веб-разработки заключается в написании базовой версии, подходящей для всех, а затем ее постепенном улучшении. Хотя улучшение обычно основано на функциях, вы также можете улучшить его, ориентируясь на те платформы, которые вам интересны больше всего. Это своего рода «обнаружение браузера», которое иногда не одобряется веб-сообществом, главным образом потому, что существует очень много возможных браузеров. Но если вы просматриваете две или три платформы с очень высоким приоритетом и готовы приложить дополнительные усилия, чтобы противостоять нативным альтернативам, это может быть правильным решением.
Что касается базовой версии, Интернет имеет свой собственный внешний вид, и мы можем даже сказать, что каждая мобильная платформа имеет свой собственный «веб-стиль», установленный браузером по умолчанию и веб-средой выполнения. «Внешний вид веб-страницы» может подойти вашим пользователям и фактически позволяет вам достичь большей степени согласованности с работой браузера на настольном компьютере, а также с браузером на других устройствах, с которыми может работать пользователь. Более того, существует множество успешных приложений, которые в любом случае не поддерживают собственный внешний вид. Это, безусловно, верно в отношении игр (соответствует ли ваша любимая мобильная игра внешнему виду вашей мобильной ОС?) и даже в отношении более традиционных приложений, например, проверьте более популярные собственные клиенты Twitter на выбранной вами платформе, и вы увидите широкий спектр механизмов пользовательского интерфейса в работе.
Обнаруживаемость
Мысль: нативные приложения легче обнаружить.
Механизмы распространения приложений, такие как Android Market и Apple App Store, в последние годы пользуются огромной популярностью и являются основной движущей силой всей мобильной индустрии. Любой разработчик может отправить свое собственное приложение на рынок, где пользователи смогут найти его с помощью просмотра, поиска и получения рекомендаций. Более того, если вы правильно выполнили свою работу, яркие оценки и комментарии убедят пользователей нажать важнейшую кнопку установки.
Контрапункт: на самом деле веб-приложения легче обнаружить.
Интернет, возможно, является самой доступной средой, когда-либо созданной. В скромном URL-адресе мы имеем (по крайней мере теоретически) уникальный идентификатор всего, что когда-либо публиковалось в сети, включая любые приложения, опубликованные на стандартных веб-сайтах. Поисковые системы позволяют легко обнаружить, что на него могут ссылаться контент и другие веб-сайты, включая каталоги веб-приложений, аналогичные мобильным рынкам. Действительно, любой человек может поделиться веб-приложениями со своими друзьями, просто связавшись с ними в электронных письмах и сообщениях социальных сетей. Ссылки также можно отправлять в SMS, при этом пользователи мобильных устройств смогут щелкнуть ссылку и запустить приложение в браузере своего устройства.
У нас пока нет прежних торговых площадок, где пользователи могут оценивать и комментировать приложения, но ситуация тоже меняется. Читай дальше…
Монетизация
Точка: Нативный можно монетизировать.
«Шестилетний ребенок делает приложение во время обеденного перерыва и продает миллион копий по 3 доллара каждая». В наши дни вы часто видите этот заголовок, поэтому неудивительно, что большие и малые разработчики обращаются к мобильным рынкам для монетизации. Мобильные платформы предлагают разработчикам несколько возможностей напрямую взимать плату за свои приложения. Самый простой — это единоразовый платеж, чтобы разблокировать приложение на всю вечность. На некоторых платформах также предлагаются механизмы оплаты и подписки внутри приложений, и они тесно интегрированы в согласованный и безопасный механизм. Эти новые формы оплаты позволяют разработчикам превратить популярное приложение в долгосрочный источник дохода.
Помимо платежей в приложениях, вы можете монетизироваться с помощью традиционных веб-моделей, таких как реклама и спонсорство.
Контрапункт: в сети всегда можно было монетизировать, и возможности растут.
Интернет не был бы двигателем современной индустрии, если бы не было широких возможностей для получения прибыли. Хотя механизмы прямой «платы по факту использования» еще не процветали, существуют различные ниши, где «программное обеспечение как услуга» на основе подписки «Решения действительно стали жизнеспособными. Примеры включают Google Apps, линейку продуктов 37Signals и премиум-версии различных почтовых сервисов. Более того, прямые платежи — не единственный способ получения прибыли от веб-приложений. Есть онлайн-реклама, партнерские ссылки, спонсорство, перекрестное продвижение других продуктов и услуг.
Тем не менее, для веб-разработчика вполне разумно читать заголовки и испытывать приступ зависти к платежам. Вы не можете отправить веб-URL на собственные торговые площадки, так что же делать веб-разработчику? Что вы делаете, так это создаете собственное «приложение-оболочку» — для каждой платформы, на которую вы хотите ориентироваться, создайте пустое собственное приложение, которое просто содержит веб-представление. Веб-представление — это место, куда вы встраиваете настоящее приложение. Затем вы просто отправляете эти приложения на различные торговые площадки (и, надеюсь, наблюдаете, как поступают деньги!). Сегодня на основных торговых площадках, вероятно, существуют сотни, если не тысячи веб-приложений, некоторые из них настолько хитро ассимилированы, что мы даже вообще не знаем их веб-приложений.
Обратной стороной является необходимость кросс-компиляции для каждой платформы. Здесь может помочь существующая платформа, такая как PhoneGap. Более того, в разработке находятся такие веб-сервисы, как PhoneGap Build и Apparatio. Направьте эти веб-сайты на свой репозиторий кода, и появится приложение для Android, приложение для iOS и т. д., готовое для отправки в соответствующие магазины. Никакой установки собственных SDK на ваш компьютер; все, что вам нужно для создания всех этих собственных приложений, — это редактор кода и веб-браузер.
Будут ли торговые площадки когда-либо поддерживать веб-приложения напрямую, без затрат на их нативную упаковку? Это еще не ясно. Мы знаем, что Google представил Интернет-магазин Chrome в прошлом году, и хотя он применим только к настольным компьютерам, магазин вызвал интерес со стороны других поставщиков браузеров и в целом является частью тенденции к созданию каталогов веб-приложений, включая некоторые попытки для мобильных устройств. . Концепция интернет-магазина только начинается, но признаки обнадеживают.
Выводы
Было бы неплохо объявить здесь победителя, но на данный момент явного победителя нет. Некоторые приложения лучше всего подходят для нативной версии, а некоторые лучше всего подходят для Интернета. Веб-стек, возможно, имеет больший импульс, но с точки зрения возможностей и качества исполнения нативные приложения также развиваются быстро. И пока не наступит время, когда веб-технологии станут первосортным элементом большинства мобильных ОС, нативность всегда будет важным фактором.
Один из методов, упомянутых в этой статье, — это гибридные приложения, и для некоторых разработчиков это может быть лучшим компромиссом: веб-просмотр там, где это возможно, и собственные компоненты, специфичные для платформы, где это невозможно.
Если вы все же выберете веб-путь, помните о веб-стандартах и принципе постепенного улучшения. Интернет — это технология, которая знает, как работать с множеством устройств и операционных систем вокруг. Независимо от того, решите ли вы назвать это «фрагментацией» или «разнообразием», Интернет принимает это, и вы, разработчики, можете извлечь выгоду из всего существующего уровня техники.