фрагментами. Есть фрагмент который дает пользователю возможность редактировать некий датакласс. Как архитектурно правильнее передавать в этот фрагмент сами данные? ссылкой на базуданных, откуда можно получить эти данные отредактировать и сохранить + уведомить, что изменились или правильнее передать сам инстанс данных через activitiLiveData? И после редактирования уведомить через ту же activitiLiveData, что данные изменились?
передать базу в presentation presentation во Fragment. Поменять и отобразить
ммм ну понятно :) спс
Через лайфдату передать данные для отображения, потом во вью модель передать изменённые данные и обновить их базе
Тут скорее вопрос в том, стоит ли view(его viewmodel) в которой происходит редактирование, знать о бд:)
В целом нет, view model должна знать только о доменном слое.
А о репозитории?
мы сейчас о Clean говорим?
Допустим
смотря где находится репозиторий вопрос более широкий на самом деле, в простом приложении можно принебречь чем-то, в большом такого делать нельзя в идеале конечно нужно чтобы view model общалась только с интеракторами
Если из репозиторя возвращается Result<SomeObject>, то как с ним работать в интеракторе? В result есть колбеки onSucess. Onerror. Или будет лучше не оборачивать так?
как это в Result могут быть колбэки? куда они колбэчат? Или интерактор может на них подписаться?
можно спокойно передавать репозиторий в vm
а как у Вас интерактор должен с ними работать? просто в Presentation передавать?
Я просто думаю стоит ли этой фью добавлять ещё ответственность по сохранению, мне все же кажется чище будет если вью позволит просто отредактировать данные, а после завершения редактирования создаст евент/вернет результат о том, что данные обновились, нужно сохранить. А уже тот кто вызвал эту фью для редактирования обработает результат. Но не знаю бестпрактикс потому и в замешательстве
Зависит о того, что из себя представляет первая view. Если это просто кастомная view (грубо говоря, layout), то да, она ничего не должна сохранять. Только коллбечить, а уже фрагмент будет сохранять результат.
мы делаем для каждого экрана свой interactor, который и занимается подобной логикой т.е. он обслуживает логику конкретного экрана можете попробовать
т.е. Вы хотите отделить редактирование и сохранение?
Скорее понять, стоит ли их разделять в этой архитектуре(mvvm) Т.к. думаю,что есть вероятность, что после редактирования наблюдатель(подписка же во view идёт?) может не получить событие,что нужно сохранить данные. Например после нажатия редактирования и нажатия ок, пользователь ожидант,что данные сохранятся, но происходит вход.звонок и система убивает приложение = наблюдатель не успел получить событие🤷
я не понял, для чего
для чистоты архитектуры ) я в процессе изучения
Обсуждают сегодня