Как использовать gRPC-клиент в проекте на Kotlin Multiplatform Mobile

Привет! На связи команда разработчиков из Новосибирска.

Нам давно хотелось рассказать сообществу о том, как мы разрабатываем фичи в KMM-проектах, и вот на одном из них подвернулась хорошая нестандартная задача. На ней, помимо собственно решения задачи, продемонстрируем путь добавления новой фичи в проект. Также мы очень хотим продвигать мультиплатформу именно в среде iOS-разработчиков, поэтому бонусом делаем особый акцент на этой платформе.

В чем суть задачи

Обычно в мобильных проектах общение с бэкендом происходит по REST API и спецификация оформляется в swagger-файлах. При таком раскладе мы спокойно используем Ktor и нашу библиотеку moko-network, в которой используем плагин для генерации кода запросов и моделей ответов по Swagger‘у. В очень редких случаях требовалось дополнительно немного использовать WebSockets или Sockets.IO. Это решалось индивидуально на каждой платформе. Позднее мы сделали для этого библиотеку moko-sockets-io.

В этот раз ситуация была интереснее: помимо набора swagger-файлов мобильный API был представлен несколькими gRPC-сервисами, и нам сразу же захотелось сделать процесс работы с ними максимально комфортным и приближенным к работе с REST API.

В статье описан полный путь интеграции gRPC в мультиплатформенный проект, пройденный нашей командой. Он включает и создание проекта, и настройку фичи в проекте. Если вас интересует gRPC-специфичная часть и вы уже обладаете знаниями о мультиплатформе, то шаги 2, 3 и 4 можно пропустить.

Для интеграции мы сразу же начали искать готовые библиотеки. В идеале хотелось следующего:

уметь генерировать kotlin-классы для моделей сообщений в common-коде;
уметь генерировать kotlin-классы для gRPC-клиента в common-коде;
иметь из коробки реализации этих классов для iOS и Android;
уметь настраивать gRPC-клиент из общего кода: подставлять адрес сервера, заголовки авторизации.

На тот момент нашлась только одна библиотека для работы с gRPC, в которой KMM-часть была реализована и поддерживалась, — Wire от коллег из Square. Поэтому мы взяли ее и разобрались, что мы реально можем сделать:

Настроить генерацию KMM-кода для классов сообщений и для gRPC-клиента, должно даже на корутинах работать. Пример настройки плагина есть на сайте gRPC.
Из коробки есть реализация клиента для Android, которая под капотом использует OkHttp от этой же команды разработчиков. В клиенте есть возможность устанавливать параметры запросов, используя OkHttpClient.Builder.addInterceptor.
Из коробки нет реализации клиента для iOS, только интерфейс с заглушками.

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

Основной путь решения проблемы продемонстрируем на проекте Hello world, заодно покажем, как с нулевого состояния поднять проект на основе шаблона и добавить туда новую фичу. Основной упор будет на iOS-платформу. В качестве спецификации возьмем готовый пример из gprc-go. Все шаги будут сопровождаться коммитами в репозитории.

В итоге в статье мы рассмотрим:

подготовку тестового окружения (шаг 1);
создание новой фичи в проекте (шаги 2, 3, 4);
подключение wire-плагина к common-коду (шаг 5);
настройку модуля фичи из корневой фабрики (шаг 6);
генерацию и настройку gRPC-клиента для iOS (шаги 7, 8);
реализацию KMM-интерфейса через нативный gRPC-клиент (шаг 8);
проверку работы gRPC-клиента внутри фичи (шаг 9).

А также расскажем, что делать в Android-приложении.

Шаг 1. Подготавливаем тестовое окружение

Здесь все просто — берем из примера команды для установки сервера и клиента:

```  $ go get google.golang.org/grpc/examples/helloworld/greeter_client  $ go get google.golang.org/grpc/examples/helloworld/greeter_server  ```

Затем выполняем запуск в разных терминалах:

```  $ ~/go/bin/greeter_server  2022/02/13 20:04:13 server listening at 127.0.0.1:50051  2022/02/13 20:04:20 Received: world  ```  ```  $ ~/go/bin/greeter_client  2022/02/13 20:04:20 Greeting: Hello world  ```

Теперь терминал с клиентом нам не понадобится. Закрываем клиент, а сервер оставляем работать: вернемся к нему ближе к концу статьи.

Шаг 2. Стартуем новый MPP-проект

