Комментарии 13
Ваш MainDispatcher для iOS вроде не будет работать во всех случаях. Воткните delay(...) в общем коде и наблюдайте, что ничего не работает. По крайней мере так раньше было.
Решение с 2 MainDispatcher подходит только для Ktor. В остальных случаях мы либо используем GlobalScope на главном диспетчере, либо делаем фриз-обертку с передачей блока в фон. Первый способ, на мой взгляд, проще и понятнее. И в случае его использования мы переносим переключение контекста уже в сервис. Похоже на то, как мы работаем с нативными сетевыми библиотеками.
Что-то как будто-то не то:) У вас все методы suspended и при этом же возвращают результаты через коллбэки? Но зачем? suspended и делались, чтобы избавиться от всего этого.
Да, можно было бы сделать и с возвратом из корутины, но тогда нужно было бы писать в методе напрямую:
suspended loadMovies(): MoviesList?{
return GlobalScope(uiDispatcher) {
networkService.loadData(url)
}
}
Но мне хотелось показать более инкапсулированное решение. Иначе бы нужно было бы делать еще один блок со scope с возвратом
В вашем случае не нужен скоуп внутри сервиса. Вообще достаточно делать только:
suspended loadMovies() = networkService.loadData(url)Ktor саму сетевую часть уже сделает на отдельном треде(причём как для iOS так и для Андроид).
Но для общего случая (без Ktor или с тем же delay), если я хочу выполнять работу в фоне, такой scope нужен.
Тогда посыл немного неверный. Вы не описали(или я не увидел)) в статье зачем нужно делать фоновую работу в отдельном скопе вне зависимости от внешнего(например UI) скоупа. Например, если у вас репозитории который хочет дождаться результата даже если внешний закенсилился. Но и в этом случае лучше рассматривать уже Flow(или другую реактивщину) вместо прямой передачи коллбэка.
Использовать Flow или нет, это выбор разработчика и дело вкуса. Как и применение реактивщины.
Ну а про то, для чего нужно разделять работу UI и работу в фоне, знает любой разработчик, знакомый с многопоточной работой для нативной разработки)
P.S. Поддержка suspend функций на уровне языка для меня остается секретом, для чего это сделали… не понятно.
Если её правильно приготовить, то она работает отлично и для больших приложений.
А так она пока ещё в Бете официально, и отсутсвие нормальной многопоточности в iOS это пока главная проблема и сложность.
Вообще KMM — вещь очень удобная, и единственный сложный момент в работе с ней — необходимость настройки своих Dispatchers. В остальном вы получаете большой выигрыш в работе и затратах на проект: бизнес-логику пишете один раз, весь код, независящий от UI, делаете общим и пишете один раз, нет расхождения в реализации DTO. Раздельно пишете только UI. Да, для кого-то необщий UI — это минус, но зато не надо тратить время на решение проблем с платформенно-специфическим кодом и вьюхами.
При выборе любой технологии для проекта стоит учитывать, как она будет взаимодействовать с уже выбранными или существующими решениями. Насколько дорогой в плане времени и усилий будет миграция с одной технологии на другую. Ну и опять же предпочтения разработчика. Вам не зашло KMM, я, к слову, не поклонник ReactNative.
Однако, если говорить про то, под какие проекты подойдет Kotlin Multiplatform, то в принципе этот SDK можно использовать в проектах любого размера. Главное, спроектировать корректно архитектуру, чтобы можно было работу параллелить, и не занимало много времени править и добавлять фичи. А так обычно кросс-платформу советуют на небольшие и/или несложные проекты, а вот средние и крупные, особенно с эдаким UI лучше писать на нативе.
Kotlin Multiplatform. Работаем с многопоточностью на практике. Ч.2