ну с mvi еще можно понять, там все на потоках построено, а с редуксом да, не понятно

ну так дырками обмазал и жонглируешь fs2 да zio streams

Ну дык с флоу тяжко будет, а ркс можно в дырки засунуть

Ну так то да, но тогда уж надо было сразу на arrow-kt абстракциях пилить.
И все равно остается вопрос встает "зачем тут вообще стримы?.."

В какую сторону вы обычно направляете зависимости при организации настроек приложения? Например есть три булевых флага, каждый из них влияет на отдельную фичу, и сохраняется в префах.

Вариант 1: Каждый флаг хранится в собственных префах фичи, и на экране общих настроек перещелкивается. Вроде логично, потому что настройка принадлежит конкретной фиче.

Вариант 2: Есть общее хранилище настроек пользователя, и фичи забирают текущее значение своих флагов оттуда. Вроде логично, потому что настройки все в целом относятся к текущему пользователю приложения.

А если настройки задаются удаленно?

Это можно в обоих вариантах сделать) Или у каждой фичи свой конфиг, или общий для всего пользователя.

Я к тому, что стараюсь делать фичи-модули максимально автономными. Соответственно и настройки у каждой свои.

И плагинами их подключать в общий экран настроек, и позволить каждой из них иметь свою реализацию, одна в префах, другая в памяти, третья удаленная?

Есть еще 4-ая — захардкоженные разрабом для тестирования))

Если рассматривать настройки как отдельную фичу - то вполне можно хранить все в префах настроек. А из них потом в зависимых фичах все извлекать.
Мне кажется это верным вариантом, так как иначе настройки будут зависеть от реализации фич, которых они касаются, а это уже странновато, подобный код сложнее поддерживать и менять.

тогда или все фичи зависят от фичи настроек, или в каждую надо предоставить зависимость, которая будет сохранять и отдавать настройки под конкретную фичу

Зависит от. Думаю вначале проще всего хранить все в одних префсах и не заморачиваться. А уже по мере роста таких флагов, можно разбить на отдельные хранилища.

Мне больше нравится первый вариант. Причем рулить зависимостями можно по-разному, например, сделав read-only интерфейс только для считывания настроек, и интерфейс для записи конкретно из фичи настроек. Тут уже все ограничивается только требованиями и фантазией

Спасибо за ответы) Кажется, что первый вариант более гибкий, но второй проще в реализаци и понимании. Начнём с него, а там посмотрим.

Я думаю, что некая комбинация.
При разбивке на модули - вариант 1. Внутри модуля - вариант 2.

Есть репозитории

TreeRepository - получает список папок (вложенностей, дерево)
ObjectsRepository - объекты (содержимое дерева)
ObjectTypeRepository - описание типа объекта(ов)


1) Есть экран SplashView, в котором нужно все эти данные предварительно загрузить и закэшировать.
2) Есть экран ObjectsView в котором нужно собрать дерево используя данные из всех трех репозиториев.

Добавил интерактор ObjectsInteractor (пока просто как прокси работает, ну и объединяет данные из 3х репозиториев) и туда добавил получение джанныз из всех 3х репозиториев и получение комбинированных данных (т.е. собранное дерево с объектами).
Этот интерактор имеет методы:

getTree()
getObjects()
getObjectTypes()
getObjectsInTree()

и он используется и в SplashView и в ObjectsView

Вопрос:
Нужно делать разные интеракторы под эти 3 репозитория и объединять их где то в другом месте? Где?.. Сейчас, получается, нарушается SRP. А с другой стороны, кажется, что все нормально(одна бизнес фича, дерево объектов)..
+ подскажите источник, где хорошо(правильно) описано, что можно, а что нет по интерактору..

И, еще один вопрос:
Есть 2 интерактора AuthInteractor и UserInteractor
После авторизации нужно указать текущего пользователя через UserInteractor(потому что приложение мультиаккаунтное, и можно залогинится с разных акк, после логина автоматически должен становится активным пользователем).

Сейчас, AuthViewModel отправляет команду авторизации в AuthInteractor, после получения авторизации(там есть информация об ID пользователя) AuthViewModel отправляет команду установки текущего пользователя в UserInteractor.
Такое взаимодействие правильное? Или создать третий интерактор (SuperAuthInteractor) в котором есть AuthInteractor и UserInteractor и все делать внутри SuperAuthInteractor?

Привет) Вопрос такой, есть app модуль и есть другой модуль, назовем lib. В lib в с помощью implementation указана моя либа, которая с мавена тянется и другая либа, которая тоже тянется с maven. Так вот в app я могу обратиться к класам, которые подтягиваются в lib из НЕ моей либы. А своими классами из моей либы я пользоваться почему-то не могу. Может кто ясность внести почему так?

Если я убираю имплементацию lib в app/build.gradle, то доступ к классам НЕ моей либы тоже пропадает.