Блог

Главная - Вопросы по программированию - ViewModel с несколькими живыми данными и пользовательскими базами

ViewModel с несколькими живыми данными и пользовательскими базами

#android #kotlin #viewmodel #android-lifecycle #android-livedata

#Android #котлин #видовая модель #android-жизненный цикл #android-livedata #kotlin #viewmodel

Вопрос:

В настоящее время я экспериментирую с созданием viewmodel для Fragment. Мой подход заключается в использовании ровно одной viewmodel для одного фрагмента. У меня есть несколько вариантов использования для разных сценариев, например. для извлечения книг, для получения информации о книге. Все эти варианты использования происходят в одном фрагменте. Теперь я создал ViewModel с 3 независимыми друг от друга UseCases и 3 соответствующими LiveDatas.

Мне интересно, является ли это хорошей практикой. Есть предложения?

 class GetBooksViewModel
@Inject constructor(private val getBooksUseCase: GetBooksUseCase,
private val getBooksListsUseCase: GetBooksListsUseCase,
private val getInfoByBookUseCase: GetInfoByBookUseCase) :
    BaseViewModel() {

var books: MutableLiveData<java.util.LinkedHashMap<String, Book?>> = MutableLiveData()
var bookLists: MutableLiveData<List<BookList>> = MutableLiveData()
var infos: MutableLiveData<List<BookInfo>> = MutableLiveData()

//methods for fetching data will be below

fun getBooks() =
getChannelsUseCase() {
  it.either(::handleFailure, ::handleGetBooksUseCase)
}

private fun handleGetBooksUseCase(response: 
 java.util.LinkedHashMap<String, Channel?>) {
this.books.value = response
}

внутренний Фрагмент

 getBooksViewModel = viewModel(viewModelFactory) {
  observe(books, ::getBooks)
  observe(booksLists, ::getBooksLists)
  observe(bookInfos, ::doSomethingWithInfos)
  failure(failure, ::handleFailure)
}

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

1. Лично я считаю (и это всего лишь мнение, но), что название «UseCase» для задач выборки api довольно неудачно. Да, я знаю, что это взято из документа Android Clean Architecture от 2014 , но, с другой стороны, если вы подумаете о диаграмме пользовательских баз UML, то выборка данных — это не взаимодействие с пользователем, не функция, это просто деталь реализации. Я предпочитаю называть их «RemoteTask». Как только вы узнаете, что это просто «задача», а не то, что волнует пользователя, тогда вы сможете выяснить, что с ней делать и когда она должна выполняться

Ответ №1:

Вместо трех разных models и liveData подобных им можно использовать комбинированную модель :-

 class CombinedModel( var map : MutableLiveData<java.util.LinkedHashMap<String, Book?>, var books : MutableList<BookList>, var infos = MutableList<BookInfo> )

И живые данные могут быть похожи :-

 var response: MutableLiveData<CombinedModel>

Следовательно, только одна Observer логика может обрабатывать все три данных в activity