Обучение мобильной разработке
Различные способы сочетания разработки под iOS и Android вместе
Знание доступных подходов и фреймворков, позволяющих сделать разработку на iOS и Android масштабируемой.
Иногда назад я писал о том, как мы можем масштабировать мобильную разработку согласно статье ниже.
Здесь я делюсь несколькими вариантами, которые можно рассмотреть, если кто-то хочет разработать приложение, применимое как к iOS, так и к Android.
Проблемы, которые нужно решить
Перед этим давайте сформулируем проблему, которая у нас есть. Когда нам нужно разработать приложение, оно должно применяться как для платформ Android, так и для iOS.
К сожалению, в отличие от веб-разработки, разработка уникальна для каждой платформы. Следовательно, нам нужно иметь 2 разные команды разработчиков только для поддержки одного приложения.
Чтобы решить эту проблему, ниже приведены различные подходы, которые можно рассмотреть ...
Подход, ориентированный на сервер
Подход состоит в том, чтобы перенести как можно больше логики на сервер вместо того, чтобы иметь ее в приложении, якобы сделав приложение максимально «глупым» (но на самом деле это усложняет его, как указано в задаче 1 ниже).
Бонус этого подхода заключается в том, что оба приложения также могут получать постоянные изменения при развертывании изменений на сервере.
Вызовы
- Поскольку большая часть логики находится на сервере, приложениям необходимо будет кодировать возможность правильного перевода всех этих логик. Этот универсальный «переводчик» в приложении может оказаться сложной задачей.
- В отличие от Интернета, пользователи, загрузившие старую версию приложения, скорее всего, будут использовать ее в течение длительного времени, даже после того, как новая версия будет выпущена. Следовательно, нам потребуется «версия» сервиса, что усложняет поддержку.
Подход, ориентированный на веб-страницы
Этот подход использует доступные веб-страницы на has и помещает их в контейнеры веб-просмотра. Приложению просто нужно встроить соответствующий контроллер представления, чтобы содержать их и управлять навигацией.
Первое впечатление, что этот подход - убить трех зайцев одним выстрелом (то есть создать одну веб-страницу, и ее можно применить к Интернету, iOS и Android), что звучит как большая победа. Но есть проблемы ниже
Вызовы
- Веб-страница должна учитывать, что приложение будет к ней обращаться. Следовательно, ему может потребоваться по-другому обслуживать его представление для приложения (например, скрыть верхний / нижний колонтитул, избегать навигации пользователя в другом месте) и, следовательно, усложнить веб-разработку.
- Взаимодействие между нативным и веб-приложением всегда сложно. В приложении нам нужно будет добавить логику моста для взаимодействия между собственным кодом и веб-кодом (пример стороны Android здесь). Это усложняет поток.
- Взаимодействие с веб-просмотром не идеально на дисплее приложения, поскольку взаимодействие не такое плавное, как взаимодействие, изначально разработанное в приложении.
- Веб-просмотры хранят некоторые данные с помощью файлов cookie. Это можно рассматривать как хранение информации о пользователе, которая должна быть доведена до сведения пользователя как с использованием информации о пользователе.
Подход, основанный на локальном веб-просмотре
Этот подход аналогичен подходу к веб-странице, описанному выше, с той разницей, что Webview загружает веб-приложение локально для приложения.
Разработка заключается в создании веб-приложения один раз, которое может применяться как на iOS, так и на Android в качестве одного и того же источника.
Этот подход лучше, чем подход веб-страницы, поскольку веб-приложение может быть разработано специально для приложения. Однако у него есть аналогичные проблемы.
Вызовы
- Взаимодействие между нативным и веб-приложением всегда сложно. В приложении нам нужно будет добавить логику моста для взаимодействия между собственным кодом и веб-кодом (пример стороны Android здесь). Это усложняет поток.
- Взаимодействие с веб-просмотром не идеально на дисплее приложения, поскольку взаимодействие не такое плавное, как взаимодействие, изначально разработанное в приложении.
Реактивный подход
Один из подходов, который популярен среди тех, кто отдает предпочтение разработке в веб-стиле, но при этом умеет делать это для приложения. И что самое приятное, одна разработка применима к обеим платформам.
Для этого существует множество фреймворков, но наиболее популярными из них являются следующие два.
- 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
- потерять возможность использовать преимущества нативной разработки
Есть различные статьи, в которых упоминается их опыт по этому поводу.
- Airbnb отказался от React Native 2 года назад . (дополнительная информация: Coinbase заявляет об этом)
- Мой первый взгляд на Flutter (возможно, датированный)
- Плюсы и минусы Flutter от Altexsoft
Мультиплатформенный библиотечный подход
Ясно, что в приложениях есть части кода, зависящие от платформы (например, пользовательский интерфейс, специфические функции приложения), но есть также части логики приложений, которые являются общими для обеих платформ. Мы можем извлечь их в общую библиотеку, где она есть.
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, которые я упускаю, пожалуйста, просветите. Спасибо!