Size: a a a

Android Architecture

2020 May 26

AD

Aleksey D. in Android Architecture
Andy Yanechko
Но ничего не мешает вызвать метод setSomeInfo из фрагмента, когда приходят id из  sharedViewModel.

Это я про пример на гисте, который выше кинул
почему ты второй раз мне отвечаешь, а не автору вопроса?
источник

EG

Evgeny GooDi in Android Architecture
это из рабочего проекта?
источник

AY

Andy Yanechko in Android Architecture
Evgeny GooDi
это из рабочего проекта?
Конкретно это нет, но я использую такой же подход в рабочих проектах
источник

EG

Evgeny GooDi in Android Architecture
Andy Yanechko
Конкретно это нет, но я использую такой же подход в рабочих проектах
благодарствую, буду вникать
источник

EG

Evgeny GooDi in Android Architecture
Aleksey D.
только сейчас разглядел, что там подписка на sharedViewModel для id сделана, а оно уже в локальную делегирует

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

AD

Aleksey D. in Android Architecture
Evgeny GooDi
локальная вьюмодель - это вьюмодель фрагмента? как тогда активити до нее достучится?
на скриншоте вижу, что обе VM доступны внутри фрагмента, потому не вижу проблем сделать так:

val sharedViewModel = // init
val model = FragmentViewModel(sharedViewModel)
источник

EG

Evgeny GooDi in Android Architecture
О! Одну вьюмодель передать в конструктор другой?
источник

AD

Aleksey D. in Android Architecture
Evgeny GooDi
О! Одну вьюмодель передать в конструктор другой?
ага, что-то вроде того
источник

EG

Evgeny GooDi in Android Architecture
Ни разу не встречал такого подхода... Так делают? ))))
источник

AD

Aleksey D. in Android Architecture
Evgeny GooDi
Ни разу не встречал такого подхода... Так делают? ))))
p.s. все еще кажется, что вставить что-то такое во все заинтересованные VM лучше:
class PlaylistIdBus {
 fun observe(callback: (PlaylistId) -> Unit)
 fun dispose(callback: (PlaylistId) -> Unit)
 fun post(id: PlaylistId)
}
источник

AD

Aleksey D. in Android Architecture
Evgeny GooDi
Ни разу не встречал такого подхода... Так делают? ))))
но вариант с прокинуть через fragment.setPlaylistId(PlaylistId) тоже имеет место быть 🤷
источник

АЕ

Алексей Ершов... in Android Architecture
Ребята, а вам правда нравится шарить вьюмодели? Разве не проще и надежнее общение между экранами уровнем выше организовывать, через модель?
источник

AD

Aleksey D. in Android Architecture
Алексей Ершов
Ребята, а вам правда нравится шарить вьюмодели? Разве не проще и надежнее общение между экранами уровнем выше организовывать, через модель?
формально, шаренная модель и играет этой самой модели, но решение такое себе, да
источник

В

Вася in Android Architecture
Есть юскейс получения юзера с сервера и записи в БД и есть юскейс чтения юзера с БД и если он нуловый - получение юзера с сервераи собственно запись в бд.  Есть несколько юскейсов , работа которых связана с записью данных сервер и  после успешной записи снова нужно обновить юзера с сервера и записать в БД. Подскажите пожалуйста, как правильней лучше это сделать? В каждом юскейсе , где понадобится обновление юзера в БД , делать доп. метод который при успешном ответе сервера будет обновлять юзера? В некоторых примерах один юскейс инжектят в другой юскейс. Подскажите пожалуйста как правильней всего это реализовать будет
источник

В

Вася in Android Architecture
В идеале какой-то флаг сделать в юскейс получения юзера с БД , если флаг тру - сразу обновлять юзера с сервера , а не пробовать тянуть с бд. Хорошая вообще идея  один юскейс в другой инжектить ?
источник

В

Вася in Android Architecture
Когда в нескольких разных юскейсах , при выполнении определенных запросов, нужно выполнить работу, которая есть в каком-то ином юскейсе
источник

АЕ

Алексей Ершов... in Android Architecture
Aleksey D.
формально, шаренная модель и играет этой самой модели, но решение такое себе, да
Вот и вопрос, зачем шарить вьюмодель, если можно просто модель? Просто классов меньше?
источник

AD

Aleksey D. in Android Architecture
Алексей Ершов
Вот и вопрос, зачем шарить вьюмодель, если можно просто модель? Просто классов меньше?
а по делу - не приходилось шарить VM пока, все какие-то колбэки внутрь добавляю
источник

DS

Dm Savin in Android Architecture
Ребят, вы чо
Модель как раз и нужна, чтоб хранить/шарить данные, с которыми работают несколько вью моделей, сиречь бизнес логик
Исходная задача абсолютно рутинная для mvvm - 2 view (fragments), 2 view models, которые держат логику для вью, и 1 модель с данными. Вью модели общаются посредством событий типа onDataChanged, которые выбрасываются моделью, когда данные меняются, и на которые подписаны обе вью модели
источник

DS

Dm Savin in Android Architecture
Если мы имеем дело с ситуацией, когда vmodel данные не меняет, но отреагировать надо, то же самое, события в модели и подписка на них, если примитивно. Чуть посложнее - message bus в модели
источник