Мы в IceRock уже довольно давно для старта мультиплатформенных проектов используем свой шаблон и сейчас начнем с него же. Генерируем по нему проект на GitHub, импортируем всю папку в Android Studio или IDEA и смотрим, что для нас уже настроено.

В mpp-library/feature видим две готовые фичи — config и list:

Еще есть реализация доменной логики для них в отдельном пакете domain:

Связывающая их фабрика в корне пакета mpp-library:

Шаг 3. Добавляем новый модуль фичи

Для ускорения скопируем модуль config с новым именем. Например, grpcTest. Почистим от логики и переименуем файлы:

Содержимое новых файлов (коммит):

/model/GrpcTestRepository.kt — интерфейс доменной логики для фичи, предоставляется из корневой фабрики проекта SharedFactory:

```  package org.example.library.feature.grpcTest.model  interface GrpcTestRepository {  }  ```

/presentation/GrpcTestViewModel.kt — пустая вью-модель. Она наследуется от dev.icerock.moko.mvvm.viewmodel.ViewModel, поэтому имеет coroutine scope для выполнения асинхронных вызовов. Также в ней объявляем интерфейс событий, которые вью-модель может кидать на платформенную часть и принимаем диспетчер этих событий (eventsDispatcher) в качестве параметра:

```  package org.example.library.feature.grpcTest.presentation  import dev.icerock.moko.mvvm.dispatcher.EventsDispatcher  import dev.icerock.moko.mvvm.dispatcher.EventsDispatcherOwner  import dev.icerock.moko.mvvm.viewmodel.ViewModel  import org.example.library.feature.grpcTest.model.GrpcTestRepository  class GrpcTestViewModel(     override val eventsDispatcher: EventsDispatcher<EventsListener>,     private val repository: GrpcTestRepository  ) : ViewModel(), EventsDispatcherOwner<GrpcTestViewModel.EventsListener> {     interface EventsListener {     }  }  ```

/di/GrpcTestFactory.kt — фабрика вью-модели для фичи. Создается в корневой фабрике проекта SharedFactory. Там же решается, какой будет реализация репозитория. Методы фабрики вызываются с нативной платформы:

```  package org.example.library.feature.grpcTest.di  import dev.icerock.moko.mvvm.dispatcher.EventsDispatcher  import org.example.library.feature.grpcTest.model.GrpcTestRepository  import org.example.library.feature.grpcTest.presentation.GrpcTestViewModel  class GrpcTestFactory(    private val repository: GrpcTestRepository  ) {      fun createViewModel(          eventsDispatcher: EventsDispatcher<GrpcTestViewModel.EventsListener>,      ) = GrpcTestViewModel(          eventsDispatcher = eventsDispatcher,          repository = repository      )  }  ```

EventsDispatcher реализован здесь и нужен для гарантированной отправки событий на платформу. Для iOS это будет происходить по умолчанию на главной очереди. Для Android — в рамках главного цикла.

Также добавим путь до модуля фичи в settings.gradle.kts в корне проекта (коммит):

```  include(":mpp-library:feature:grpcTest")  ```

Подключим модуль фичи к модулю mpp-library в /mpp-library/build.gradle.kts (коммит):

```  ...  dependencies {  ...  commonMainApi(projects.mppLibrary.feature.grpcTest) //Чтобы видеть классы фичи в SharedFactory  ...  }  ...  framework {    ...    export(projects.mppLibrary.feature.grpcTest)  // Чтобы классы фичи попали в фреймворк для iOS    ...  }  ```

И не забываем переименовать пакет в AndroidManifest.xml (коммит):

```  <?xml version="1.0" encoding="utf-8"?>  <manifest package="org.example.library.feature.grpcTest" />  ```

Шаг 4. Пишем логику фичи

Функции клиента у нас очень простые: нужно будет инициировать запрос и показать на экране ответ. Для использования метода объявим его в GrpcTestRepository (коммит):

```  interface GrpcTestRepository {      suspend fun helloRequest(word: String): String  }  ```

Для отображения текста в алерте (текст успешного ответа от сервера или текст ошибки) добавим новое событие в EventsListener (коммит):

```  interface EventsListener {      fun showMessage(message: String)  }  ```

Для отправки запроса сделаем метод в GrpcTestViewModel, который будем вызывать с нативной стороны по какому-нибудь событию. Заодно покажем ошибку, если что-то пойдет не так (коммит):

```  fun onMainButtonTap() {      viewModelScope.launch {          var message: String = ""          try {              message = repository.helloRequest("world")          } catch (exc: Exception) {              message = "Error: " + (exc.message ?: "Unknown error")          }          eventsDispatcher.dispatchEvent { showMessage(message) }      }  }  ```

