Увлекательно. Можно двухстороннее связывание прикрутить, ну да ладно. Мне просто интересно, где тут "все решает вью"?

Все решает вьюмодель. А вью интерпретирует данные из вм

Да, вот мне тоже так кажется

Вью модель говорит что показать, а вью говорит как. Лично я считаю что mvvm удобнее из-за меньшего количества методов. Сами посудите - юзер кликает на кнопку и надо поменять у элемента цвет.
MVP:
1. Создаем онкликлисенера во вью
2. Создаем метод презентера для обработки кликов
3. Создаем метод для интерфейса вью
4. Создаем метод для реализации вью
MVVM:
1. Создали метод онкликлисенер во вью модели.
2. Биндингом в xml привязали цвет элемента к обсерваблу

Ага, только перед этим написали десяток биндер адаптеров, потратив неделю на отлов багов и изучение ограничений библиотеки

Статью читали про недостатки мввм на Андроиде? Не зря ее Вася писал, мы много это обсуждали

Мввм только в теории хорош

А можно линк? 😔

А можно ссылку?

Статью читали про недостатки мввм на Андроиде? Не зря ее Вася писал, мы много это обсуждали

Спасибо, Артур)

Спасибо, Артур

Блог мобайлапа надо везде закрепить

И предложение, как это можно исправить: https://habr.com/company/mobileup/blog/326962/

Вижу такие статьи и начинаю думать, что хабр не помойка

Странно, что читал это, но не читал про МВВМ

👍

Прочитал статью, если отбросить то, какие названия использует автор, то суть статьи следующая: "я использую гибрид MVP и MVVM, а это неудобно, так как проявляются все боли MVP со смертью view, потому MVVM - говно". Да, тост надо показывать из кода view (глупо и неудобно это делать каким либо образом через xml), но вот только почему он связывает view с vm, через передачу интерфейса? Правильно делается просто: создается обсервабл, эвент от которого можно словить только один раз и подписываемся на него из вью. Пример такого обсервабла - SingleLiveData называется.