введение в гибридные технологии разработки мобильных приложений
Разработка гибридных мобильных приложений
Писал уже статью о сравнении разработки нативных приложений и гибридных, теперь собралась критическая масса вопросов про гибридные приложения и выбора инструментов, поэтому давайте разберемся в концептуальных отличиях.
Еще пожалуй опишу свой опыт, чтобы был очевиднее ход моих мыслей. Я ранее 5 лет в роли ведущего программиста разрабатывал мобильные приложений под заказ на iOS и воспитал 8 программистов на iOS, которые также программировали мобильные приложения.
Учить разрабатывать мобильные приложения на iOS крайне долго, чтобы выйти на достойный уровень уходит 4-6 месяцев. Само собой кандидатов достойных к обучению крайне мало.
Если говорить о своем опыте разработки, то это:
И основное что долгое время держало именно в разработке нативных приложений: «приложение работает быстро». За счет обмена с сервером посредством API, эти данные кэшируются и используются повторно.
Это преимущество тает в динамичных сервисах, где данные все равно нужно запросить с сервера, чтобы они были актуальны. Например список активных заказов, нельзя показать список из кэша, некоторые заказы уже через секунду могут быть не актуальны.
Ну и тут вопрос «что если будет задержка отображения данных на 2-е секунды», критично ли это для бизнеса? Нет, не критично! Бизнес ценит гибкость, экономичность, а не крутой код.
Когда мы показали нашим первым пользователям наш полуфабрикат для создания сервиса поиска исполнителей, мы ожидали шквал недовольства медленной загрузкой, но нет… речи о зажержке и не было, народ требовал наращивать функционал. Тут мы сделали вывод что для бизнеса важны другие факторы, нежели наши программисткие замашки.
Нужны универсальные инструменты. Быстрая адаптируемость программиста. Чтобы на одном проекте мог все реализовать один программист, и серверную часть, и мобильные приложения. Это экономит кучу времени, нет ни обсуждения интерфейса передачи данных между сервером и приложением, ни как спроектировать базу данных, чтобы соответствовало логике приложения, ни грабли наоборот. Все сконцентрировано в одних руках, это очень удобно.
Давайте разберем варианты реализации гибридных мобильных приложений.
Смысл тот же что и в Xamarin, только создание элементов экрана происходит в процессе его открытия на мобильном телефоне, интерпретируя скрипты на JS. Идея в том чтобы посредством языка JavaScript используя биндинги вызывать любые нативные компоненты, тем самым реализовывать нативное приложение, с соответсвующим быстродействием. Минусы: нужно изучать JS классы и методы для реализации мобильного приложения.
Реализация на языке html + js вызовы плагинов нативных функций. Что важно наиболее простая адаптация для вебщиков, т.к. по сути создается мобильный сайт. Из минусов: грамоздкость оболочки, за счет совместимости с древними версиями iOS и Android. Адаптирован на работу с сервером по API, файлы верстки лежат в ресурсах приложения.
Можно сказать что это тот же Phonegap, только если срезать с него 90% древних наростов и хранить файлы не в ресурсах приложения, а на сервере. Одно из главных преимуществ, любой нативщик добавит те или иные функции на ваш вкус. Например вам нужно в фоновом режиме GPS обрабатывать особым образом, а результат отправлять на сервер. Плюсы: все просто, любой веб разработчик пишет на php/html мобильный сайт, дополнительно нужно по итогу расставить несколько js функций, например, нативные переходы между экранами, получение gps или считывание QR кода с камеры телефона.
В реакте, кордове и ксамарине есть отличная особенность, приложения по сути являются автономными приложениями со своим кэщем, а возможно и базой данных из которой можно брать данные в том иили ином случае, например при отсутствии интернета.
Но это и порождает серьезные минусу на мой взгляд:
Мы выбрали вариант с читым webView, добавили необходимые нам JS функции, которые работают с нативными функциями. В верстке мы используем Bootstrap, а в роли серверной части и админки используем 1С-Битрикс. Тем самым у нас есть унифицированная выборка и запись данных от bitrix framework, которую программист в комплексе с остальными тонкостями может освоить за неделю. Понятное управление данными для админа сервиса буквально с небольшими настройками уже после установки. Один программист управляет всеми процессами создания приложения. Использование компонент и разделение визуальной части и работу с данными позволяет распараллелить разработку над одним проектом до 5-и программистов, для ускорения производства.
Каждый при выборе руководствуется базисом имеющихся знаний, мы выбрали более распространенный вариант, чтобы максимально просто (за неделю) было переучить вебщика.
Как выбрать мобильную кросс-платформу в 2021 году
Новый развивающийся бизнес зачастую в первую очередь ориентируется на мобильные технологии: социальные сети, необанкинговые решения, приложения для электронной коммерции, такси и другие. Новый бизнес ориентирован на экономическую эффективность, поэтому переход на кросс-платформенность для разработки мобильного приложения кажется правильным выбором. Посмотрим, что будет в 2021 году и как выбрать правильную технологию.
Познакомимся с Женей
Евгения — солюшн-архитектор. Она должна решить, как построить новое мобильное приложение для изучения английского языка не носителями: людьми из Турции, Италии или России. Давайте посмотрим, как Женя подходит к этой задаче.
Приложение должно включать в себя богатую анимацию, уметь воспроизводить и записывать аудио, показывать видео с субтитрами, а также статические и динамические изображения.
В компании — владельце приложения также ожидают, что разработкой будет заниматься единая команда — как для Android- и iOS-приложений, чтобы свести к минимуму усилия по передаче знаний и максимизировать скорость команды. В будущем также планируют запустить веб-приложения. А еще в компании хотели бы упростить будущий найм.
Прогрессивные веб-приложения
Женя начинает свои исследования. Она гуглит «мобильные веб-приложения» и находит статью. В ней упоминаются «Прогрессивные веб-приложения» (PWA). Что это такое?
Прогрессивные веб-приложения — это, по сути, веб-сайты, которые используют специальные API для доступа к определенным возможностям устройства. Эти API позволяют получить доступ к памяти на устройстве, интегрируются с Push Notifications (на Android) и, что самое важное, работать в отдельной вкладке браузера. Еще их можно установить на устройство «иконкой», как настоящее приложение. Звучит неплохо! Давайте посмотрим на плюсы и минусы PWA:
Русские Блоги
введение
В этой статье подробно объясняется, что такое разработка гибридных приложений, концепции, принципы, различия, почему вы должны изучать гибридные приложения, несколько способов разработки гибридных приложений, а также конкретные конфигурации среды и руководства по питанию.
1- Что такое разработка гибридных мобильных приложений
Что такое разработка мобильных приложений: популярным считается использование технологии разработки веб-сайтов.
(HTML + CSS + JS) каким-то образом перенесен в разработку мобильных приложений для использования. Такой способ использования технологии веб-разработки для разработки мобильных приложений называется гибридным мобильным приложением. Развитие!
Что касается разработки мобильных приложений, вам необходимо знать несколько концепций:
Собственная разработка: английское слово (NativeApp) означает способ разработки мобильных приложений с использованием инструментов, платформ разработки и поддерживающих языков, официально предоставляемых IOS и Android;
Гибридная разработка: (HybirdApp) заключается в использовании существующей интерфейсной технологии, HTML + CSS + JS, а затем с помощью некоторой связанной технологии компиляции пакетов, вы можете разработать приложение для мобильного телефона, установить его на мобильный телефон для использования;
Что такое Приложение: Приложение (аббревиатура от Application), что означает: устанавливаемое приложение;
Разница между приложением и Интернетом:
Существенная разница между двумя типами разработки приложений:
2- Почему вы должны изучать разработку гибридных приложений
С точки зрения программистов:
Анализируйте с точки зрения предприятия: (Выберите правильный метод разработки мобильных приложений) Введение в гибридные технологии разработки мобильных приложений
1. Общие методы разработки приложений на рынке
3- Как компании выбирают правильный способ разработки собственного приложения
4- Процесс разработки проекта на предприятии
Дизайн по запросу, разработка по дизайну
1. Angular.js и Ionic
2. Vue.js и Weex
3. React.js и React-Native
Angular, Vue и React являются интерфейсными фреймворками. Когда мы разрабатываем гибридные приложения, мы используем только [базовый синтаксис] этих трех фреймворков;
6-интерфейсная гибридная среда разработки приложений
7- Разница между фреймворками разработки
8- Используйте HBuilder для создания приложений Android (онлайн)
Преимущества: нет необходимости настраивать среду разработки локально; работа удобна, и программист не заботится о процессе упаковки, и процесс упаковки прозрачен для нас;
Недостатки: программисты редко вмешиваются в процесс упаковки; исходный код отправляется на облачный сервер, есть риск утечки основного кода проекта;
9- Использование переменных окружения
Функция: сконфигурируйте инструменты или приложения, которые должны использоваться глобально, в переменной среды Path, и вы можете легко запустить их в форме командных строк, в которых вы хотите запускать эти приложения;
10-Конфигурация среды разработки мобильных приложений [Ключевые моменты]
10.1- Установите последнюю версию java jdk
10.2- Установить среду Node.js
10.3- Установить среду C ++
В большинстве случаев операционная система поставляется со средой C ++, и нет необходимости вручную устанавливать среду C ++;
Если при запуске выдается сообщение об ошибке, вам необходимо вручную установить среду C ++ в Visual Studio;
10.4- Установить среду Git
10.5- Установить среду Python
10.6- Настройка среды Android
11-ReactNative быстрая упаковка
, а затем выполните указанную выше команду;
Встряхните телефон, чтобы вызвать окно свойств настройки, нажмите «Dev settings», а затем нажмите Debuug server host. Появится окно настройки IP-адреса, введите IP-адрес и номер порта 8081, например 192.168.1.111:8081
Обзор кросс-платформенных фреймворков мобильной разработки
По работе мне неоднократно приходилось сталкиваться с выбором подходящей технологии для мобильной разработки. Ниже я попробовал собрать и классифицировать основные фреймворки по используемым подходам, достоинствам и недостаткам.
Если какая-то моя информация некорректна, или устарела — комментарии приветствуются.
Общие минусы кросс-платформенной разработки
Ограниченная поддержка платформы
Любой кросс-платформенный фреймворк — это слой абстракции над нативной платформой и позволяет обращаться только к тем её возможностям, которые прямо поддерживаются фреймворком.
В большинстве случаев есть возможность расширить поддержку возможностей платформы путём написания нативных плагинов к фреймворку, но в некоторых случаях это может существенно усложнить разработку. Свежий пример из нашумевшей статьи AirBnb — React Native, который в данный момент не умеет “из коробки” работать с 64-битными Android-библиотеками.
Также нужно обратить внимание, что нативные плагины и основной код кросс-платформенного приложения, как правило, исполняются в разных процессах и взаимодействие между ними может вызывать проблемы с производительностью. Для работы с датчиками, или SQLite это, обычно, не проблема, но если вы используете, скажем, библиотеку OpenCV в качестве нативного плагина и начинаете кидать видео между ней и основным приложением, замедление может быть существенным.
Ограниченное предложение на рынке труда
Во-первых, само наличие разработчиков зависит от распространённости фреймворка. Найти людей под React Native может быть даже легче, чем нативных разработчиков, а, например, с Flutter намного сложнее.
Насколько нужно учитывать этот фактор — зависит от задач. Большинство стартапов могут не обращать на него внимания, поскольку изучение новой технологии является скорее бонусом для действующих и потенциальных сотрудников. С другой стороны, крупный бизнес вынужден учитывать рынок труда.
Риски поддержки
Считается, что вероятность того, что поддержка кросс-платформенного фремворка закончится — намного выше, чем вероятность того же события в отношении мобильной ОС.
На самом деле вопрос довольно сложный. ОС могут закрываться так же, как фреймворки (пример Windows Phone совсем свеж). Кроме того, внутри нативной разработки могут отдельные технологии также могут закрываться и иногда код на кросс-платформенных фреймворках обладает большей живучестью.
Пример этого есть в области игр и мультимедиа — Apple собирается отправить на покой технологию OpenGL в своих ОС и всем, кто писал нативные 3D-приложения придётся их полностью переписывать для выпуска новых версий. В то же время для тех, кто пользовался кросс-платформенными игровыми движками (например Unity), обновление не потребует никаких дополнительных усилий.
Основные направления
Гибридная разработка, HTML+JavaScript
Технически, приложения гибридного типа представляют собой HTML-страницу, отображаемую во встроенном браузере. В целом для этого подхода фреймворк не обязателен, но Cordova обеспечивает набор плагинов для доступа к возможностям платформы, из-за чего как правило используют её.
Основные плюсы
Минимальная стоимость разработки
Гибридный подход позволяет переиспользовать не только навыки разработчиков, но и код, написанный для веб-сайтов.
Возможность интеграции веб-элементов
Количество библиотек для HTML/JS заметно превосходит количество таковых для нативных приложений. Из интересного, сюда относятся, например, Google Analytics, или богатый выбор рекламных сетей.
Основные минусы
Невысокая производительность
Сам по себе современный JavaScript использует JIT-компиляцию, хорошо оптимизирован и работает быстро, но построение интерфейса на основе DOM-дерева — не очень эффективный процесс. Использование современных JS-фреймворков даёт дополнительный уровень нагрузки. Для слабых телефонов и/или при активном использовании интерактивных элементов, это может быть проблемой.
“Ненативное ощущение”
Это довольно неформальный, но очень важный пункт. Сайт в браузере реагирует на жесты и отображается немного не так, как мобильное приложение. Наиболее заметный элемент этого ощущения, задержку 300ms при нажатиях, Cordova решает, но многие другие детали остаются.
Проблема браузерной совместимости
На старых версиях Android (до версии 5), WebView был частью платформы и не обновлялся автоматически. Соответственно, использовать современные возможности браузеров в гибридных приложениях на этих устройствах не получится.
Как следствие, гибридные приложения либо ограничивают минимальную версию Android (оставляя за бортом около 13% устройств на данный момент), либо включают WebView в код приложения (проект CrossWalk), увеличивая размер приложения на несколько десятков мегабайт.
Предназначение
Быстрое создание одноразовых приложений. При наличии существенного бюджета на разработку, гибридным подходом, как правило, брезгуют.
Основные фреймворки
Основой всех основных гибридных фреймворков является Cordova, предоставляющая доступ к нативным плагинам. PhoneGap предоставляет инструментарий для сборки поверх Cordova, в то время как Ionic представляет собой фреймворк и набор компонентов для построения в ней пользовательских интерфейсов.
Нативный UI, общий код
Важно отметить, что при таком подходе, пользовательский интерфейс и бизнес-логика выполняются в разных процессах, взаимодействующих через мост (“bridge”). С этим связан ряд минусов подхода.
У этого подхода есть несколько вариантов реализации.
Классификация по работе исполняемого кода
Компилируемый код
Xamarin использует язык C#, компилируя его в нативный код платформы. В целом, такой подход обеспечивает достаточно небольшой размер приложения и достаточно высокую скорость работы.
Интерпретируемый язык с JIT-компиляцией
Большинство фреймворков этого подхода используют JavaScript для обработки бизнес-логики.
Классификация по способу описания интерфейса
Нативные инструменты
Xamarin не только использует нативные компоненты интерфейса, но и описывает их в формате, принятом для каждой платформы.
Универсальные элементы интерфейса
Xamarin Forms и Appcelerator используют собственный набор виджетов, который преобразуется в подходящие компоненты интерфейса каждой платформы.
Разный интерфейс для разных платформ, но общий подход
React Native использует обёртки вокруг нативных компонентов интерфейса. Соответственно, интерфейс описывается для каждой платформы отдельно, но способ описания един.
Основные плюсы
Полностью нативный интерфейс
Во-первых, внешний вид и “ощущение” от приложения полностью совпадают с нативными приложениями.
Во-вторых, это позволяет использовать в приложениях библиотеки нативных интерфейсов. Использовать нативную рекламу (Native Ads), ориентированную на мобильные приложения, в других подходах не получится. Правда и для этого подхода набор соответствующих библиотек очень ограничен. Я знаю только о поддержке Facebook Native Ads в React Native.
Возможность переиспользования квалификации разработчиков
Основные минусы
Ограничение возможностей интерфейса, или дополнительные затраты на раздельную разработку
Формат этого минуса зависит от классификации фреймворка по способу описания интерфейса:
Xamarin позволяет использовать почти все возможности платформ, но приходится тратить много времени на интерфейсы для каждой платформы. В итоге трудозатраты становятся ненамного меньше, чем при нативной разработке.
Xamarin Forms и Appcelerator позволяют описывать интерфейсы только один раз, но работают с сильно ограниченным подмножеством нативной функциональности (не больше, чем минимальное пересечение множеств возможностей каждой платформы, если быть формальным).
React Native находится посредине, совмещая оба недостатка, но в менее выраженной форме.
Производительность взаимодействия с интерфейсом
Здесь вступает в игру фактор исполнения интерфейсов и бизнес-логики в разных процессах. Когда нужно обмениваться через мост большими объёмами информации с высокой скоростью (сложная анимация с высокой частотой), в данном подходе могут возникать сложности.
Утечки памяти
Утечки памяти могут возникать в любом приложении, но с большинством стандартных ситуаций отлично справляются сборщики мусора.
Проблема кросс-платформенных приложений с нативным интерфейсом опять в том, что они выполняются в двух процессах, имеющих раздельные сборщики мусора. Если объект бизнес-логики ссылается на объект интерфейса, этот объект интерфейса не является мусором, т.к. на него есть ссылка из моста. Если объект интерфейса ссылается обратно на объект бизнес-логики, они не будут считаться мусором даже если больше никаких ссылок на них не будет.
Шансы встретить проблему и её масштаб напрямую зависят от приложения. Если в нём активно создаются и удаляются объекты, связанные с интерфейсом (как в бесконечном скроллинге) вероятность утечки вырастает. Если эти объекты большие (например изображения), вырастает влияние утечки.
Собственно, эта проблема присутствует и при работе с нативными плагинами, которые тоже выполняются в отдельном процессе. Но там, в большинстве случаев, либо нет такого интенсивного манипулирования большими объектами, либо взаимодействие идёт в строго процедурном подходе, без перекрёстных ссылок.
Предназначение
Приложения с полностью нативным интерфейсом, особенно при наличии специалистов в смежных технологиях.
Основные фреймворки
React Native
Имеет поддержку Facebook и использует подход самого популярного JS-фреймворка React, за счёт чего очень популярен. Недавняя статья об отказе AirBnb от React Native наделала много шума, но если осознавать риски, может быть очень эффективным решением.
Xamarin
Помимо основного подхода имеет библиотеку Xamarin.Forms, которая позволяет эффективно и кроссплатформенно проектировать простые интерфейсы. Активно поддерживается Microsoft. При работе с ASP.NET на сервере позволяет дополнительно съэкономить определённый объём работы за счёт использования общих классов бизнес-логики на сервере и в мобильном приложении.
NativeScript
Сделан по образцу React Native для разработчиков, владеющих другими JS-фреймворками (Angular и Vue.js). Менее популярен, но имеет ряд более современных решений в архитектуре.
Собственный UI, общий код
Этим подходом пользуются почти все игровые движки, но они находятся за рамками данной статьи.
Принцип данного подхода — приложение использует собственный код и собственную отрисовку пользовательского интерфейса.
Основные плюсы
Высокая производительность интерфейсов
По сути, приложение, самостоятельно рисующее свой интерфейс, выполняет те же операции, что ОС в нативном интерфейсе. В теории оно может быть даже быстрее, т.к. нет переключения между процессом и ядром, но на практике другие факторы влияют на скорость отрисовки конкретного интерфейса, играют намного большую роль.
“Дизайнерские интерфейсы”
Нативные приложения пользуются готовыми компонентами интерфейса и имеют некоторые ограничения в том, что с ними можно сделать. В свою очередь, приложения, сами рисующие свой интерфейс, не имеют таких ограничений и могут свободно смешивать готовые элементы с индивидуальной отрисовкой.
Основные минусы
Данные минусы актуальны только для приложений, имитирующих стандартный интерфейс ОС. Как уже говорилось, для дизайнерских интерфейсов и игр данный подход является оптимальным.
Размер приложения
Приложения с таким подходом вынуждены нести с собой код для отрисовки всех элементов интерфейса, включая условно стандартные. Это сказывается как на размере приложения при установке, так и на оперативной памяти при работе.
Если первую проблему можно минимизировать эффективным Tree Shaking (как это делают последние версии Flutter), то по оперативной памяти эти приложения стабильно проигрывают нативным. Впрочем, эта проблема характерна и для других кросс-платформенных фреймворков.
Ненативный интерфейс
По умолчанию, приложение выглядит одинаково на всех платформах, что может создавать дискомфорт для пользователей. Для решения этих проблем используются темы, но создать ощущение полностью нативного приложения они не могут.
Но есть и более крупный минус — с таким подходом сложнее всего использовать сторонние элементы интерфейса, созданные для нативных приложений (включая упомянутые ранее Native Ads).
Предназначение
Приложения общего пользования, особенно с дизайнерским интерфейсом.
Основные фреймворки
Flutter
Flutter продвигается компанией Google как основной фреймворк кросс-платформенной разработки и основа интерфейса их будущей ОС Fuscia. Пока фреймворк очень молод (в стадии Release Preview) и не очень распространён, но быстро набирает популярность. Использует язык Dart (с компиляцией в нативный код).
Имеет все плюсы и минусы молодости — продуманную архитектуру с учётом ошибок предшественников, но достаточно ограниченную экосистему.
QT Mobile
Пользуется популярностью у разработчиков десктопного QT. При разработке может использоваться JavaScript. Без поддержки крупных компаний не пользуется особой популярностью.
Ещё один не очень популярный фреймворк, который интересен, в первую очередь тем, что это единственный фреймворк в списке, который использует язык Python. Для разработчиков, знакомых только с этим языком (а таких много в некоторых областях информационных технологий), это может иметь решающее значение.
Мобильная разработка: native, cross-platform, hybrid, web …
May 24, 2020 · 6 min read
Мобильные приложения давно являются мейнстримом для удаленного обслуживания клиентов и предоставлению сервисов. Они активно вытесняют полнофункциональные веб приложения во многих категориях. Это обусловлено разными причинами, среди которых главной является динамическая природа нашего времени, когда все требуется делать быстро и на бегу — мобильный всегда под рукой, а вот полнофоматный компьютер доступен гораздо реже.
В этой статье я попробую рассмотреть различные варианты реализации мобильных приложений или чего-то похожего на них. Вот схема того, что мы обсудим в этой статье.
На схеме эти варианты представлены на шкале Complexity/Functionality (Сложность реализации/Доступная функциональность), причем в понятие сложность входить и трудоемкость реализации такого решения.
Web и PWA
W e b появился задолго до появления мобильных приложений. За это время он стал почти вездесущ. Но современная тяга к мобильности привела к тому, что страницы изначально создаваемые под десктопы начали становится адаптивными (responsive), а иногда этого не хватало и появлялись отдельные мобильные версии сайтов. Сейчас веб приложения бывают двух вариантов:
На оба вида веб приложений мобильный трафик все увеличивался. В итоге, у больших игроков (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 — это возможность превратить веб приложение в подобие мобильного, получив возможности
Минусы тоже значительны:
С моей точки зрения PWA — это отличный способ проверить идею нового мобильного приложения, имея ограничения на команду, которая умеет разрабатывать только веб приложения. Также PWA можно использовать для улучшения UX на начальных этапах воронки, а именно на посадочных страницах — работа офлайн + расширенный доступ к функциям устройства по сравнению с обычным вебом может быть очень полезен. Но использовать PWA для развития стратегически важных приложений я бы не стал, если нет жестких ограничений на ресурсы.
Native development
На другом конце спектра находится нативная разработка мобильных приложений. В текущий момент это разработка под две основные платформы Android и iOS. Каждая из платформ имеет свою специфику, но в общем обладает схожим функционалом (подробнее про Native Mobile Development читайте в книге [2], где приводится сравнительный обзор функциональности и примеры). Написание приложений под эти платформы позволяет обеспечить наилучший UX, соответствующий актуальным гайдлайнам каждой из платформ, но писать код приложения придется дважды — под Android и под iOS.
Среди плюсов можно выделить следующие
Cross-platform development
Для того, чтобы не писать код дважды появились кросс-платформенные решения с знакомым слоганом “Write once, run anywhere”. Иронично, что этот слоган пригодился для того, чтобы заменить в том числе разработку на Java:) Хороший исторический обзор этих решений можно прочесть в статье [8] с забавным названием “Почему Flutter побеждает?”. Забавно название тем, что не ясно в чем именно и кого он побеждает. Среди актуальных кроссплатформенных решений можно выделить:
Не вдаваясь в конкретные возможности каждого из приведенных выше решений, можно сказать, что каждое из них позволяет создавать решения под обе платформы сразу используя общую кодовую базу. Интересно, что все приведенные выше решения поддерживаются ИТ-гигантами, возможно, потому, что на поддержание и развитие таких решений требуются ресурсы. Каждое из кроссплатформенных решений имеет свои сильные и слабые стороны, которые неплохо освещены в статье [4], но основной плюс в том, что код действительно получается +/- кроссплатформенным и имеет неплохой доступ к функциональности мобильных приложений. А минусов достаточно много:
В целом это решение достаточно качественное, но менее гибкое. Есть смысл его использовать, если есть фокус на развитии мобильных приложений, но нет ресурсов под обе платформы.
Web и native
Есть еще один вариант реализации мобильного приложения — гибридный. И смешиваем мы в данном случае нативную разработку и web приложения. Основная мысль в том, чтобы часть функционала реализовать посредством рендера через WebView внутри нативного приложения. По сути в данном случае некоторая веб-страница открывается во встроенном браузере внутри приложения и пользователь может взаимодействовать с ней. Подробнее про возможности такой интеграции можно прочитать в мануале Anroid [9].
Обычно к такому решению можно придти из двух состояний
В первом случае обычно основная функциональность внутри веба, а нативная только оболочка. Цель такого решения в том, чтобы сделать “полноценное” приложение, готовое к размещению в магазине приложений. Больше особых плюсов по сравнению с просто PWA и нет.
Во втором случае обычно основная функциональность внутри нативного приложения, но некоторые “избранные” features реализуют в вебе, а потом интегрируют через WebView. Здесь мотивация бывает разная, но среди наиболее частых:
В пассиве данного решения имеем:
Итого
Мы рассмотрели различные варианты разработки мобильных приложений. У каждого из них есть свои плюсы и минусы, но если принимать решение с точки зрения технологических и продуктовых инвестиций, то
Более подробный анализ с точки зрения принятия стратегического решения есть в статье [7].