отсутсвие вменяемого дата биндинга по вашему исключает MVVM в андроиде?

Коллеги, делаю презентацию для выступления спикером. Тема "Чем MVVM лучше MVP?".  Я привожу там аргументы, собственно чем. Вот они:
1) Нет беготни туда-сюда и ссылки на вью в презенторе
2) В VM легче следить за состоянием вью
3) Это более актуальная архитектура представления
4) Легче в использовании (сомнительно)
5) Привожу в пример кейс где у меня 2 ViewPager-а с фрагментами, которые ведут себя синхронно. Один ViewPager - миниатюрка с графиками (листаемая), другой ViewPager - детализация все с теми же графиками только информации больше и графиков (листаемая). И делая фичу на MVP получилось 4 презентора (хотя это можно было бы избежать используя необязательные методы во View-интерфейсе. Но все равно кода получилось меньше, читабельность не пострадала, и вроде как ViewModel получилась более переиспользуемой. И не пришлось юзать колбэки между фрагментами, чтобы миниатюрка была на той же странице, например.
Если есть что добавить, или считаете что я не прав в некоторых пунктах, то накидывайте. Нужно понять насколько прочный и уместный у меня доклад!

тем что собственно есть состояние а не набор комманд

накину: в андроиде нет MVVM, и если вы под этим подразумеваете ViewModel из архитектурных компонентов, то в плане удобства использования они полностью эквивалентны MVP.

тем что собственно есть состояние а не набор комманд

>2) В VM легче следить за состоянием вью
чем легче?

да. Я это упомянул, скорее, в том смысле, что прежде чем сравнивать две вещи, надо дать им чёткое определение. Про MVP примерно ясно, а вот MVVM прям нужно чётко пояснить, что вы в это вкладываете.

Коллеги, делаю презентацию для выступления спикером. Тема "Чем MVVM лучше MVP?".  Я привожу там аргументы, собственно чем. Вот они:
1) Нет беготни туда-сюда и ссылки на вью в презенторе
2) В VM легче следить за состоянием вью
3) Это более актуальная архитектура представления
4) Легче в использовании (сомнительно)
5) Привожу в пример кейс где у меня 2 ViewPager-а с фрагментами, которые ведут себя синхронно. Один ViewPager - миниатюрка с графиками (листаемая), другой ViewPager - детализация все с теми же графиками только информации больше и графиков (листаемая). И делая фичу на MVP получилось 4 презентора (хотя это можно было бы избежать используя необязательные методы во View-интерфейсе. Но все равно кода получилось меньше, читабельность не пострадала, и вроде как ViewModel получилась более переиспользуемой. И не пришлось юзать колбэки между фрагментами, чтобы миниатюрка была на той же странице, например.
Если есть что добавить, или считаете что я не прав в некоторых пунктах, то накидывайте. Нужно понять насколько прочный и уместный у меня доклад!

+ вьюмодель ничего не знает о вью и может шариться

+ вьюмодель ничего не знает о вью и может шариться

чем это отличается от презентера?

Почему архитектурные компоненты это не мввм? Не могут им быть

если сделать mvp с одной командой то будет тоже самое

и часто, гхм, вы шарите VM на разные вьюхи? Чуть реже чем никогда? И если шарите и потом нужно одну вьюху изменить?) Так ты слона не продашь.

тогда это будет не классический mvp. Команда одна