Как грузить данные во ViewModel?

Привет, Хабр!

Эта статья будет полезна для мобильных разработчиков, потому что в ней обсуждаются различные подходы к первоначальной загрузке данных во вьюмодели (Jetpack ViewModel) при ее использовании в проектах на Jetpack Compose (либо Compose Multiplatform).

Тема эта настолько холиварная, что один из самых влиятельных ютуберов в сфере Android-разработки Philip Lackner недавно посвятил ей отдельный как всегда очень качественный обзор. Эта статья — во многом ответ и дополнение к нему.

Итак, перейдем к сути.

Первый способ. LaunchedEffect

На своем карьерном пути я видел уже несколько проектов, где данные во вьюмодели грузятся следующим образом:

class MyViewModel: ViewModel() {   fun loadInitialData() {     viewModelScope.launch {       repository.loadData()       // ...     }   } }  // В Composable коде LaunchedEffect(Unit) {   viewModel.loadInitialData() }

На первый взгляд, он позволяет добиться желаемого. Однако есть один нюанс: в этом случае загрузка данных привязана к жизненному циклу рекомпозиции, а не к жизненному циклу экрана. В случае с Android это, конечно, не одно и то же. Если ваше приложение поддерживает альбомную ориентацию, то LaunchedEffect будет перезапущен при каждом повороте экрана. А это означает лишние запросы, а может быть и лишние элементы интерфейса (лоадеры, скелетоны, шиммеры) связанные с загрузкой данных. Звучит не очень, не правда ли?

(В скобках оговоримся, что, к огромному сожалению, далеко не все сегодняшние продовые Android-приложения поддерживают поворот экрана, но это на их совести. Спасибо Павлу Дурову за возможность вертеть Telegram и VK, как нам вздумается.)

Второй способ. Блок init

Итак, признаем, что LaunchedEffect не лучшее решение. Другой и один из самых распространенных способов загрузки данных — init блок во ViewModel.

class MyViewModel: ViewModel() {   suspend fun loadInitialData() {     repository.loadData()     // ... дальнейшая логика   }      init {     viewModelScope.launch {       loadInitialData()     }   } }

Этот способ отличается простотой и во многих случаях работает вполне правильно. Он не будет перезапущен при каждом повороте экрана, поскольку любой наследник ViewModel живет в ViewModelStore и переживает смерть Activity при повороте экрана.

Однако есть случаи, когда данный метод будет не вполне удобен. Представим себе классическую ситуацию, когда нам надо отобразить какие-либо данные списком, а затем детальный экран с редактированием и/или удалением одного из элементов списка:

navigation(route = "contacts_flow", startDestination = "contacts_list") {   composable("contacts_list") {     val viewModel: MyViewModel = viewModel() // либо koinViewModel, hiltViewModel, смотря какой у вас DI.     // ...   }    composable("contact/{contactId}") {     // ...   } }

В этом случае метод с init блоком не будет работать на экране списка контактов. Рассмотрим пошагово жизненный цикл загрузки:

1. Пользователь переходит на флоу "contacts_flow". Наша вьюмодель создается и вызывается init блок, загружаются данные.

2. Пользователь переходит на детальный экран контакта и, скажем, удаляет его.

3. Пользователь возвращается на экран "contacts_list" и видит удаленный контакт в списке, поскольку вьюмодель уже создана и init блок больше не отрабатывает.

Как решить эту проблему? Как загрузить данные при каждом появлении нашего экрана, но при этом игнорируя изменения конфигурации?

Чтобы ответить на этот вопрос, нужно вспомнить, в каком ViewModelStore сохраняется наша вьюмодель по умолчанию при вызове функции viewModel (то же самое будет справедливо и для koinViewModel). По умолчанию это LocalViewModelStore.current, то есть либо наше Activity, либо последний NavBackStackEntry в бэкстеке навигации.

Здесь и кроется наше решение: зная, что NavBackStackEntry обладает своим жизненным циклом, можно отследить его реальные появления на экране:

val LifecycleOwner?.isCreated: Boolean     get() = this?.lifecycle?.currentState == Lifecycle.State.CREATED  val LifecycleOwner?.isResumed: Boolean     get() = this?.lifecycle?.currentState == Lifecycle.State.RESUMED  val LifecycleOwner?.isStarted: Boolean     get() = this?.lifecycle?.currentState == Lifecycle.State.STARTED  @Composable fun NavBackStackEntry.OnAppear(controller: NavController, action: () -> Unit) {     LaunchedEffect(Unit) {         controller.visibleEntries.collectLatest { entries ->             val leavingEntry = entries.firstOrNull { it.isCreated }             val appearingEntry = entries.firstOrNull { it.isStarted || it.isResumed }             leavingEntry?.let {                 if (appearingEntry == this@OnAppear) action()             }         }     } }

В этой небольшой функции мы отслеживаем, нет ли экрана, который «покидает» отображение (то есть находится в состоянии CREATED), и если он есть, то вызываем лямбду action для нашей NavBackStackEntry.

Теперь можно использовать функцию для любого экрана, где нам нужна загрузка (или перезагрузка) данных при его появлении:

composable("contacts_list") { entry ->     val viewModel: MyViewModel = viewModel()      entry.OnAppear(navController) {       viewModel.loadInitialData()     }     // ... Дальше ваша Composable верстка и т. д.     ContactsListScreenUI(viewModel) }

Вот и все. Мы нашли полностью устраивающий нас способ загрузки данных: он не перезапускается при повороте экрана и перезапускается при возврате пользователя к экрану с другого экрана.

Напоследок отмечу, что способ, описанный Philip Lackner, то есть Flow<T>.onStart { loadInitialData() } , тоже имеет право на существование. В этом подходе используется пятисекундный таймаут коллектора (SharingStarted.WhileSubscribed(5000L) ), благодаря чему данные перезагружаются, если приложение было в фоновом режиме больше 5 секунд (правда с оговоркой, что вы используете collectAsStateWithLifecycle). Тем не менее, с задачей автоперезагрузки данных после возвращения с другого экрана такой фокус не справится, если пользователь посетил другой экран на менее, чем пять секунд. Из других минусов подхода — он предполагает использование Flow во вьюмодели (вдруг вы захотите все же использовать MutableState или, не дай бог, LiveData?), а также привязывает вас к collectAsStateWithLifecycle , недоступного в KMP и Compose Multiplatform.