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

Учтите следующее: вы разработчик Android, у вас нет опыта работы со Swift, Dart, Xamarin и React Native. Не возражаете ли вы создать приложение для платформ Android и iOS в течение 3 месяцев?

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

За прошедшие годы появились многообещающие альтернативы для создания многоплатформенных приложений, такие как Flutter, React Native, .Net Maui, Native Script, Kotlin Multiplatform Mobile и т. д. Каждая из этих платформ надежна для разработки многоплатформенных приложений и обеспечивает хорошо построенную мост, который позволит вам плавно переключаться между платформами.

Однако нативный разработчик Android должен быть знаком либо с Kotlin, либо с Java. В настоящее время разработчикам Android крайне важно перейти с Java на Kotlin, чтобы следовать рекомендуемым передовым методам разработки для Android. Kotlin не только прост и эффективен в использовании, но и имеет большое будущее. Другими словами, мы можем сказать, что это действительно такой мост, который предлагает своим «ходокам» многоцелевое назначение.

Я не буду здесь говорить о преимуществах Kotlin для Android-разработки. Вместо этого мы сосредоточимся на предложениях Kotlin для мультиплатформенной разработки, которые в настоящее время находятся в статусе Alpha. Несмотря на статус, мое исследование Kotlin Multiplatform Mobile привело к удивительным результатам.

Общая логика

Во-первых, способность делиться логикой — вот почему нам нужно обратить внимание на будущее Kotlin Multiplatform Mobile.

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

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

В папке commonMain создается общая логика, а папки androidMain и iosMain используются для логики actual для каждой платформы.

Ktor и SQLDelight в настоящее время являются основным оружием, используемым для связи с API приложения и локальной базой данных.

Поскольку обе зависимости имеют разные конфигурации сборки для каждой платформы, они встроены в androidMain и iosMain. Таким образом, как показано на следующем рисунке, функция actual из createDriver(), которая используется для создания локальной базы данных, не имеет тела метода. Они будут запускать тело метода по-разному для каждой платформы, которая вызывается с помощью функции expect.

Следующие expect функции запускаются после вызова его фактического метода (в данном случае createDriver()) shared построителя базы данных.

Декларативный пользовательский интерфейс

Предоставление Jetpack Compose, основанного на Kotlin, в качестве декларативного пользовательского интерфейса — действительно крутая идея.

Что здесь круто, так это то, что те, кто разрабатывает пользовательский интерфейс Android с помощью Jetpack Compose, по своей сути учатся кодировать с помощью SwiftUI.

В результате разработчикам на Kotlin не потребуется много времени для изучения SwiftUI и разработки пользовательского интерфейса iOS, поскольку они имеют дело с основными рабочими процессами декларативного пользовательского интерфейса. Удивительно, не так ли?

//Jetpack Compose (Android)
@Composable
fun MainScreen(){
    Text("Hello World")
}
//SwiftUI (iOS)
struct MainScreen: View{
    var body: some View{
        Text("Hello Wrold")
    }
}

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

Ниже представлен превью моего пользовательского интерфейса проекта Kotlin Multiplatform Mobile, разработанного не более чем за 3 месяца, с примечанием, что у меня вообще нет опыта работы со Swift.

На предварительном изображении выше мы можем видеть, как пользовательский интерфейс обеих платформ выглядит одинаково, несмотря на разные фреймворки. Суть в том, что пока области пользовательского интерфейса можно проектировать, декларативная разработка пользовательского интерфейса Jetpack Compose или SwiftUI может сделать их похожими друг на друга.

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

На следующем рисунке показан результат реализации Google Map API внутри декларативного подхода к пользовательскому интерфейсу (Jetpack Compose и SwiftUI).

Вот как UIKit помогает реализовать Google Map API в SwiftUI. Пользовательский интерфейс, представляемый UIKit, может быть различным в зависимости от того, какие типы представления мы собираемся показать.

Другими словами, он играет роль в том, как Android View помогает Jetpack Compose отображать представление, которое в настоящее время не поддерживается.

В приведенном ниже коде представление Android играет роль в том, как пользовательский интерфейс, представленный UIKit, помогает SwiftUI отображать API Карт Google.

Это всего лишь пример того, как Jetpack Compose предоставляет альтернативу для поддержки любой неподдерживаемой конфигурации представления, такой как представление на основе XML.

Заключение

Наконец, интересно работать с общей логикой, и нам просто нужно использовать Kotlin Multiplatform Mobile в качестве моста, который позволит каждой платформе вызывать свои необходимые коды.

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

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