Общий код модуля фичи на этом готов, теперь нужна имплементация собственно grpc-запросов и наша вью-модель с нативной стороны.

Шаг 5. Подключаем генерацию моделей сообщений по proto-файлам

Для начала берем файл спецификации нашего клиента helloworld.proto и помещаем в папку /domain/src/proto:

Теперь нужно будет очень аккуратно подключить wire-плагин к доменному модулю. Все шаги из этого блока намеренно собраны в один коммит, чтобы при воспроизведении не потеряться.

Мы используем libs.versions.toml для версионирования зависимостей. С него и начинаем:

Добавляем версию wire в секцию [versions]:

``` # wire wireVersion = "4.0.0-alpha.15" ```

Добавляем библиотеки и плагин в секцию [libraries]:

``` # wire wireGradle = { module = "com.squareup.wire:wire-gradle-plugin", version.ref = "wireVersion"} wireRuntime = { module = "com.squareup.wire:wire-runtime", version.ref = "wireVersion"} wireGrpcClient = { module = "com.squareup.wire:wire-grpc-client", version.ref = "wireVersion"} ```

Затем цепляем сам плагин и настраиваем в /mpp-library/domain/build.gradle.kts:

Поскольку Wire хостится на jitpack.io, убедимся, что все плагины будут скачиваться в том числе и оттуда в /build-logic/build.gradle.kts:

``` repositories {     mavenCentral()     google()      gradlePluginPortal()     maven("https://jitpack.io") } ```

И здесь же сам плагин в dependencies:

``` dependencies {   ...   api("com.squareup.wire:wire-gradle-plugin:4.0.0-alpha.15") } ```

Далее работаем с domain-модулем, добавляем плагин в секцию plugins в /mpp-library/domain/build.gradle.kts:

```   ...   id("com.squareup.wire") } ```

Добавляем в секцию dependencies библиотеку клиента и рантайма:

