Согласно этой статье :
Модель представления должна представлять состояния для представления, а не только для событий.
Я использую повторноviewmodel, потому что мне нужны одни и те же данные для нескольких представлений , но я сомневаюсь, что они используют одни и те же данные, но отображают их по-разному .Как, например, если у меня есть список пользователей, в первом представлении отображаются их , во втором представлении используются данные для целей сортировки , в третьем представлении отображается метка , если список пользователей достиг определенного размера .
Если я только выставляю данные (список пользователей), и представление решает, что делатьэто, кроме того, что я нарушаю архитектуру, это также трудно проверить, потому что мне нужно смоделировать android, но я хочу только проверить, вызывается ли определенный метод, не имеет значения, как его отображает представление.
Так что я думаю о решении, как о создании класса State для каждого представления, которое использует модель представления, чтобы модель представления обновляла состояние, и теперь я могу легко проверить, изменяется ли состояние.
Моя проблема здесьчем больше представлений повторно использует модель представления, тем больше состояний для каждого вида, мне это тоже не кажется правильным, просто представьте, как метод изменяет все состояния, даже если одновременно может отображаться только 1 представление.
Создание отдельных моделей представления для каждого представления похоже на дублирование кода для меня, например: ResetPasswordView и CreatePasswordView, они оба имеют одинаковый процесс, почти одинаковое поведение, так почему бы не использовать повторно Viewmodel?... или я должен?Что мне здесь не хватает?
Редактировать (мое текущее решение):
Из того, что я сделал, я создал отдельные модели представления для каждого фрагмента / действия, потому что хотя они используют одни и те же данные, они представляют их по-разному .И, делая это, я могу выполнять модульные тесты для логики представления, потому что все манипуляции с данными (особенно для представления) происходят в модели представления.
Я делюсь моделью представления, но для целей навигации, пример - лучший способ объяснить это (я использую Koin здесь в качестве моей структуры зависимостей):
OnBoardingActivity :
class OnBoardingActivity {
var fullNameViewModel by viewModel<FullNameViewModel>()
private fun initViewModels() {
fullNameViewModel.stateShowEmail.observe(this, Observer {
// do navigate to email because that's the next screen/fragment after FullNameFragment
})
}
}
FullNameFragment :
class FullNameFragment {
var viewModel by sharedViewModel<FullNameViewModel>() // notice that I share the view model from the activity here to have only 1 instance
private fun initViews() {
RxTextView.textChanges(etFirstName)
.doOnNext { viewModel.setFirstName(it.toString()) }
.subscribe()
// ... set the other fields
}
private fun initViewModels() {
viewModel.stateValidationFirstName.observe(this, Observer {
when(it) { // validation
is RequiredValidation -> // show some error/validation message
else -> it is valid! remove any error/validation messages
}
})
}
}
FullNameViewModel :
class FullNameViewModel {
val stateValidationFirstName = MutableLiveData<Validation>() // some validation object
val stateShowEmail = SingleLiveEvent<Any>() // I'm using the hacky single live event here hehe
fun setFullName() {
// do the validations, some process and this can be easily test
// like: stateValidationFirstName = RequiredValidation()
stateShowEmail.call()
}
}