#coroutines
На сайте для разработчиков от Google появились практики работы с
Coroutines. Давайте их рассмотрим.🔹нельзя хардкодить
Dispatchers. Особенно это касается работы с Coroutines во ViewModel. Google предлагает инжектить каждый диспетчер в отдельности и применять его в зависимости от контекста. Плюсом данного подхода является простота тестирования. Из практики добавлю сюда передачу не конкретного элемента, а обёртки с 3 основными
Dispatchers, которую можно переопределить для тестирования. На мой взгляд, такой подход удобнее.🔹suspend-функции должны быть безопасными для вызова из основного потока. Предлагается использовать для этого
withContext, где надо явно указать поток для выполнения функции. Хороший подход, но я не часто встречал его на практике.🔹
ViewModel должны быть ответственными за Coroutines. Довольно логичный паттерн: нельзя возвращать suspend-функцию во View, где запускать эту функцию и получать из неё какой-то результат. Правильнее будет использовать для этих целей Flow или LiveData.🔹не делайте видимыми изменяемые типы из
ViewModel, такие как MutableStateFlow или MutableLiveData. Это делается для того, чтобы избежать возможности отправки каких-то данных из View. 🔹слои бизнес-логики и данных должны возвращать или suspend-функции, или
Flow. Плюсую за эту рекомендацию, потому что разработчики часто протаскивают LiveData во все слои приложения, где её фичи вообще не используются.🔹избегайте
GlobalScope. Это затрудняет тестирование и debug приложения. Если вам нужно «пережить» текущий экран, то стоит задуматься о scope, который будет управляться приложением или другим копонентом, живущим дольше, чем текущий экран.🔹не забывайте про исключения. Обязательно стоит помнить о неуспешной работе suspend-функций и использовать для этого try-catch, хотя мне больше нравится
CoroutineExceptionHandler.