Вы сложный человек, серьёзно и Вы реально запутались, распутывайтесь

Это оригинальное пособие от майкрософт, которые и придумали mvvm...

ViewModel запрашивает данные

В Android, конечно, невозможно полноценно реализовать true какой-либо из шаблонов, слишком много костыльности

Более того — Android Architecture Components и гугловские примеры реализации MVVM — это не совсем MVVM))

да, согласен

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

Это будет по канонам гиганта Google

и всю "бизнес-логику" писать непосредственно в viewmodel

Так отЭц завещал

Всем привет
Направьте, пожалуйста, что можно изучить, не могу до конца понять такой кейс:

Есть ViewModel, в которой мы используем viewModelScope, как сейчас модно. По каким-то событиям запускается 2 корутины, которые начинают работать с моделью. Возможно в это время начинается синхронизация чего-то с сервером или просто меняется состояние модели без запросов, это не важно...

Как гарантировать, что у нас не будет состояний гонки при модификации модели во время выполнения этих двух корутин?

Сделать модель иммутабельной) А в чём у вас может гонка произойти?

Под моделью здесь подразумевается не data class, не набор полей, а какая-то бизнес-логика - набор данных с логикой.

Если на примере ToDo-листа, то можно представить, что одно событие добавляет запись, а второе событие вызывает синхронизацию с сервером. Мне кажется эти действия нельзя делать одновременно.

Вообще тут нет особого отличия от обычных потоков. Если у вас есть shared mutable state, который вы меняете из разных потоков, то у вас большая беда, и от этого надо избавляться.

Можно попробовать синхронизированный доступ к данным сделать (хотя там есть какая-то особенность для корутин), можно делать операции над этими данными строго по очереди, например, в последовательном Dispatcher-е

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

Сама архитектура ваша может упорядочивать задачи, если у вас какой-нибудь MVICore везде. В общем, сложно дать универсальный ответ, конкретизируйте как-нибудь)

Вот это вот самая дичь, непонятно на кой такое мудрить. Назвали бы как-то по своему, чтобы не создавать дополнительной путаницы...

Часто в примерах встречаю, что VM берет подписки на базу данных и отображение происходит данных из бд. При этом если какой-то UseCase модифицирует БД (не на прямую, конечно). То экран изменяется из-за получения новых данных из вышеупомянутых подписок.

Бывают примеры приложений, где моделью является не БД, а какие-то классы, объекты, находящиеся в памяти?