Каковы преимущества и недостатки подходов HTML5, нативных и гибридных мобильных приложений?

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

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

Я разработчик мобильных приложений, который потратил много времени на рассмотрение этой проблемы.

Почему ты справшиваешь?

Скорее всего, вы надеетесь сократить расходы на разработку приложений за счет:

• Использование существующих навыков разработки HTML5 / Javascript
• Ориентация на несколько платформ без написания нескольких приложений с нуля
• Не нужно поддерживать несколько кодовых баз в будущем

Причины могут также включать:

• Разработка HTML5 / Javascript воспринимается как «более легкая», чем разработка нативной платформы
• Избегать оплаты регистрационных сборов разработчиков
• Как избежать ограничений контента в AppStore (азартные игры и т. Д.)
• Избегать покупки аппаратного обеспечения разработки (например, Mac для разработки iPhone)

Определения

Давайте точно установим, что мы подразумеваем под каждым из трех упомянутых подходов:

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

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

Гибридное
гибридное instanceofприложение.

Большинство людей, вероятно, понимают гибридное приложение как одностраничное мобильное веб-приложение (опять же, наиболее вероятно, имитирующее внешний вид нативного приложения), но упакованное как нативное приложение с доступом к нативным службам (как Phonegap).

Однако на самом деле между моделью Phonegap и полностью нативной есть спектр, о котором я расскажу позже.

Мобильная сеть

Технические ограничения
Давайте сначала перечислим некоторые технические ограничения для мобильных веб-приложений, которые сами по себе могут нарушить условия сделки в зависимости от того, что вы делаете:

• Только пользовательский интерфейс HTML / canvas
• Нет доступа к определенным событиям и службам устройства (они широко задокументированы)
• Не могут быть перечислены в магазинах приложений (влияет на обнаружение)
• Может отображаться в полноэкранном режиме и иметь значок рабочего стола на iOS, однако это необычный и незнакомый опыт для большинства пользователей.

Если вы можете справиться со всем вышеперечисленным, то читайте дальше о проблемах одностраничных веб-приложений в собственном стиле. Однако этот раздел не будет полным без ссылки на приложение FT.

Financial Times веб - приложение FT является известным примером этого стиля приложения. Вот интересная особенность из британской газеты Guardian об этом.

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

Одностраничные веб-приложения в собственном стиле

Этот раздел относится как к мобильным сетям, так и к приложениям в стиле PhoneGap.

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

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

Основным способом, которым страдают эти платформы, является попытка эмулировать собственные тонкости пользовательского интерфейса платформы. Этот приятный небольшой эффект, который вы получаете, прокручивая до конца список на iPhone? Ваша структура должна эмулировать это в Javascript. Невозможно воссоздать его полностью, оно будет склонно к замедлению, и ваши пользователи будут застревать в «сверхъестественной долине» приложения, которое выглядит как родное, но явно нет, и нетехническое пользователь не сможет понять, почему.

Миф «HTML5 / Javascript это просто»

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

И поскольку ваше приложение становится все более функционально сложным, вы обнаружите, что вам нужны не только базовые навыки работы с jquery, чтобы поддерживать чистоту и удобство обслуживания вашего Javascript.

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

Далее по спектру

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

Поделиться кодом не-пользовательского интерфейса

Существует целый ряд методов для обмена бизнес-логикой на нескольких собственных платформах. Google запустил J2ObjC, который переводит Java в Objective-C. При тщательном разборе кода библиотека Java может использоваться как на Android, так и на iOS.

Такие библиотеки, как Calatrava и Kirin, позволяют манипулировать основами кода, написанными на Javascript (и, следовательно, всем, что может быть скомпилировано в Javascript) из собственного кода. Отказ от ответственности: я работаю на Future Platforms, которые создали Кирин; мы добились большого успеха, используя его на iOS с Javascript, сгенерированным из Java с GWT, с Java-кодом, также работающим на Android.

Используйте веб-просмотров ... где это уместно

У полноэкранных веб-просмотров есть много работы, чтобы имитировать переходы экрана и эффекты отказов. Но веб-просмотр в нативном приложении Chrome может быть неотличим от нативного.

Существуют стандартные и хорошо документированные методы для общения между приложениями и веб-представлениями.

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

В итоге

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

Мой девиз: везде, где только можно, используйте веб-просмотры, но убедитесь, что ваши пользователи не могут сказать .

Сначала проверьте этот опрос, чтобы узнать, что происходит!

сравнение между тремя типами: понимание ваших возможностей разработки мобильных приложений

Сравнение натива и гиприда:

HTML5 против родного

HTML5 против родного приложения: что выбрать ??

Это действительно хорошо: HTML5 v нативные приложения: ключевые аспекты вашей мобильной стратегии

Комментарии:

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

Если вам нужен доступ к аппаратному обеспечению телефона, вам следует создать собственное приложение (в HTML5 вы можете получить доступ к некоторым аппаратным компонентам устройства, таким как GPS).

Если вам удобнее заниматься веб-разработкой, вам следует придерживаться этого, если только вам не нужно создавать нативное приложение.

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

