Обучение мобильной разработке

Различные способы сочетания разработки под iOS и Android вместе

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

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



Масштабирование мобильной разработки
Как мы можем практически масштабировать мобильную разработку? medium.com



Здесь я делюсь несколькими вариантами, которые можно рассмотреть, если кто-то хочет разработать приложение, применимое как к iOS, так и к Android.

Проблемы, которые нужно решить

Перед этим давайте сформулируем проблему, которая у нас есть. Когда нам нужно разработать приложение, оно должно применяться как для платформ Android, так и для iOS.

К сожалению, в отличие от веб-разработки, разработка уникальна для каждой платформы. Следовательно, нам нужно иметь 2 разные команды разработчиков только для поддержки одного приложения.

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

Подход, ориентированный на сервер

Подход состоит в том, чтобы перенести как можно больше логики на сервер вместо того, чтобы иметь ее в приложении, якобы сделав приложение максимально «глупым» (но на самом деле это усложняет его, как указано в задаче 1 ниже).

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

Вызовы

  1. Поскольку большая часть логики находится на сервере, приложениям необходимо будет кодировать возможность правильного перевода всех этих логик. Этот универсальный «переводчик» в приложении может оказаться сложной задачей.
  2. В отличие от Интернета, пользователи, загрузившие старую версию приложения, скорее всего, будут использовать ее в течение длительного времени, даже после того, как новая версия будет выпущена. Следовательно, нам потребуется «версия» сервиса, что усложняет поддержку.

Подход, ориентированный на веб-страницы

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

Первое впечатление, что этот подход - убить трех зайцев одним выстрелом (то есть создать одну веб-страницу, и ее можно применить к Интернету, iOS и Android), что звучит как большая победа. Но есть проблемы ниже

Вызовы

  1. Веб-страница должна учитывать, что приложение будет к ней обращаться. Следовательно, ему может потребоваться по-другому обслуживать его представление для приложения (например, скрыть верхний / нижний колонтитул, избегать навигации пользователя в другом месте) и, следовательно, усложнить веб-разработку.
  2. Взаимодействие между нативным и веб-приложением всегда сложно. В приложении нам нужно будет добавить логику моста для взаимодействия между собственным кодом и веб-кодом (пример стороны Android здесь). Это усложняет поток.
  3. Взаимодействие с веб-просмотром не идеально на дисплее приложения, поскольку взаимодействие не такое плавное, как взаимодействие, изначально разработанное в приложении.
  4. Веб-просмотры хранят некоторые данные с помощью файлов cookie. Это можно рассматривать как хранение информации о пользователе, которая должна быть доведена до сведения пользователя как с использованием информации о пользователе.

Подход, основанный на локальном веб-просмотре

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

Разработка заключается в создании веб-приложения один раз, которое может применяться как на iOS, так и на Android в качестве одного и того же источника.

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

Вызовы

  1. Взаимодействие между нативным и веб-приложением всегда сложно. В приложении нам нужно будет добавить логику моста для взаимодействия между собственным кодом и веб-кодом (пример стороны Android здесь). Это усложняет поток.
  2. Взаимодействие с веб-просмотром не идеально на дисплее приложения, поскольку взаимодействие не такое плавное, как взаимодействие, изначально разработанное в приложении.

Реактивный подход

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

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

  • React Native - от Facebook, с использованием обычного JavaScript-фреймворка
  • Flutter - от Google. Использование языков программирования Dart.

Что касается сравнения, посмотрите https://www.thedroidsonroids.com/blog/flutter-vs-react-native-what-to-choose-in-2021

Вызовы

Поскольку это дополнительная структура поверх собственной разработки приложений,

  • совместимость временами сомнительна, поскольку она оборачивается вокруг нативной (она может быть совместима с одним (iOS или Android), но не с другим)
  • он добавляет дополнительный размер к выпуску приложения, поскольку полагается на фреймворк
  • готовность, когда будет готова новая версия собственного App SDK
  • потерять возможность использовать преимущества нативной разработки

Есть различные статьи, в которых упоминается их опыт по этому поводу.

Мультиплатформенный библиотечный подход

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

Kotlin Multiplatform Mobile (KMM) - это один фреймворк, который позволяет перемещать общую логику / данные в библиотеку, написанную на Kotlin. С этим мы можем написать один раз и использовать его на обоих.

Я считаю, что мы также можем создать библиотеку C ++ как для iOS, так и для Android, но я не видел, чтобы какая-либо существующая структура позволяла применять их к обоим. Помимо написания C ++ и бриджа, это более требовательно.

У этого подхода много преимуществ.

  • Мы по-прежнему можем писать нативную часть приложения, используя нативный подход (например, SwiftUI, Jetpack Compose и т. Д.).
  • Он по-прежнему считается нативной частью кода, поскольку он хорошо встроен в приложение и хорошо взаимодействует с нативным кодом.
  • Он находится в приложении, поэтому нет необходимости рассматривать поддержку управления версиями, как подход общего кода на основе сервера.

Вызовы

Мультиплатформенный поток Kotlin пока еще не готов к работе. Когда я запускаю сценарий, он сообщает

Kotlin Multiplatform Projects are an Alpha feature. See: https://kotlinlang.org/docs/reference/evolution/components-stability.html. To hide this message, add 'kotlin.mpp.stability.nowarn=true' to the Gradle properties.

Тем не менее, я думаю, что это можно сделать стабильным и совместимым, поскольку он содержит только библиотеку общей логики.

TL; DR

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

Тем не менее, Apple и Google - две компании, которые конкурируют друг с другом в области технологий и разработки, поэтому заставить их перейти к единому стандартному процессу разработки будет нелегко, если вообще возможно.

Тем не менее, пока что с технической точки зрения мы наблюдаем их сближение, например

  • использование похожих друг на друга языков Swift и Kotlin.
  • направляемся к SwiftUI и JetpackCompose в качестве будущей разработки пользовательского интерфейса
  • продвижение с использованием реактивного потока Combine и Kotlin Flow

Хотя названия разные, принятая парадигма похожа. Это хороший знак.

P / S: Если вы знаете о других способах объединения работы iOS и Android, которые я упускаю, пожалуйста, просветите. Спасибо!