```   ...   commonMainImplementation(libs.wireGrpcClient)   commonMainImplementation(libs.wireRuntime) }

Добавляем секцию wire в конец файла и синхронизируем проект:

``` wire {     sourcePath {       srcDir("./src/proto")     }     kotlin {         rpcRole = "client"         rpcCallStyle = "suspending"     } } ```

После синхронизации проекта появляется gradle-таска generateProtos:

Итоги ее выполнения можно найти в /mpp-library/domain/build/generated/source:

Здесь у нас довольно объемные сгенерированные классы для запроса (HelloRequest) и ответа (HelloReply) метода, интерфейс клиента (GreeterClient) и его gRPC-реализация (GrpcGreeterClient).

Забегая вперед: на Android мы используем все эти классы, на iOS — только классы сообщений.

Шаг 6. Объявляем MPP-интерфейс для gRPC-клиента

На текущий момент у нас есть сгенерированные модельки HelloReply и HelloRequest и интерфейс для репозитория конечной фичи GrpcTestRepository. Поскольку использовать сгенерированный готовый клиент в общем коде мы не сможем, нужно объявить его интерфейс, а реализовать по отдельности на платформах.

В нашем случае интерфейс gRPC-клиента будет выглядеть так:

``` interface HelloWorldSuspendClient {     suspend fun sendHello(message: HelloRequest): HelloReply } ```

Однако для iOS реализовать интерфейс с suspend-методами не получится, поэтому понадобится еще один интерфейс на callback‘ах:

``` interface HelloWorldCallbackClient {     fun sendHello(message: HelloRequest, callback: (HelloReply?, Exception?) -> Unit) } ```

И реализация, переводящая методы с callback‘ами в suspend-методы:

``` class HelloWorldSuspendClientImpl(     private val callbackClientCalls: HelloWorldCallbackClient ): HelloWorldSuspendClient {      //Пока что у нас в интерфейсе всего один метод, но на будущее очень пригодится generic-функция для конвертации, сразу реализуем ее     private suspend fun <In, Out> convertCallbackCallToSuspend(         input: In,         callbackClosure: ((In, ((Out?, Throwable?) -> Unit)) -> Unit),     ): Out {         return suspendCoroutine { continuation ->             callbackClosure(input) { result, error ->                 when {                     error != null -> {                         continuation.resumeWith(Result.failure(error))                     }                     result != null -> {                         continuation.resumeWith(Result.success(result))                     }                     else -> { //both values are null                         continuation.resumeWith(Result.failure(IllegalStateException("Incorrect grpc call processing")))                     }                 }             }         }     }      override suspend fun sendHello(message: HelloRequest): HelloReply {         return convertCallbackCallToSuspend(message, callbackClosure = { input, callback ->             callbackClientCalls.sendHello(input, callback)         })     } } ```

Размещаем все это там же, где генерировали модельки, в domain-модуле (коммит):

Теперь в общем коде осталось только принять на вход в SharedFactory реализацию этого интерфейса и передать на вход фабрики фичи.

Добавляем репозиторий как параметр в фабрику фичи GrpcTestFactory.kt (коммит):

``` class GrpcTestFactory(     private val repository: GrpcTestRepository ) {     fun createViewModel(         eventsDispatcher: EventsDispatcher<GrpcTestViewModel.EventsListener>,     ) = GrpcTestViewModel(         eventsDispatcher = eventsDispatcher,         repository = repository     ) } ```

Добавляем новое поле в конструкторы SharedFactory и сразу для кастомного конструктора используем suspend-обертку клиента:

``` class SharedFactory(     ...     helloWorldClient: HelloWorldSuspendClient ) {   //Специально для вызова со стороны iOS-платформы мы не используем аргумент со значением «по умолчанию» constructor(     ...     helloWorldCallbackClient: HelloWorldCallbackClient ) : this(     ...     helloWorldClient = HelloWorldSuspendClientImpl(helloWorldCallbackClient) ) ... ```

Создаем экземпляр этой фабрики, используем gRPC-клиент как репозиторий (коммит):

``` val grpcTestFactory = GrpcTestFactory(     repository = object : GrpcTestRepository {         override suspend fun helloRequest(word: String): String {             return helloWorldClient.sendHello(HelloRequest(word)).message         }     } ) ```

В общем коде все готово, осталось реализовать gRPC-клиент со стороны платформ.

Шаг 7. iOS: генерация классов gRPC-клиента

Для генерации классов возьмем библиотеку и генератор gRPC-Swift. Сначала поставим генератор, например через Homebrew:

``` brew install swift-protobuf grpc-swift ```

Затем нам понадобятся плагины к нему, устанавливаются через cocoapods:

``` pod 'gRPC-Swift-Plugins' ```

Если все прошло успешно, то оба плагина появятся по пути /ios-app/Pods/gRPC-Swift-Plugins/bin/, и теперь их можно использовать следующим образом:

Сделать папку для сгенерированных классов, например, /ios-app/src/generated/proto.
Находясь в корне проекта, вызвать команду для генерации классов сообщений:

``` protoc \ --plugin=./ios-app/Pods/gRPC-Swift-Plugins/bin/protoc-gen-swift \ --swift_out=./ios-app/src/generated/proto \ --proto_path=./mpp-library/domain/src/proto \ ./mpp-library/domain/src/proto/helloworld.proto ```

Находясь в корне проекта, вызвать команду для генерации методов gRPC-клиента:

``` protoc \ --plugin=./ios-app/Pods/gRPC-Swift-Plugins/bin/protoc-gen-grpc-swift \ --grpc-swift_out=./ios-app/src/generated/proto \ --grpc-swift_opt=Client=true,Server=false \ --proto_path=./mpp-library/domain/src/proto \ ./mpp-library/domain/src/proto/helloworld.proto ```

В итоге получаем два файла: helloworld.grpc.swift, helloworld.pb.swift. Добавляем их в проект и в Podfile саму библиотеку gRPC-Swift (коммит):

``` pod 'gRPC-Swift', '~> 1.7.0' ```

Шаг 8. iOS: реализация HelloWorldClient

Создаем новый класс, реализующий HelloWorldCallbackClient. Сделаем так, чтобы при его инициализации сразу создавались и сохранялись gRPC-канал и gRPC-клиент:

``` class HelloWorldCallbackBridge: HelloWorldCallbackClient {      private var commonChannel: GRPCChannel?     private var helloClient: Helloworld_GreeterClient?      init() {          //Настраиваем логгер         var logger = Logger(label: "gRPC", factory: StreamLogHandler.standardOutput(label:))         logger.logLevel = .debug          //loopCount — сколько независимых циклов внутри группы работают внутри канала (могут одновременно отправлять/принимать сообщения)         let eventGroup = PlatformSupport.makeEventLoopGroup(loopCount: 4)          //Создаем канал, указываем тип защищенности, хост и порт         let newChannel = ClientConnection             //Можно вместо .insecure использовать .usingTLS, но к нашему тестовому серверу так подключиться не выйдет, у него нет сертификата             .insecure(group: eventGroup)             //Логгируем события самого канала             .withBackgroundActivityLogger(logger)             .connect(host: "127.0.0.1", port: 50051)          //Работаем без дополнительных заголовков, логгируем запросы         let callOptions = CallOptions(             customMetadata: HPACKHeaders([]),             logger: logger         )          //Создаем и сохраняем экземпляр клиента         helloClient = Helloworld_GreeterClient(             channel: newChannel,             defaultCallOptions: callOptions,             interceptors: nil         )         //Сохраняем канал         commonChannel = newChannel     } ... ```

Реализуем метод sayHello(..):

``` func sendHello(message: HelloRequest, callback: @escaping (HelloReply?, KotlinException?) -> Void) {     //Проверяем что все идет по плану     guard let client = helloClient else {         callback(nil, nil)         return     }      //Создаем SwiftProtobuf.Message из WireMessage     var request = Helloworld_HelloRequest()     request.name = message.name      //Получаем экземпляр вызова     let responseCall = client.sayHello(request)     DispatchQueue.global().async {         do {             //В фоне дожидаемся результата вызова             let swiftMessage = try responseCall.response.wait()             DispatchQueue.main.async {                 //Конвертируем SwiftProtobuf.Message в WireMessage (объект ADAPTER умеет парсить конкретный класс WireMessage из бинарного формата)                 let (wireMessage, mappingError) = swiftMessage.toWireMessage(adapter: HelloReply.companion.ADAPTER)                 //Обязательно вызываем callback на том же потоке на котором фактически создался wireMessage, иначе получим ошибку в KotlinNative-рантайме                 callback(wireMessage, mappingError)             }         } catch let err {             DispatchQueue.main.async {                 callback(nil, KotlinException(message: err.localizedDescription))             }         }     } } ```

Функция toWireMessage(..) довольно простая: она берет представление SwiftMessage в виде NSData, переводит в KotlinByteArray и отдает на вход адаптеру:

``` fileprivate extension SwiftProtobuf.Message {     func toWireMessage<WireMessage, Adapter: Wire_runtimeProtoAdapter<WireMessage>>(adapter: Adapter) -> (WireMessage?, KotlinException?) {         do {             let data = try self.serializedData()             let result = adapter.decode(bytes: data.toKotlinByteArray())              if let nResult = result {                 return (nResult, nil)             } else {                 return (nil, KotlinException(message: "Cannot parse message data"))             }         } catch let err {             return (nil, KotlinException(message: err.localizedDescription))         }     } } ```

Самый примитивный вариант конвертации NSData в KotlinByteArray:

й примитивный вариант конвертации NSData в KotlinByteArray: ``` fileprivate extension Data {     //Побайтово копируем NSData в KotlinByteArray     func toKotlinByteArray() -> KotlinByteArray {         let nsData = NSData(data: self)          return KotlinByteArray(size: Int32(self.count)) { index -> KotlinByte in             let byte = nsData.bytes.load(fromByteOffset: Int(truncating: index), as: Int8.self)             return KotlinByte(value: byte)         }     } } ```

Сохраняем все и пробуем проверить прямо в AppDelegate (коммит):

``` @UIApplicationMain class AppDelegate: NSObject, UIApplicationDelegate {      var window: UIWindow?      let gRPCClient = HelloWorldCallbackBridge()      func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool {          let request = HelloRequest(name: "AppDelegate", unknownFields: OkioByteString.companion.EMPTY)         gRPCClient.sendHello(message: request) { reply, error in             print("Reply: \(reply?.message) - Error: \(error?.message)")         }         return true     } } ```

В терминале с запущенным сервером увидим сообщение:

``` 2022/02/17 23:51:28 Received: AppDelegate ```

А в консольном выводе XCode — много логов по состоянию канала и наш print:

```  2022-02-17T23:51:27+0700 debug gRPC : old_state=idle grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 new_state=connecting connectivity state change  2022-02-17T23:51:27+0700 debug gRPC : grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 connectivity_state=connecting vending multiplexer future  2022-02-17T23:51:27+0700 debug gRPC : grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 making client bootstrap with event loop group of type NIOTSEventLoop  2022-02-17T23:51:27+0700 debug gRPC : grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 Network.framework is available and the EventLoopGroup is compatible with NIOTS, creating a NIOTSConnectionBootstrap  2022-02-17 23:51:28.487194+0700 mokoApp[34306:38235189] [] nw_protocol_get_quic_image_block_invoke dlopen libquic failed  2022-02-17T23:51:28+0700 debug gRPC : connectivity_state=connecting grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 activating connection  2022-02-17T23:51:28+0700 debug gRPC : h2_settings_max_frame_size=16384 grpc.conn.addr_remote=127.0.0.1 grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 grpc.conn.addr_local=127.0.0.1 HTTP2 settings update  2022-02-17T23:51:28+0700 debug gRPC : connectivity_state=active grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 connection ready  2022-02-17T23:51:28+0700 debug gRPC : grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 old_state=connecting new_state=ready connectivity state change  2022-02-17T23:51:28+0700 debug gRPC : grpc.conn.addr_remote=127.0.0.1 grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 grpc_request_id=682A7FB4-4543-4609-A2C0-498B8A1445A3 grpc.conn.addr_local=127.0.0.1 activated stream channel  2022-02-17T23:51:28+0700 debug gRPC : grpc.conn.addr_local=127.0.0.1 grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 grpc.conn.addr_remote=127.0.0.1 h2_stream_id=HTTP2StreamID(1) h2_active_streams=1 HTTP2 stream created  2022-02-17T23:51:28+0700 debug gRPC : h2_active_streams=0 grpc.conn.addr_remote=127.0.0.1 grpc.conn.addr_local=127.0.0.1 grpc_connection_id=7E6AA2F6-3F83-4448-BEB1-F0C3C85131AD/0 h2_stream_id=HTTP2StreamID(1) HTTP2 stream closed  Reply: Optional("Hello AppDelegate") - Error: nil  ```

Шаг 9. iOS: проверяем работу gRPC-клиента внутри фичи

Пожалуй, не будем создавать новый контроллер. Добавим еще одну вью-модель на ConfigViewController, будем вызывать ее метод при появлении контроллера на экране и показывать алерт по событию из EventsListener (коммит):

``` override func viewDidLoad() {   ...   grpcTestViewModel = AppComponent.factory.grpcTestFactory.createViewModel(eventsDispatcher: EventsDispatcher(listener: self))   }  override func viewDidAppear(_ animated: Bool) {     super.viewDidAppear(animated)     grpcTestViewModel.onMainButtonTap() }  deinit {     //Очищаем вью-модель, чтобы сразу же остановить все корутины     viewModel.onCleared()     grpcTestViewModel.onCleared() } ...  extension ConfigViewController: GrpcTestViewModelEventsListener {     func showMessage(message: String) {         let alert = UIAlertController(title: "gRPC test", message: message, preferredStyle: .alert)         present(alert, animated: true, completion: nil)     } } ```

В результате при запуске приложения получаем:

Что делать для Android-приложений

С стороны Android-платформы можно использовать именно сгенерированный код Wire-клиента, дав ему экземпляр платформенного клиента. Выглядеть это может примерно так:

CommonMain-код:

``` class WireClientWrapper(grpcClient: GrpcClient): HelloWorldSuspendClient {     private val greeterClient = GrpcGreeterClient(grpcClient)     override suspend fun sendHello(message: HelloRequest): HelloReply {         return greeterClient.SayHello().execute(message)     } } ```

AndroidMain-код:

``` val grpcOkhttpClient = OkHttpClient().newBuilder()     .protocols(listOf(okhttp3.Protocol.HTTP_2, okhttp3.Protocol.HTTP_1_1))     .build()  val grpcClient = GrpcClient.Builder()     .client(grpcOkhttpClient)     .baseUrl("127.0.0.1:50051")     .build()  val helloClient = WireClientWrapper(grpcClient)  return SharedFactory(            settings = settings,            antilog = antilog,            newsUnitsFactory = newsUnitFactory,            baseUrl = BuildConfig.BASE_URL,            helloWorldClient = helloClient         ) ```

Итоги

Конечно, в приведенном решении еще много чего можно улучшить:

Заменить долгую реализацию копирования NSData в KotlinByteArray на использование memcpy.
Добавить в интерфейс клиента метод для установки значений заголовков запросов и пересоздавать канал и клиенты при его вызове.
Реализовать универсальный маппинг сообщений из WireMessage в SwiftMessage.

Да и сам шаблон проекта мы еще будем развивать и дорабатывать. Надеемся, что цель статьи достигнута, и всем осилившим будет интересно заниматься разработкой на KMM и особенно новыми нестандартными задачами в ней.

До новых встреч!

ссылка на оригинал статьи https://habr.com/ru/post/672278/