Для меня, когда пишу любое потребительское приложение, главное в его успехе - принятие и восприятие приложения пользователем. Из-за этого четыре причины склоняться в пользу нативных приложений, несмотря на дополнительные расходы, связанные с обучением, обучением и потерей WORA (пишите один раз в любом месте):

1. Быстрый запуск приложения
2. Плавная прокрутка
3. Более согласованный пользовательский интерфейс приложения, который более последовательно связывается с остальными ОС и приложениями
4. Более быстрый ответ пользовательского интерфейса приложения

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

По аналогичным причинам Facebook отказался от стратегии своих приложений в пользу нативных приложений для IOS и Android:

Пожалуйста прочти:

Марк Цукерберг: Нашей самой большой ошибкой было слишком много ставок на HTML5 http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /

Почему Facebook отказался от мобильного интернета и оставил свой собственный новый iOS-приложение http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ИОС-приложение # awesm = ~ o9jDrRefxdgnpS

Надеюсь это поможет.

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

Я оставил Мобильный Интернет, потому что он служит совершенно другой цели. Если вы хотите быть в магазинах приложений, Native / Hybrid - это то, что вам нужно. Если вы хотите упростить развертывание и пожертвовать опытом и техническими возможностями, перейдите на Mobile Web.

За / Минусы Родной :

• Pro: Это соответствует остальной части опыта устройства, никаких сверхъестественных проблем долины .
• Pro: Это в основном обеспечивает плавный и последовательный интерфейс, без задержек и заиканий.
• Pro: Несколько технических ограничений, вы можете полностью использовать устройство.
• Pro: Собственные инструменты обеспечивают соответствие проверки магазинов приложений.
• Pro: Родные фреймворки включают в себя настройки для каждой версии платформы, меньше времени затрачивается на тонкую настройку.
• Con: Это построение, чтобы длиться, и поэтому занимает больше времени, чтобы построить.
• Против: Требуются разработчики полиглотов, которые трудно найти, дорого.
• Против: Нужно ознакомиться с API каждого устройства (iOS / Android / и т. Д.).
• Con: крутая кривая обучения.
• Против: Различные наборы инструментов для каждой платформы.

Про / Минусы Гибрид :

• Pro: одна кодовая база для нескольких платформ устройств.
• Pro: Быстрые циклы разработки, отличная гибкость в макете, идеально подходит для прототипирования и MVP .
• Pro: Удобная форма обучения, много документации, фреймворки, которые могут вам помочь.
• Pro: Единый набор инструментов для разработки. Инструменты отладчика Chrome превосходны.
• Pro: одна кодовая база для нескольких платформ устройств.
• Pro: множество разработчиков доступно, легко учиться.
• Против: Требуется приличная структура пользовательского интерфейса для адаптации пользовательского интерфейса для каждой отдельной платформы, чтобы соответствовать опыту устройства. Есть такие решения, как Kendo UI , Sencha Touch .
• Против: Необходимо очень внимательно относиться к использованию памяти и вычислений, некоторые циклы CSS и javascript могут серьезно замедлить работу приложения. На устройстве доступны не очень хорошие инструменты для отладки.
• Con: еще не созрели, все может внезапно измениться, хотя инструменты становятся лучше.

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

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

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

Большая проблема с гибридными приложениями заключается в фрагментации фреймворков: их явно гораздо больше (Ionic, Xamarin, React Native и т. Д.), Чем нативных мобильных платформ, представляющих интерес (обычно только две, Android и iOS). Эти фреймворки конкурируют, появляются, отклоняются, поэтому гибрид не спасет вас от перехода с платформы на платформу, даже если вы планируете сохранить свою нынешнюю команду на всю жизнь.

Google и Apple стараются изо всех сил в обеспечении и поддержке редакторов, отладчиков, сред тестирования, инструментов рефакторинга и других средств разработки для своих платформ. Поэтому я бы взял типичную формулировку « гораздо проще разработать гибридное приложение, отредактировать его в своем любимом редакторе и открыть в браузере » с разумной оговоркой. Xamarin и React Native являются платформами разработки, такими же, как Swift или Java / Android, и, хотя «привет мир» может выглядеть короче, в конечном счете, для правильного обучения может потребоваться сопоставимое время.

Если в любом случае возникнет необходимость в собственных компонентах (например, необходимо интегрировать существующую стороннюю библиотеку), вы получите три фреймворка, а не две: iOS, Android и гибридный фреймворк наверху, в итоге с более сложной архитектурой. Отладка таких приложений, переход между межуровневыми вызовами, регистрация всех слоев, синхронизация кода сложна, а порой и невозможна.

Некоторые говорят, что « приложение будет выглядеть одинаково для всех платформ ». Это действительно хорошая вещь? Приложение Android должно выглядеть как приложение Android, а приложение iOS должно выглядеть как приложение iOS.

Как насчет новых функций? Носимых? Мгновенные приложения теперь предлагаются на платформе Android? Отображение дополнительных данных на внешнем дисплее? Гибридные приложения теперь поддерживают множество встроенных функций, но действительно ли они поддерживают их все ? В любое время, немедленно?

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

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