Как сделать гибридное мобильное приложение
это руководство поможет вам приступить к созданию гибридного веб-приложения или последовательного веб-приложения (PWA) на Windows с помощью одной базы кода HTML/CSS/JavaScript, которую можно использовать в интернете и на разных платформах устройств (Android, iOS, Windows).
С помощью правильных платформ и компонентов веб-приложения могут работать на устройстве Android таким образом, чтобы пользователи были очень похожи на собственное приложение.
возможности PWA или гибридного веб-приложения
Существует два основных типа веб-приложений, которые можно установить на устройствах Android. Основное различие состоит в том, что код приложения внедрен в пакет приложения (гибридный) или размещен на веб-сервере (PWA).
Гибридные веб-приложения: код (HTML, JS, CSS) УПАКОВАН в apk и может распространяться с помощью Google Play Маркет. Подсистема просмотра изолирована от Интернет-браузера пользователей, нет общего доступа к сеансу или кэшированию.
Прогрессивные веб-приложения (пвас): код (HTML, JS, CSS) находится в Интернете и не нуждается в упаковке как apk. Ресурсы загружаются и обновляются по мере необходимости с помощью рабочей роли службы. Браузер Chrome выполнит визуализацию и отобразит ваше приложение, но будет искать собственный код и не включать в себя обычную адресную строку браузера и т. д. С помощью браузера можно предоставлять общий доступ к хранилищу, кэшу и сеансам. По сути, это аналогично установке ярлыка в браузере Chrome в специальном режиме. Пвас также можно найти в Google Play Маркет с помощью доверенного веб-действия.
Пвас и гибридные веб-приложения очень похожи на собственные приложения Android:
- Можно установить через App Store (Google Play Маркет и (или) Microsoft Store)
- доступ к собственным функциям устройства, таким как камера, GPS, Bluetooth, уведомления и список контактов
- Работать вне сети (без подключения к Интернету)
Пвас также имеют несколько уникальных функций:
- Можно установить на начальном экране Android непосредственно из Интернета (без магазина приложений).
- Дополнительно можно установить через Google Play Маркет с помощью доверенного веб-действия .
- Можно обнаружить с помощью веб-поиска или через URL-ссылку.
- Полагаться на рабочую роль службы , чтобы избежать необходимости упаковывать машинный код
для создания гибридного приложения или PWA не требуется платформа, но есть несколько популярных платформ, которые будут рассмотрены в этом разделе, включая PhoneGap (с cordova) и ионные (с помощью cordova или конденсатора с использованием Angular или React).
Apache Cordova.
Apache Cordova — это платформа с открытым исходным кодом, которая может упростить обмен данными между кодом JavaScript и собственной платформой Android с помощью подключаемых модулей WebView . Эти подключаемые модули предоставляют конечные точки JavaScript, которые можно вызывать из кода и использовать для вызова интерфейсов API устройства Android. К примерам подключаемых модулей Cordova относятся доступ к таким службам устройств, как состояние аккумулятора, доступ к файлам, звуки вибрации и кольца и т. д. Эти функции обычно недоступны для веб-приложений и браузеров.
Существует два распространенных дистрибутива Cordova:
PhoneGap: поддержка прекращена корпорацией Adobe.
Ionic
Ионная среда — это платформа, которая корректирует пользовательский интерфейс приложения в соответствии с языком разработки каждой платформы (Android, iOS, Windows). с помощью ионных приAngularов или React.
Существует новая версия платформы ионных вызовов, которая использует альтернативу Cordova, именуемый конденсатором. В этом альтернативном варианте используются контейнеры, чтобы сделать приложение более удобным для веб-приложений.
Начало работы с ионными программами с помощью установки необходимых средств
чтобы приступить к созданию PWA или гибридного веб-приложения с помощью ионных приложений, необходимо сначала установить следующие средства:
Node.js для взаимодействия с экосистемой ионных взаимодействий. скачайте NodeJS для Windows или следуйте инструкциям руководства по установке NodeJS с помощью подсистема Windows для Linux (WSL). Если вы будете работать с несколькими проектами и версией NodeJS, вы можете использовать Диспетчер версий node (НВМ) .
VS Code для написания кода. скачайте VS Code для Windows. Также можно установить Удаленное расширение WSL , если вы предпочитаете создавать приложение с помощью командной строки Linux.
Терминал Windows для работы с предпочтительным интерфейсом командной строки (CLI). установите Терминал Windows из Microsoft Store.
Git для управления версиями. Скачайте Git.
Создание нового проекта с помощью ионных и Angular
Установите ионные и Cordova, введя в командной строке следующее:
создайте ионное Angular приложение с помощью шаблона приложения "табуляция", введя команду:
Перейдите в папку приложения:
Запустите приложение в веб-браузере:
дополнительные сведения см. в статье о ионных Angularных документах Cordova. сведения о перемещении приложения из гибридной среды в PWA см. в разделе создание Angular приложения PWA .
Создание нового проекта с конденсатором ионных и Angular
Установите ионные и Cordova-Res, введя в командной строке следующее:
создайте ионное Angular приложение с помощью шаблона приложения "табуляция" и добавьте конденсатор, введя команду:
Перейдите в папку приложения:
Добавьте компоненты, чтобы сделать приложение PWA:
@ionic/pwa-elementsЧтобы импортировать, добавьте в файл следующее src/main.ts :
Запустите приложение в веб-браузере:
дополнительные сведения см. Angular документации по ионным конденсаторам. сведения о перемещении приложения из гибридной среды в PWA см. в разделе создание Angular приложения PWA .
Создание нового проекта с помощью ионных и React
Установите ионный интерфейс командной строки, введя в командной строке следующее:
создайте новый проект с React, введя команду:
Перейдите в папку приложения:
Запустите приложение в веб-браузере:
дополнительные сведения см. в статье о ионных React документах. сведения о перемещении приложения из гибридной среды в PWA см. в разделе создание React приложения PWA .
Тестирование приложения на устройстве или в эмуляторе
Чтобы протестировать приложение на устройстве Android, подключаемый модуль (Убедитесь, что он впервые включен для разработки), в командной строке введите:
Чтобы протестировать приложение-ионное устройство в эмуляторе устройства Android, необходимо выполнить следующие действия.
Введите команду для ионных ресурсов, чтобы создать и развернуть приложение в эмуляторе: ionic cordova emulate [<platform>] [options] . В этом случае команда должна быть следующей:
дополнительные сведения см. Emulator Cordova в документации по ионным соединению.
А помните ли вы свой первый мобильный телефон? Для меня это была Nokia 3310, неубиваемая «трубка», неустанно радовавшая меня скудным набором развлечений в виде игры в змейку, WAP и чудесных монофонических рингтонов. За последние тридцать лет индустрия шагнула далеко вперед. И это ещё мягко сказано: мобильные чипы приближаются по производительности к современным компьютерам, а две самые популярные на текущий момент системы — Android и iOS — предоставляют практически безграничные возможности для создания приложений на любой вкус.
Оплата по NFC, заказ такси буквально за пару свайпов, и даже тот же Instagram настолько плотно вошли в нашу жизнь, что необходимость создания мобильного клиента для своего бизнеса теперь уже не вызывает вопросов. Стандартом разработки в этом случае принято считать нативные приложения. Они работают плавно, имеют привычный пользователям UI и UX, а также доступ к разнообразным аппаратным возможностям смартфона и его операционной системы. Из основных недостатков этого подхода можно отметить необходимость иметь в штате выделенных iOS- и Android-разработчиков, возникновение сложностей в организации тестирования, и более длительный, по сравнению с web, релизный цикл. Нельзя забывать и про сегментацию: часть пользователей предпочитает оставаться на старых версиях приложения, старых версиях iOS и Android, обожают свои старые телефоны. Поэтому ненайденный в релизе баг, просочившись в сторы, напоминает землетрясение с долгим афтершоком.
Если у вас уже есть команда опытных мобильных разработчиков и налажен CI, то кажется, что выбор очевиден. Но зачастую бывают ситуации, когда время запуска функциональности в прод играет решающую роль, а постоянные обновления не идут на пользу репутации приложения. Хотя бы раз в жизни, каждый из нас брал кредит, или, по крайней мере, всерьез задумывался об этом. Обычно этот процесс включает в себя заполнение анкеты. Представим, что такая анкета есть у вас на сайте и в мобильном приложении. И вот банк решил освободить зарплатных клиентов от половины полей — это, безусловно, прекрасно, но влечет за собой изменения на сайте, а также в iOS- и Android-приложениях. Учитывая нашу асинхронность релизных циклов, а также возможность появления багов при обновлении, возникает риск получить три разные анкеты на неопределенный срок. А если подобные изменения нужно вносить часто?
Очевидное решение — гибрид. Существует множество фреймворков, позволяющих писать код сразу под обе платформы: Flutter, React Native, Ionic, однако их внедрение в существующий проект может стоить значительного времени и трудозатрат. Есть способ проще: помещая часть функциональности в WebView, мы можем быстро и относительно дешево переиспользовать часть уже реализованной на сайте логики. Контент, загружаемый из сети, в связке с нативными компонентами подчас абсолютно неотличим от нативного экрана. Так пользователи получат доступ к новым фичам одновременно с веб-версией, а мобильная команда сможет проработать полноценный нативный процесс в менее жестких временных рамках.
Если вы пошли по пути «гибрида», то важно понимать, когда это решение временное, а когда постоянное. Экран в WebView, как и любой другой, является частью экосистемы приложения. Запуская функциональность с объемной бизнес-логикой, придется закладывать значительное время и ресурсы на её поддержку. Но почему, если всё уже давно свёрстано и прекрасно работает?
50 оттенков сервисов
Тестирование под разные браузеры и разрешения — обычное дело при разработке фронта. Теперь этот чеклист пополнит ещё и мобильное приложение. Всё дело в WebKit-е, свободном движке для отображения веб-страниц, на котором работают все самые популярные браузеры. Он отвечает за единообразный разбор HTML, построение DOM, создание объектов window и document, работу с CSS, а также построение макетов и позиционирование UI-элементов. Однако при всём видимом удобстве, он насчитывает немалое количество версий, или, как их ещё называют, — «портов».
От одной версии к другой могут различаться подходы к управлению рендерингом, декодированию изображений и работе с видео; меняется поддержка кодеков, сетевой слой, а также используются разные JS-движки. Также WebKit позволяет включать или выключать любую функциональность на этапе компиляции при помощи compile-time feature flags, и даже в рантайме, при передаче параметров в командной строке или конфигурации. Прибавьте ко всему этому факторы, зависящие от «железа», и становится очевидно: браузер на телефоне точно будет отличаться от своего одноименного десктопного собрата.
Таким образом, встраивая в приложение «браузер на минималках» перед выкаткой в прод всё равно стоит закладывать дополнительное время на тестирование экрана, а лучше всего процесса.
WebView ≠ адаптив
Если пользователи привыкли менять вкладки при помощи свайпов, то на экране с WebView они будут ожидать поддержки такого же поведения. То же самое касается нативной навигации между экранами и UI-элементов (кнопок, полей ввода, контекстных меню и т.п.).
С точки зрения UX и дизайна, процесс работы с приложением должен оставаться согласованным, а руководящие принципы разработки пользовательских интерфейсов платформ должны быть учтены. Можете считать, что создание отдельной верстки под WebView это неизбежная плата за возможность мгновенного обновления функциональности без привязки к мобильным релизам. Чтобы поддержка функциональности в WebView не причиняла вам боль, с самого начала тратьте время на создание базы UI-компонентов со стилями, использованными в приложении.
Бесшовный процесс
UI приведен к общему виду, и даже самый нервный дизайнер опустил нож? Новый экран не зависит от других и не требует ввода данных? Тогда, пожалуй, можно пропустить этот пункт… Но лучше не торопитесь.
На протяжении пользовательского пути зачастую возникает необходимость сохранить прогресс и полученную информацию. Открывая гибридный экран, не будет лишним передать в параметрах ссылки всё, что необходимо для продолжения работы. Что касается обмена данными в реальном времени, то его легко организовать, используя коллбэки. Например, с их помощью WebView может передать информацию о пунктах, которые должны отображаться в контекстном меню, а нативное меню, в свою очередь, вернёт пункт, на который нажал пользователь, и браузер загрузит нужную страницу.
Хотите встроить экран в существующий процесс? Без проблем. Но при этом логика работы приложения должна оставаться согласованной, а данные — консистентными. Библиотека WebKit в связке со средствами JS, реализованными интерфейсами на стороне Android и message handler со стороны iOS способны обеспечить глубокую интеграцию WebView-экрана и нативного кода. Вы сможете добавлять нативные виджеты поверх страниц, управлять их UI, добавлять требуемое поведение и настраивать видимость.
Тёмная сторона WebView
Начиная с Android 10 и iOS 13 появилась функциональность, называемая «тёмной темой». Это альтернативная цветовая схема UI, предназначенная для заботы о ваших глазах во время использования телефона в ночное время. Библиотека WebKit позволяет выставить настройки, согласно которым загруженная страница будет отображаться в соответствии с темой, установленной в текущий момент на телефоне (рекомендуемый режим), всегда в тёмном или светлом виде. Обратите внимание, что добавление поддержки тёмной темы в CSS веб-страницы строчкой @media (prefers-color-scheme: dark) не даст нужного результата, так эта настройка влияет только на контролы — панель прокрутки, кнопки приближения и отдаления и т.д., но не на стиль контента, отображаемого внутри WebView.
Если в вашем приложении заданы стили для тёмной темы, это уже отлично, но и экран в WebView тогда обязан выглядеть соответствующе.
Разделяй и властвуй
Одними из важнейших показателей стабильности мобильных приложений являются доля crash-free users и отзывы в сторах. И если раньше все данные об ошибках, логи и пользовательские метрики можно было найти в Firebase или любом другом любимом вами сервисе, то теперь отладка и сбор аналитики станут несколько сложнее. В то же время оценки пользователей всё так же будут отражать их отношение к продукту целиком, вне зависимости от того, в какой части работы с гибридом у них возникли затруднения. Разбор каждого такого случая теперь будет начинаться с выявления источника: ошибка в нативе или вебе, или всё же в интеграции. Решением может стать сегментирование отзывов пользователей по тегам и перенос аналитики в единый кроссплатформенный сервис.
Один из популярных сервисов мониторинга активности приложений в App Store и Google Play — AppFollow. Он предоставляет автоматическую разметку отзывов пользователей. Для этого нужно прописать правила, согласно которым будут проставляться теги. Например, к жалобам на баги можно отнести отзывы с наличием в тексте слов «баг», «ошибка» или «не работает», а также с оценкой меньше 3.
А для сбора аналитики отлично подойдет ClickHouse — open source СУБД российской разработки, предназначенная для работы с большими объёмами данных. Она способна эффективно обрабатывать запросы в реальном времени, при этом их синтаксис максимально приближен к классическому SQL. Помимо быстродействия и низкого порога вхождения для пользователей стоит также отметить отлично реализованное сжатие данных и отсутствие проблем с подключением — у сервиса активное сообщество, на текущий момент есть готовые коннекторы под большинство популярных языков программирования. А если мне до сих пор не удалось вас убедить, то посмотрите руководство, знакомство с функциональностью займёт буквально пару часов, а тестовые данные идут в комплекте.
Подводя итог, становится понятно, что «быстро и относительно дёшево запуститься в WebView» — задача нетривиальная, если говорить о крупных и хорошо оттестированных фичах. Но зато этот подход отлично применим для кратковременного промо, раздела со справочной информацией, динамических форм обратной связи — иными словами, для экранов с часто изменяемой информацией, не завязанных на основные сценарии приложения.
Выбирая между запуском MVP в нативе и WebView, важно понимать, что лучшее решение принимается только в контексте задачи. Нативные SDK позволяют эффективно контролировать объём памяти, используемой приложением, загружать файлы в фоне, хранить локально большие объёмы данных, а также использовать все аппаратные преимущества современных смартфонов и систем iOS и Android. Требуется минимальный Time To Market? Гибридное решение позволяет запускать новую функциональность синхронно с сайтом, фиксить баги быстро и одновременно на всех устройствах. Однако при его некачественном исполнении пользовательский опыт может серьёзно пострадать.
Так где же золотая середина? WebView может неплохо себя показать в качестве заглушки, однако, как известно, нет ничего более постоянного, чем временное. Отличным вариантом будет начать разработку нативной версии одновременно со страницей гибрида. Мобильные разработчики смогут быстро погрузиться в контекст, фронты — корректно доработать вёрстку, пользователи получат фичу в самые короткие сроки, а через релиз экран уже станет нативным. Выбирайте мудро, используйте инструменты правильно, и результат не заставит себя долго ждать.
В этой статье вы узнаете, как реализовать приложение Cordova с нуля в среде Windows и как развернуть приложение на устройстве Android.
1. Установите необходимые инструменты
Вам нужно будет установить 3 инструмента, чтобы создать первое приложение Cordova в Windows:
-
: нам нужен комплект разработки Java, установленный на нашем компьютере. : хотя мы не будем использовать Android Studio, рекомендуется загрузить полный пакет, включающий Android Studio и SDK, этот SDK включает в себя инструменты сборки, AVD Manager и SDK Manager. Размер установочного файла составляет около 1,6 ГБ. Загрузите предварительно созданный установщик для вашей платформы Node.js с архитектурой вашей системы (x64 или x86). Установщик может быть MSI или EXE-файл.
Поскольку установка каждого из этих инструментов не требует какой-либо специальной настройки, а только для следования мастеру установки в системе, позаботьтесь об установке и перейдите к шагу 2, когда все будет установлено. Если вы хотите проверить, все ли правильно установлено, вы можете проверить каталоги установки:
Установка JDK
Найдите папку установки (которая обычно есть) и убедитесь, что папка jdk [версия] существует:
Кроме JAVA_HOME переменная окружения должна существовать. Если он не был создан автоматически, вам нужно его создать. Как только у вас есть путь установки JDK (с /bin в конце):
- Щелкните правой кнопкой мыши Мой компьютер значок на рабочем столе и выберите свойства.
- Нажмите на продвинутый вкладку, затем нажмите Переменные среды кнопка.
- Под Системные переменные, нажмите Новый.
- Введите имя переменной как JAVA_HOME.
- Введите значение переменной в качестве пути установки для Java Development Kit (в этом примере будет C:\Program Files\Java\jdk1.8.0_111\bin ).
- Нажмите Хорошо.
- Нажмите Применять изменения.
Android SDK
Откройте папку AppData, набрав %appdata% в строке поиска Windows или нажав WIN + R:
Затем перейдите в локальную папку, а затем папка android должна существовать, а внутри должна находиться папка sdk, папка sdk должна иметь следующее содержимое (или аналогично):
Node.js
Чтобы проверить, правильно ли установлен node.js, должен быть прямой доступ с именем Командная строка Node.js исполняемый файл в меню «Пуск»:
Этот исполняемый файл такой же cmd.exe из окон, однако он запускает следующую команду для запуска: C:\Windows\System32\cmd.exe /k "C:\Program Files\nodejs\nodevars.bat" , Поэтому, если исполняемый файл по какой-то необычной причине, вы можете выполнить предыдущую команду для запуска в окне cmd. Консоль Node должна выглядеть так:
В этой консоли вы будете запускать каждый узел и команду cordova позже.
2. Установите Cordova в Node.js
Продолжите установку Cordova, выполнив следующую команду в командной строке Node.js:
Поскольку Cordova будет установлен в глобальном масштабе, вы можете выполнить команду из любой точки консоли. После завершения установки проверьте версию Cordova, выполнив:
Это должно генерировать следующий вывод в консоли (обратите внимание, что версия Cordova может отличаться):
3. Создайте свой первый проект
Теперь, когда CLI Cordova доступен для его использования, мы можем начать с создания нашего проекта. Перейдите с помощью консоли к папке, в которой вы хотите сохранить все свои проекты cordova, с помощью команды CD, в этом случае папка будет расположена в Desktop и будет иметь имя dev-desktop :
Приступить к созданию проекта с использованием cordova create Команда, эта команда имеет следующую структуру:
В этом примере наше тестовое приложение будет песочницей, и мы создадим его, выполнив следующую команду (измените имя пакета в соответствии с вашим именем):
Создание проекта не должно занять много времени, команда создаст папку с именем sandbox и содержание нашего проекта Cordova будет внутри. Теперь перейдите в папку с песочницей, используя:
С помощью этой инструкции вы находитесь с консолью в C:\Users\sdkca\Desktop\dev-desktop\sandbox каждая команда cordova для вашего проекта должна выполняться только тогда, когда вы находитесь в папке вашего проекта с консолью.
4. Добавить платформу в свой проект
Ваш проект Cordova был успешно создан, однако без какой-либо платформы он не будет работать. Вы можете использовать команду cordova platform, чтобы добавить первую платформу в ваше приложение, в этом случае и, как сказано в этой статье, мы собираемся создать наше первое приложение для использования в Android, поэтому мы собираемся добавить платформу Android, используя следующая команда:
Вывод в консоли будет похож на:
После установки платформы структура вашего проекта должна быть похожа на:
Важный: как вы можете видеть на изображении, с последней версией Cordova целевая версия Android равна 24. Это означает, что вам нужно проверить, установлена ли эта версия API в SDK Manager android.
Откройте SDK Manager (обычно находится в папке Android SDK, т.е. C:\Users\\AppData\Local\Android\sdk\SDK Manager.exe ) и проверьте, какие версии установлены:
Если целевая версия не установлена, перейдите к ее установке и дождитесь завершения установки.
5. Сборка и тестирование
Развернуть приложение Cordova можно двумя способами:
Эмулятор
Чтобы эмулировать ваше приложение cordova в эмуляторе Android, сначала необходимо настроить его в качестве эмулятора. Откройте диспетчер AVD (Android Virtual Device) (обычно находится в папке Android SDK, т.е. C:\Users\\AppData\Local\Android\sdk\AVD Manager.exe ) и создайте новый, если у вас его еще нет.
Прежде чем продолжить создание эмулятора, мы рекомендуем вам (лучше сказать, вам нужно) для установки Intel HAXM. Это может быть автоматически установлено менеджером Android SDK ( C:\Users\\AppData\Local\Android\sdk\SDK Manager.exe ):
Если у вас есть видеокарта, отметьте опцию Use Host GPU. Наконец, нажмите «Сохранить», чтобы создать эмулятор, после его создания запустите его. Наш эмулятор с Android 7 выглядит так:
Позвольте активировать окно эмулятора и, в качестве последнего шага, создайте приложение и установите эмулятор в качестве цели, используя следующую команду:
Если вы выполните команду, а эмулятор не будет открыт, то он автоматически запустит эмулятор по умолчанию, доступный в AVD Manager (поэтому, чтобы увеличить время разработки, позвольте эмулятору открыться :-)). Начнется сборка приложения, и ваше приложение должно запуститься в эмуляторе:
Довольно легко, правда?
устройство
Чтобы развернуть приложение на своем устройстве, вам понадобится (за счет избыточности):
- Мобильное устройство с Android (очевидно, по крайней мере с минимальной версией Android, требуемой для приложения cordova, обычно Android 4.1.2 API 16).
- USB-совместимый кабель для вашего устройства.
Подключите устройство к компьютеру с помощью USB-кабеля и выполните следующую команду, чтобы создать приложение и выполнить его на устройстве:
Начнется процесс сборки, и приложение будет развернуто на вашем устройстве. Поздравляем, вы только что создали и развернули свое первое приложение Cordova, наконец, мы рекомендуем вам читать документацию кордова для дополнительной информации.
Дополнительно
Есть пара советов, которые могут сделать ваш опыт разработки еще лучше:
Отладка вашего index.html с помощью Chrome
Как всем известно, нет возможности отладить страницу Cordova непосредственно в устройстве. Хотя отладка приложения для Android с помощью Android studio (нативного приложения для Android) довольно проста, отладка приложения Cordova может стать большим кошмаром, если у вас нет нужных инструментов. Вы можете использовать Google Chrome для отладки приложения Cordova так же, как вы отлаживаете веб-сайт в браузере.
Отладка нативного кода в Cordova
Мобильные приложения давно являются мейнстримом для удаленного обслуживания клиентов и предоставлению сервисов. Они активно вытесняют полнофункциональные веб приложения во многих категориях. Это обусловлено разными причинами, среди которых главной является динамическая природа нашего времени, когда все требуется делать быстро и на бегу — мобильный всегда под рукой, а вот полнофоматный компьютер доступен гораздо реже.
В этой статье я попробую рассмотреть различные варианты реализации мобильных приложений или чего-то похожего на них. Вот схема того, что мы обсудим в этой статье.
На схеме эти варианты представлены на шкале Complexity/Functionality (Сложность реализации/Доступная функциональность), причем в понятие сложность входить и трудоемкость реализации такого решения.
W e b появился задолго до появления мобильных приложений. За это время он стал почти вездесущ. Но современная тяга к мобильности привела к тому, что страницы изначально создаваемые под десктопы начали становится адаптивными (responsive), а иногда этого не хватало и появлялись отдельные мобильные версии сайтов. Сейчас веб приложения бывают двух вариантов:
- посадочные страницы (лендинги) с информацией о продуктах и услугах (использование продуктов через отдельные мобильные приложения)
- полноценные веб приложения со сложным UI/UX и взаимодействием с пользователями
На оба вида веб приложений мобильный трафик все увеличивался. В итоге, у больших игроков (aka Google) появилось желание обеспечить пользователям возможность превращать веб приложения в “почти мобильные” приложения. Так и появились прогрессивные веб приложени aka Progressive Web App. Вот как Google описывает что такое PWA в своем гайде, посвященном PWA ([1])
Progressive Web Apps provide an installable, app-like experience on desktop and mobile that are built and delivered directly via the web. They’re web apps that are fast and reliable. And most importantly, they’re web apps that work in any browser. If you’re building a web app today, you’re already on the path towards building a Progressive Web App.
Отношение к PWA может быть разным, от крайне позитивного, как в статье компании IQUII [3], до настороженного. Киллер фичи PWA — это возможность превратить веб приложение в подобие мобильного, получив возможности
- сохранить иконку на мобильном устройстве
- работать оффлайн
- иметь доступ к части функций устройства
- возможности обновлять прогрессивное приложение без прохождения ревью в магазинах
Минусы тоже значительны:
- ограниченный функционал
- отсутствие в магазинах (Google Play и App Store)
С моей точки зрения PWA — это отличный способ проверить идею нового мобильного приложения, имея ограничения на команду, которая умеет разрабатывать только веб приложения. Также PWA можно использовать для улучшения UX на начальных этапах воронки, а именно на посадочных страницах — работа офлайн + расширенный доступ к функциям устройства по сравнению с обычным вебом может быть очень полезен. Но использовать PWA для развития стратегически важных приложений я бы не стал, если нет жестких ограничений на ресурсы.
На другом конце спектра находится нативная разработка мобильных приложений. В текущий момент это разработка под две основные платформы Android и iOS. Каждая из платформ имеет свою специфику, но в общем обладает схожим функционалом (подробнее про Native Mobile Development читайте в книге [2], где приводится сравнительный обзор функциональности и примеры). Написание приложений под эти платформы позволяет обеспечить наилучший UX, соответствующий актуальным гайдлайнам каждой из платформ, но писать код приложения придется дважды — под Android и под iOS.
Среди плюсов можно выделить следующие
- производительность решения
- полный доступ к функциональности мобильных устройств
- максимальная гибкость в разработке — вы ограничены только создателями оригинальных платформ
- нативный UX/UI
Минусы тоже есть:
- это дорого, даже дважды дорого
- повторная реализация логики на двух платформах и зачастую потребность синхронизации функциональности под разные платформы
Для того, чтобы не писать код дважды появились кросс-платформенные решения с знакомым слоганом “Write once, run anywhere”. Иронично, что этот слоган пригодился для того, чтобы заменить в том числе разработку на Java:) Хороший исторический обзор этих решений можно прочесть в статье [8] с забавным названием “Почему Flutter побеждает?”. Забавно название тем, что не ясно в чем именно и кого он побеждает. Среди актуальных кроссплатформенных решений можно выделить:
- React Native — кросс-платформенное решение от Facebook. Подробнее про него можно прочитать в книге [10]
- Xamarin — кросс-платформенное решение от Microsoft. Подробнее в книге [11]
- Flutter — кросс-платформенное решение от Google. Подробнее в книге [12], а также статьях [5] и [6]
Не вдаваясь в конкретные возможности каждого из приведенных выше решений, можно сказать, что каждое из них позволяет создавать решения под обе платформы сразу используя общую кодовую базу. Интересно, что все приведенные выше решения поддерживаются ИТ-гигантами, возможно, потому, что на поддержание и развитие таких решений требуются ресурсы. Каждое из кроссплатформенных решений имеет свои сильные и слабые стороны, которые неплохо освещены в статье [4], но основной плюс в том, что код действительно получается +/- кроссплатформенным и имеет неплохой доступ к функциональности мобильных приложений. А минусов достаточно много:
- ограничения в функциональности и иногда в производительности
- сложности с гибкостью и адаптивностью решения
- зависимость от вендора кросс-платформенного фреймворка
- не нативный UI/UX
В целом это решение достаточно качественное, но менее гибкое. Есть смысл его использовать, если есть фокус на развитии мобильных приложений, но нет ресурсов под обе платформы.
Есть еще один вариант реализации мобильного приложения — гибридный. И смешиваем мы в данном случае нативную разработку и web приложения. Основная мысль в том, чтобы часть функционала реализовать посредством рендера через WebView внутри нативного приложения. По сути в данном случае некоторая веб-страница открывается во встроенном браузере внутри приложения и пользователь может взаимодействовать с ней. Подробнее про возможности такой интеграции можно прочитать в мануале Anroid [9].
Обычно к такому решению можно придти из двух состояний
- если идти от веб приложения или PWA
- если идти от нативного приложения
В первом случае обычно основная функциональность внутри веба, а нативная только оболочка. Цель такого решения в том, чтобы сделать “полноценное” приложение, готовое к размещению в магазине приложений. Больше особых плюсов по сравнению с просто PWA и нет.
Во втором случае обычно основная функциональность внутри нативного приложения, но некоторые “избранные” features реализуют в вебе, а потом интегрируют через WebView. Здесь мотивация бывает разная, но среди наиболее частых:
- наличие реализованной feature в web’е и желание “почти бесплатно” получить ее в мобильном приложении
- наличие свободных ресурсов веб-разработчиков и отсутствие нативных
- наличие неважной функциональности, которую просто надо иметь внутри мобильного приложения
В пассиве данного решения имеем:
- смешивание разных технологий, которые надо совместно развивать и синхронно модифицировать, например, при редизайне
- худшие нефункциональные характеристики WebView части — нужен доступ в сеть, больше потребление ресурсов, сложный доступ к функциональности мобильного устройства и т.д.
Мы рассмотрели различные варианты разработки мобильных приложений. У каждого из них есть свои плюсы и минусы, но если принимать решение с точки зрения технологических и продуктовых инвестиций, то
- если надо испробовать идею, то проще всего начать с web’а + добавить PWA, а потом если нужны Google Play и App Store, то завернуть приложение в нативную оболочку
- если идея летит и есть ресурсы, то стартуем нативную разработку
- если идея летит, но писать дважды или даже трижды (если учитывать web отдельно) не хочется, то можно положиться на кросс-платформенный фреймворк типа React Native или Flutter, но надо помнить об их ограничениях
Более подробный анализ с точки зрения принятия стратегического решения есть в статье [7].
Читайте также: