Комментарии 4
Fragment/Activity - это скорее Controller с возможностью сохранять данные в бандл, а не ViewModel
Это сильно зависит с какой стороны смотреть и к какой части статьи комментарий.
В самом конце речь идет про сопоставление сущностей верстки с сущностями кода чернз привязку с помощью data binding, и с этой точки зрения они являются vm из шаблона.
Но конечно же, сам по себе такой сферический конь в вакууме не имеет смысла, т.к. гораздо логичнее сразу вынести из них все что возможно, чтобы оставить из максимально тонкими.
Пс. Во ViewModel от гугл так же можно сохранять состояние и это тогда тоже контроллер? Или о каком вообще контроллере идет речь?
я не говорил что контроллер должен сохранять состояние. я не согласился с этим тезисом: "Из этого следует, что в Android: View это XML, а Activity/Fragment/внезапно класс View — это ViewModel" , потому что эта сущность фреймворка помогает обрабатывать пользовательский ввод/нажатия на кнопки и позволяет реагировать на эти события, а также на события жизненного цикла. Даже если у тебя есть любого вида датабиндинг + XML + Fragment/Activity
Связку xml + код (activity/fragment/view) можно сделать различными способами.
Как прямое управление xml = mvp
val textView = findById... и другие способы получить саму View
textView.text = "Hello World"
Как привязку данных к xml = mvvm
val text : LiveData
val binding: TextBinding = DataBindingUtil.setContentView(this, R.layout.text)
text = "Hello World"
И в таком максимально прямом подходе, можно сказать, что Activity это Presenter/ViewModel в понятии шаблона. И это дает законные основания из далее следующих классов, которые с такого ракурса будут являться частью Model, делать огромные вундервафли которые и в сеть сходят и про базу данных знают.
НЕ НУЖНО ТАК ДЕЛАТЬ.
Пример выше это только теоретическая точка зрения на код и шаблоны, которая позволяет понять, что есть разные взгляды на одни и те же вещи.
И если вы делаете большие и уродливые Presenter/ViewModel, просто вспоминайте, что вы сейчас попутали понятия и используете Activity как сущность ViewModel, а класс ViewModel как часть Model.
Если же вы хотите чтобы ваш класс ViewModel оказался сущностью ViewModel, то он должен только проанализировать действие пользователя, попросить модель выполнить работу и переделать результат работы в данные для View.
Любая дополнительная логика превратит ваш клаcc ViewModel в часть Model.
Я специально даю такую интерпретацию шаблонов, чтобы заставить читателя задуматься над тем, что ViewModel должна быть тонкой и тупой.
Статья 2: Подробнее про MVVM