и есть отдельный экран(форма редактирования), в котором можно ввести данные для добавления/изменения одно записи. Как принято делать: сохранять данные в БД прямо из формы редактирования записи, или передавать данные в основную активити и там уже их пихать в БД?
Зависит от деталей. Из выданной инфы, сохранить на экране изменения звучит логично
вот и я так думаю, но часто встречаю уроки где зачем-то в основной активити ожидают данных от формы редактирования.
От уроков зависит. Если уроки вот прямо базовые, то искать глубинный смысл не всегда выйдет - они больше про детали "показать", "записать в бд" и прочее
+1 в уроках часто используется демонстрация какой то одной логики в то время когда в реальных проектах часто реализация куда сложнее
https://developer.android.com/codelabs/android-room-with-a-view-kotlin#15 да пример прям от гугла
Тоже когда то его проходил)
забавно что работа через "onActivityResult" по из же мнению уже устарела, но туторы они вряд ли поправят.
Та от дизайна часто зависит. Бывает, что на "основном" экране в тебя список всяких свойств и кнопка "сохранить", а на экране "изменений" каждое отдельное свойство меняешь. В итоге главной точкой будет кнопка с экрана списка - там запишешь/отправишь на бекенд.
Скажу больше, на "устаревшем" подходе огромное количество проектов все ещё и что-то сомневаюсь, что без пинка хорошего кто-то это менять будет в попыхах)
не, в таком случае конечно все очевидно. Просто думал есть какая-то секретная парадигма или шаблон проектирования. рекомендующей делать как в примере.
Не, такого шаблона проектирования точно не было у gang of four)
Секретный шаблон - сохранять и грузить данные не в UI (это не его ответственность), а в отдельном слое, который обычно называют интерактор и который знает куда и как ходить за конкретными данными.
Вопрос был не об этом, так-то)
А о чем же?
В какой момент сохранять
Когда данные готовы, тогда и да 😁 Вопрос был - сохранять в форме ввода или в активити передавать, чтобы она сохраняла. А они обе как бы UI, так-то 😏
На самом деле не все что Гугл советует используется на 100 процентов. Если я не ошибаюсь то они ретрофит только недавно признали в то время когда все проекты его использовали
ну непосредственно код, который пихает данные в бд будет один и тот же, что в основной активити, что в отдельной. Объект через который правильно пихаются данные можно иметь как в основной форме списка так и в форме редактирования элемента списка.
В таком случае особой разницы нет. Передача данных в активити для сохранения - лишнее телодвижение получается.
Я подумал, может какие анимации при добавлении/удалении данных в список некорректно отрисуются если удалить в отдельной форме а потом вернуться на список.
Дак метод вью модели же запускаете в активити и все. А вью модель в репозитории там берет что нужно и кладет что нужно
Последующая синхронизация UI должна зависеть от результатов сохранения данных. На это хорошо LiveData ложится. Все, кому надо, её слушают и обновляются.
Обсуждают сегодня