"B" может делать GET и класть в репу или "A", когда на нее переходят, может делать GET, зависит от логики приложения.

а если одновременно открыты А и В, и то, что меняешь на А должно отобразиться на В?)

нормальный вариант🤔

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

так же, через репозиторий, если данные должны сохраняться или через общий объект, который должен умереть, когда уйдут A и B.

я думала, репозиторий, по-вашему, тоже костыльно. но если быть честными, то особой разницы между репозиторием, который файрит данные, и шейрдвьюмодел, которая делает то же самое, нет

смотря наверное насколько тесна логика работы вьюмодели с разными этими экранами. если очень, то шейрдвьюмодел, как мне кажется, подойдёт больше. если не очень, то..))не очень))

репозиторий нормально, как persistence - single source of truth. Ну, типа реактивной DB, и слушатели получают обновления, не зная друг о друге

++

неправ делая вообще сравнение в подобном роде

Что лучше: теплое или мягкое?

об этом тоже сказано в докладе. Но есть аргументы "за" как и "против"

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

скорее, красное или зелёное. и тут вопрос - кому? дальтоникам? пофиг ваще))для чего? для бренда? смотря что производит и тд и тп. вот и с архитектурами то же самое. они все имеют плюсы и минусы, нельзя быть уверенным в том, что всем должно заходить что-то одно

> 3) Это более актуальная архитектура представления
hype driven dev

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

скажете что не аргумент?)

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

другое дело, что есть короткоживущие штуки, которые хочется прокинуть между вью-моделями и тут гугл пишет про shared VM. Мы попробовали и если честно, ну нахуй. Два контроллера у вьюхи уже попахивает, а общаются они через LD и потом захочется это как-то мерджить и все это через вьюху, потому что не вкладывать VM в VM же. Короче, проще какой-то общий объект в два места заинжектить через DI.

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