Привет! На связи снова Сергей Арсёнов, руководитель мобильной разработки в компании r_keeper. Я уже рассказывал, как и почему мы выбрали стек Kotlin Multiplatform Mobile + UI на Flutter для обновления нашего мобильного приложения для официантов. А теперь посмотрим, что из этого вышло на стадии продакшн (спойлер: все получилось, но проблем хватило).
Итак, мы выбрали технологический стек для нового b2b-приложения для официантов. Казалось, дальше будет просто: бери готовую структуру проекта из отлично работающего тестового приложения и добавляй необходимый функционал… Но нет.
Связь логики и представления
Из тестового проекта мы взяли схему, по которой бизнес-логика инкапсулируется в виде некоего SDK с набором public-методов. По сути для слоя представления этот SDK является «черным ящиком», с которым можно взаимодействовать только через методы и получать / отправлять данные.
Поскольку платформенная часть — это своего рода прокси между KMM SDK и Flutter UI, ей незачем знать про сущности и другие особенности реализации. Поэтому для передачи объектов из КММ во Flutter и назад мы выбрали сериализацию / десериализацию в JSON, благо в Kotlin это работает практически «из коробки», без доработки data-классов. В Dart, к сожалению, все устроено не так удобно, но для экономии сил можно использовать online-генераторы классов из JSON вроде этого или этого.
В итоге наш платформенный прокси получает вызовы из одной части приложения и транслирует их в другую часть, передавая в обе стороны лишь сериализованные сущности — json-строки и базовые типы данных. Важно, что при изменении или добавлении методов в протокол общения эти платформенные части остаются неизменными.
В отличие от тестового проекта, в рабочей версии пришлось использовать подписки на потоки данных. Kotlin умеет отправлять эти данные через flow, а Flutter — слушать их через eventChannel. Но между ними находится еще и платформенная часть, работающая как прокси.
Тут мы наткнулись на первую сложность. В Android-версии все было прекрасно — для нее не проблема работать с flow- и suspend-методами SDK из платформенной части. Но когда мы полностью описали весь интерфейс, сделали рабочую версию под Android и попытались собрать то же самое под iOS, выяснилось, что в Swift flow недоступны. Пришлось рефакторить наш SDK и его работу с платформой: теперь в нем нет suspend- и flow-методов, а подписка на потоки данных из бизнес-логики осуществляется, для совместимости, через колбеки.
Ниже приведу пример кода для обеих платформ, который позволяет общаться Flutter- и KMM-частям, возможно, кому-то этот плод наших изысканий будет полезным
Код для Android
class MainActivity: FlutterActivity() { private val CHANNEL = "mobwaiter/platform" private val CONNECT_CHANNEL = "mobwaiter/connect_channel" //создание объекта SDK и подстановка туда необходимых платформо-зависимостей private val gateway: MobwaiterSDKGateway = MobwaiterSDK( firebaseAnalyticsFactory = FirebaseAnalyticsFactory(context), driverFactory = DatabaseDriverFactory(context), httpClientFactory = HttpClientFactory(), xmlToJsonConverterFactory = XmlToJsonConverterFactory() ).gateway override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) //Инициализация каналов для связи флаттера с нативным андроидом val binaryMessenger = flutterEngine?.dartExecutor?.binaryMessenger val connectChannel = EventChannel(binaryMessenger, CONNECT_CHANNEL) val methodChannel = MethodChannel(binaryMessenger, CHANNEL) //обработчик, делающий передачу вызова от флаттер в КММ methodChannel.setMethodCallHandler{ call, result -> gateway.processCall(call.method, call.arguments, CallHandlerImpl(result) ) } //передача колбэка, позволяющего вызывать методы во флаттер из КММ gateway.setCallbacks(CallbackHandlerImpl(methodChannel)) } override fun onDestroy() { super.onDestroy() gateway.destroy(); } } //Позволяет возвращать результаты из KMM-части во флаттер class CallHandlerImpl( private val callResult : MethodChannel.Result ) : CallHandler { override fun success(result: Any?) = callResult.success(result) override fun error(errorCode: String?, errorMessage: String?, errorDetails: Any?) = callResult.error(errorCode,errorMessage, errorDetails) } //Позволяет из KMM вызывать во Flutter методы с аргументами class CallbackHandlerImpl( private val methodChannel : MethodChannel ) : CallbackHandler { override fun invokeMethod(method: String, arguments: Any?) { methodChannel.invokeMethod(method, arguments) } }
Код для iOS
import UIKit import Flutter import shared @UIApplicationMain @objc class AppDelegate: FlutterAppDelegate { private var sdk: MobwaiterSDK!; private var gateway: MobwaiterSDKGateway!; override func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? ) -> Bool { //создание объекта SDK и подстановка туда платформо-зависимостей sdk = MobwaiterSDK( firebaseAnalyticsFactory: FirebaseAnalyticsFactory(), driverFactory: DatabaseDriverFactory(), httpClientFactory: HttpClientFactory(), xmlToJsonConverterFactory: XmlToJsonConverterFactory() ); gateway = sdk.gateway; //инициализация каналов для связи нативной iOS части с Flutter let controller : FlutterViewController = window?.rootViewController as! FlutterViewController let mobwaiterChannel = FlutterMethodChannel(name: "mobwaiter/platform", binaryMessenger: controller.binaryMessenger) //обработчик, делающий вызов от флаттер в КММ mobwaiterChannel.setMethodCallHandler({ (call: FlutterMethodCall, result: @escaping FlutterResult) -> Void in let callHandler = CallHandlerImpl(resultHandler: result) self.gateway.processCall(method: call.method, arguments: call.arguments, callHandler: callHandler) }) //передача в КММ колбэка, позволяющего делать вызовы во флаттер self.gateway.setCallbacks(callback: CallbackHandlerImpl(mobwaiterChannel: mobwaiterChannel)) GeneratedPluginRegistrant.register(with: self) return super.application(application, didFinishLaunchingWithOptions: launchOptions) } } class CallHandlerImpl : CallHandler{ let resultHandler : FlutterResult init(resultHandler : @escaping FlutterResult) { self.resultHandler = resultHandler } func error(errorCode: String?, errorMessage: String?, errorDetails: Any?) { resultHandler(FlutterError(code: errorCode!, message: errorMessage, details: errorDetails)) } func success(result: Any?) { resultHandler(result) } } class CallbackHandlerImpl : CallbackHandler{ let mobwaiterChannel : FlutterMethodChannel init(mobwaiterChannel : FlutterMethodChannel){ self.mobwaiterChannel = mobwaiterChannel } func invokeMethod(method: String, arguments: Any?) { mobwaiterChannel.invokeMethod(method, arguments: arguments) } }
При передаче данных из Flutter в KMM нужно внимательно следить за соответствием типов данных: то, что без проблем передается из Flutter в Android, не обязательно так же нормально попадет из Flutter в iOS, например, arraylist. С этим нам тоже пришлось помучиться.
Работа с бэкендом
Еще одной проблемой стало древнее, как слеза мамонта, XML API. Официальная кроссплатформенная библиотека kotlinx.serialization не поддерживает XML, а найти XML-десериализатор для Kotlin Native невозможно — все библиотеки собраны исключительно для Kotlin / JVM.
Поэтому сначала, чтобы не терять темп, мы вынесли десериализацию в платформенную часть KMM, а потом своими силами портировали в кроссплатформенную часть XML-JSON-парсер, написанный для Android / JVM.
Работа с базой данных
В этой части каких-то особенностей работы именно с кроссплатформой мы не заметили. Разве что пришлось отойти отойти от привычных по Room ORM, и писать sql-запросы и схемы таблиц вручную. SQLDelight умеет генерить по этому описанию объекты и методы, но просто описать объекты и автоматически получить работу с БД не выйдет. Также, то, что SQLDelight по умолчанию не поддерживает Foreign Keys стало для нас сюрпризом. Мы потратили немало времени, пока разобрались, что происходит и почему не работает каскадное удаление.
Вот что нужно прописать в Android-части кода KMM при инициализации драйвера, чтобы ключи заработали:
actual fun createDriver(): SqlDriver { return AndroidSqliteDriver(AppDatabase.Schema, context, "rkmobwaiter.db", callback = object : AndroidSqliteDriver.Callback(AppDatabase.Schema) { override fun onOpen(db: SupportSQLiteDatabase) { db.execSQL("PRAGMA foreign_keys=ON;"); } }) }
Реализация представления
Интересной задачей стала разработка архитектуры Flutter-части. Я уже упоминал, что Flutter предполагает декларативную верстку, то есть написание Dart-кода в виде дерева виджетов (view), состоянием которых нужно как-то управлять. Официальная документация Flutter рекомендует использовать или так называемые Stateful-widgets, которые сами в себе хранят свое состояние, или пакет provider — некую реализацию классического шаблона «Наблюдатель».
В тестовом приложения, пока UI-часть была небольшой, эти схемы работали нормально, но по мере роста реального приложения они начали превращать Dart-код в нечитаемую кашу. Выходом стало использование пакета flutter_bloc, вариации знакомого многим веб-разработчикам Redux-подхода от Felix Angelov. Пришлось полностью отрефакторить уже написанный код, но оно того стоило. Код структурировался достаточно для того, чтобы новым разработчикам можно было сказать «Делай так» и наращивать функционал приложения без костылей и потери управляемости.
Сам bloc со своими State и Events нам показался немного избыточным, там очень много шаблонного кода. Мы используем так называемые cubit - вариацию bloc. Там присутствуют те же самые state для вьюшек, но вместо events просто вызываются методы в этом кубите. Это показалось нам более удобным
Вообще, хочется заметить, что официальные плагины Flutter и Dart для Android Studio пока довольно кривые — они могут внезапно перестать подсвечивать синтаксис или осуществлять переход между классами по Ctrl. Работать одновременно с KMM и Flutter неудобно, в одном SDK через два плагина — невозможно. Поэтому разработчикам приходится держать открытыми сразу два окна с приложением: в первом код подсвечивает Flutter-плагин, во втором — Kotlin. Неудобно, но жить можно.
И последний момент: импорт библиотек в actual-классах иногда приходится делать наугад, без подсказки.
Что мы поняли?
Вот какие выводы мы сделали.
Flutter удобен и приятен. Начать писать рабочий код всего через пару недель изучения — не проблема для нормального разработчика. Плюс по нему очень много документации, есть большое сообщество — все проблемы можно решить.
С KMM иногда сложно из-за его новизны, минимума документации и небольшого количества кроссплатформенных библиотек. При их использовании всегда есть шанс наткнуться на проблему, которая не описана ни на Stack Overflow, ни в issues к репозиторию на GitHub.
Kotlin и его coroutines чудесны — код пишется влет.
Обойтись только знанием Flutter и Kotlin не выйдет — нужно разбираться и в нативных платформах. Как минимум, придется научиться писать код Swift и собирать приложения в Xcode. Впрочем, это разовые задачи — достаточно хотя бы одного такого специалиста в команде.
Выбранная связка реально экономит ресурсы: мы смогли довести проект с нуля до стадии MVP на iOS и Android за 3 месяца, а если бы API был не XML и адаптирован под мобильные приложения, управились за 2,5. По нашим оценкам, написание аналогичных версий под NativeUI заняло бы почти в два раза больше человеко-часов.
Плавность и отзывчивость работы приложения на выбранной связке вполне удовлетворительная, а проблемы, которые мы пару раз выловили, оказались нашими же ошибками в коде.
Найти программистов не сложнее, чем под нативные проекты — подойдет любой грамотный мобильный разработчик. Правда, новизна стека может испугать — из-за этого у нас на собеседованиях отпали несколько кандидатов.
Наш первый опыт разработки на связке KMM + UI на Flutter в итоге был признан успешным, так что теперь мы планируем переводить и другие мобильные проекты r_keeper на этот стек.
Спасибо, что прочитали. В рамках статьи было сложно вместить все моменты и тонкости, которые нам встретились, поэтому буду рад ответить на вопросы, если что-то оказалось недостаточно раскрыто или осталось непонятно.
