Хабр полон статьями про счастье с rxJava и MVP, где мы ассинхронно грузим модель из удаленного хранилища (файловая система, сервер). Но совершенно отсутствует описание того, как эта модель меняется в ответ на действия пользователя.
Пример,
https://habrahabr.ru/company/rambler-co/blog/277003/. Описание архитектурного подхода VIPER. Сам VIPER я не использую, но в нем используется MVP, а в примере рамблера еще и rxJava. В статье описано приложение, которое выводит на экран сообщения, которые откуда-то грузит. Но написать сообщения нельзя, модель откуда-то появляется, но пользователь не в силе на нее повлиять. А ее еще нужно сохранить в базу. А если в модели у нас есть некоторые взаимоотношения между сущностями и мы можем словить ConcurrentModificationException, если в разных потоках у нас будут работать несколько Interactor`ов.
На самом деле тут врядли возникнут какие-либо проблемы, в маштабах этого приложения. Однако в реальном большом приложении, с большой моделью, все гораздо сложнее.
Допустим, у нас есть список некоторых элементов - маркеров, которые пользователь может включить или выключить для отображения на карте (некоторое навигационное приложение) - у каждой строки есть свитч. Кроме маркеров, в моделе есть большое количество других сущностей (тоже гео-объектов), и их очень много. Чтобы UI был отзывчив, менять модель нужно в отдельном потоке. Для этого я сделал свой Scheduler, который назвал DATA_SCHEDULER.
Вроде все просто - Presenter запрашивает у MarkerStore Observable> - markerObservable, после получения списка передает его на отображение в MarkerListFragment. У каждого Marker есть поле visible, в зависимости от которого свитч либо on либо off. Что происходит, когда юзер кликает по свитчу - тот должен переключиться, и в DATA_SCHEDULER отправляется событие, о том, что поле visible нужно поменять. Операция довольно быстрая, мы очень скоро получаем апдейт модели в markerObservable, где у конкретного маркера поле visible поменяло значение. Но что если DATA_SCHEDULER загружен? Или пользователь начнет барабанить по свитчу? В очереди появится много запросов на изменение поля visible, которые будут дергать его туда сюда, после которых будут валиться апдейты в markerObservable.
Это вымышленный пример, но он описывет боль, которую я испытываю. Думаю, не у меня одного возникали такие проблемы, и хотелось бы посмотреть на возможные решения. Или примеры более реальных приложений, которые используют mvp и rxJava, и работают с более реальной моделью чем большинство примеров "чистой архитектуры" на хабре. Сам я гуглил, но ничего не нагуглил.
