Как стать автором
Обновить

Комментарии 13

Ваш MainDispatcher для iOS вроде не будет работать во всех случаях. Воткните delay(...) в общем коде и наблюдайте, что ничего не работает. По крайней мере так раньше было.

Да, вы правы. Спасибо. Дополнила статью потерявшимся куском.

Решение с 2 MainDispatcher подходит только для Ktor. В остальных случаях мы либо используем GlobalScope на главном диспетчере, либо делаем фриз-обертку с передачей блока в фон. Первый способ, на мой взгляд, проще и понятнее. И в случае его использования мы переносим переключение контекста уже в сервис. Похоже на то, как мы работаем с нативными сетевыми библиотеками.

Что-то как будто-то не то:) У вас все методы suspended и при этом же возвращают результаты через коллбэки? Но зачем? suspended и делались, чтобы избавиться от всего этого.

Suspended и callback друг другу не противоречат) Suspended бывают и Unit/Void. Этот же модификатор помечает функцию, как приостанавливаемую без блокировки потока, а не возвращающую значения.
Да, можно было бы сделать и с возвратом из корутины, но тогда нужно было бы писать в методе напрямую:

suspended loadMovies(): MoviesList?{
return GlobalScope(uiDispatcher) {
networkService.loadData(url)
}
}

Но мне хотелось показать более инкапсулированное решение. Иначе бы нужно было бы делать еще один блок со scope с возвратом

В вашем случае не нужен скоуп внутри сервиса. Вообще достаточно делать только:


suspended loadMovies() = networkService.loadData(url)

Ktor саму сетевую часть уже сделает на отдельном треде(причём как для iOS так и для Андроид).

Я этот случай описала здесь habr.com/ru/post/533864. И я прямо говорю в обеих статьях, что Ktor сам реализует асинхронную работу.
Но для общего случая (без Ktor или с тем же delay), если я хочу выполнять работу в фоне, такой scope нужен.

Тогда посыл немного неверный. Вы не описали(или я не увидел)) в статье зачем нужно делать фоновую работу в отдельном скопе вне зависимости от внешнего(например UI) скоупа. Например, если у вас репозитории который хочет дождаться результата даже если внешний закенсилился. Но и в этом случае лучше рассматривать уже Flow(или другую реактивщину) вместо прямой передачи коллбэка.

Посыл статей — дать информацию, как настроить работу с многопоточностью в Kotlin Multiplatform под несколько платформ, а не рассказать про все возможные способы реализации работы с Coroutines. В конце статей есть ссылка для тех, кто хочет копнуть глубже. И в конце первой статьи об этом говорится прямо.
Использовать Flow или нет, это выбор разработчика и дело вкуса. Как и применение реактивщины.
Ну а про то, для чего нужно разделять работу UI и работу в фоне, знает любой разработчик, знакомый с многопоточной работой для нативной разработки)
Странная мультеплатформа какая-то. Какой смысл, если на iOS уже начинаются танцы с бубнами, вроде freeze и реализаций собственного Dispatcher.Main для данной платформе. Помню, что так и не получилось мультиплатформу завести на 1.4 версии языка…
P.S. Поддержка suspend функций на уровне языка для меня остается секретом, для чего это сделали… не понятно.

Если её правильно приготовить, то она работает отлично и для больших приложений.
А так она пока ещё в Бете официально, и отсутсвие нормальной многопоточности в iOS это пока главная проблема и сложность.

На версии 1.4 она заводится сейчас без танцев бубнов. Попробуйте удалить вашу Android Studio и поставить версию 4.1.1. + плагин для KMM.

Вообще KMM — вещь очень удобная, и единственный сложный момент в работе с ней — необходимость настройки своих Dispatchers. В остальном вы получаете большой выигрыш в работе и затратах на проект: бизнес-логику пишете один раз, весь код, независящий от UI, делаете общим и пишете один раз, нет расхождения в реализации DTO. Раздельно пишете только UI. Да, для кого-то необщий UI — это минус, но зато не надо тратить время на решение проблем с платформенно-специфическим кодом и вьюхами.
К сожалению когда я «бодался» с KMM плагином, он у меня попросту крашился и SQLDelight не генерил нужные классы на версии 1.4, я понимаю, что через тернии к звездам, но из-за всей боли, xCode и проблемами на мелких, и средних проектах лучше писать на нативных решениях, имхо.
Даже пример от JetBrains?
При выборе любой технологии для проекта стоит учитывать, как она будет взаимодействовать с уже выбранными или существующими решениями. Насколько дорогой в плане времени и усилий будет миграция с одной технологии на другую. Ну и опять же предпочтения разработчика. Вам не зашло KMM, я, к слову, не поклонник ReactNative.
Однако, если говорить про то, под какие проекты подойдет Kotlin Multiplatform, то в принципе этот SDK можно использовать в проектах любого размера. Главное, спроектировать корректно архитектуру, чтобы можно было работу параллелить, и не занимало много времени править и добавлять фичи. А так обычно кросс-платформу советуют на небольшие и/или несложные проекты, а вот средние и крупные, особенно с эдаким UI лучше писать на нативе.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории