JF
Это по сути логика кэширования
Size: a a a
2021 March 03
TY
Потому что переключение как механизм присутствовал в интеракторе, но так как его нет, он переезжает в репу
S
Т.е. мы можем свободно переместить функционал из интеракторов в репозитории, я правильно вас понял?
я если чесн немного слабоват в понятиях, если понимать интерактор / юзкейс в данном случае как посредник между ViewModel и Repository который хз а) не дает доступ посмотреть какие еще настройки может обрабатывать репозиторий и б) сворачивает / разворачивает данные,
то тут уже просто по предпочтениям надо смотреть и по ситуации
то тут уже просто по предпочтениям надо смотреть и по ситуации
JF
Потому что переключение как механизм присутствовал в интеракторе, но так как его нет, он переезжает в репу
У вас же получается если пользователь сменит язык в системе - в приложении он так же должен смениться?
S
то есть у меня есть интеракторы / usecase-ы в приложении, хотя я из вьюмодели мог обращаться напрямую, но мне нравится четче разграничивать по обязанностям.
TY
У вас же получается если пользователь сменит язык в системе - в приложении он так же должен смениться?
все глобально сменится)
TY
@silent829 @FatJorik спасибо за ответы)
TY
Пацаны, у меня тут вообще кора на ревью, я задам вам пару элементарных вопросов, а вы выскажите свою точку зрения, плз!
Вопрос 1.
Фича переключения языка, в рамках архитектуры есть только ViewModel и Repository. Есть объект, который переключает системный язык, который должен быть в рамках зависимости Interactor, но так как их нет, куда мы должны заинжектить этот объект:
Ответы:
Вариант А: Во ViewModel
Вариант Б: В Repository
Вопрос 2.
Есть фабрика, которая должна создавать обьект и возвращать его, но теперь появляется зависимость на конфигурацию, которая возвращает данные не просто асинхронно, а возвращает стрим в лице Flow<Data> и относительно этих данных зависит результат фабрки.
Как бы вы поступили в рамках этой задачи:
Ответы:
Вариант А: В зависимость фабрикик добавили конфигурацию и зарефакторили метод create из fun create(): Data -> fun create(): Flow<Data>
Вариант Б: Во ViewModel подписались на изменение конфигурации и когда значение конфигурации эмитится, то прокидывали его в метод create. Метод бы преобразился так: fun create(): Data -> fun create(config: Config): Data
Вопрос 1.
Фича переключения языка, в рамках архитектуры есть только ViewModel и Repository. Есть объект, который переключает системный язык, который должен быть в рамках зависимости Interactor, но так как их нет, куда мы должны заинжектить этот объект:
Ответы:
Вариант А: Во ViewModel
Вариант Б: В Repository
Вопрос 2.
Есть фабрика, которая должна создавать обьект и возвращать его, но теперь появляется зависимость на конфигурацию, которая возвращает данные не просто асинхронно, а возвращает стрим в лице Flow<Data> и относительно этих данных зависит результат фабрки.
Как бы вы поступили в рамках этой задачи:
Ответы:
Вариант А: В зависимость фабрикик добавили конфигурацию и зарефакторили метод create из fun create(): Data -> fun create(): Flow<Data>
Вариант Б: Во ViewModel подписались на изменение конфигурации и когда значение конфигурации эмитится, то прокидывали его в метод create. Метод бы преобразился так: fun create(): Data -> fun create(config: Config): Data
@FatJorik есть мнение по 2 вопросу?
СП
Именно так и есть, вопрос в том, кто ответственен за его переключение, repository ил viewmodel
Вью получает клик на элементе смены языка отдает его в слой презентера тот вызывает метод репо.
JF
@FatJorik есть мнение по 2 вопросу?
Я ещё не проснулся, вопрос не помещается в голову
СП
Это при условии что язык меняется только юзером из ui.
JF
@FatJorik есть мнение по 2 вопросу?
Не понимаю зачем нужно конфигурацию во vm каким-то образом класть. Ей там не место
TY
Не понимаю зачем нужно конфигурацию во vm каким-то образом класть. Ей там не место
Тут ключевой вопрос: насколько нормально, чтобы фабрика возвращала стрим вместо того, чтобы принять конфигурацию в методе create
JF
Тут ключевой вопрос: насколько нормально, чтобы фабрика возвращала стрим вместо того, чтобы принять конфигурацию в методе create
Зачем фабрике возвращать стрим?
JF
она же всегда возвращает 1 объект
S
она же всегда возвращает 1 объект
+
JF
фабрика создается отдельно, и можно сделать над ней надстройку/адаптер, чтобы он оборачивал данные в стрим
TY
Именно, у меня мозг у самого взрывается от подобных фраз) Возвращаемые данные зависят от доп параметров, которые мы получаем из конфига, а конфиг возвращает данные ввиде стрима.
Вариант А: Если засунуть репу конфига внутрь фабрики, то метод create будет должен возвращать стрим
Вариант Б: Если же получать конфигурацию в отдельном месте и уже прокидывать конкретные данные ее в метод create, тогда для create нужно лишь добавить входной агрумент, на основе которого она построит уже объект
Вариант А: Если засунуть репу конфига внутрь фабрики, то метод create будет должен возвращать стрим
Вариант Б: Если же получать конфигурацию в отдельном месте и уже прокидывать конкретные данные ее в метод create, тогда для create нужно лишь добавить входной агрумент, на основе которого она построит уже объект
JF
Именно, у меня мозг у самого взрывается от подобных фраз) Возвращаемые данные зависят от доп параметров, которые мы получаем из конфига, а конфиг возвращает данные ввиде стрима.
Вариант А: Если засунуть репу конфига внутрь фабрики, то метод create будет должен возвращать стрим
Вариант Б: Если же получать конфигурацию в отдельном месте и уже прокидывать конкретные данные ее в метод create, тогда для create нужно лишь добавить входной агрумент, на основе которого она построит уже объект
Вариант А: Если засунуть репу конфига внутрь фабрики, то метод create будет должен возвращать стрим
Вариант Б: Если же получать конфигурацию в отдельном месте и уже прокидывать конкретные данные ее в метод create, тогда для create нужно лишь добавить входной агрумент, на основе которого она построит уже объект
варинт Б нормальный, правда заморочный с разделением кода по слоям
JF
о какой конфигурации речь? AndroidConfig или какой-то внутренний класс?