При этом имплементация дата сорса должна быть отвязана от фичи (жить в другом модуле и может юзать контекс и т.п.)

Надо действительно схемку нарисовать, чтобы не путаться в терминах :)

ну да - так будет намного понятнее

Вечером тогда. Сейчас надо работать

ждем) не забудь

Все на работе )

Пачаны, всем привет. Нормально ли делать мвп в диалог фрагменте? Тобишь, запросы в презентере диалога  делать или сделать запрос , потом туда передать?

Иногда в этом есть смысл

Да, нормально

Понял, спасибо

Привет. Может кто-то подсказать куда рыть? Есть Navigation и bottomNavigationView с отдельными стеками и графами. Надо с фрагмента который в стеке второй вкладки запустить фрагмент в первой вкладке (можно убрать стек и вернуться к startDestination и с нее открыть фрагмент). Не как в инсте (с каждой вкладки можно в профиль аккаунта зайти) а что бы перебрасывало на первую вкладку и открывало там.

Привет! Подскажите такую штуку: есть зависимость из data-слоя, объект которой могу получить только асинхронно, коллеги посоветовали в граф зависимостей это дело не инжектить напрямую, а представить в виде провайдера:
interface StuffProvider {
     fun provideStuff(): Single<Stuff>
}
Выходит так, что имплементация провайдера должна знать про репозиторий StuffInfoRepo. Не уверен, что это корректно, но и проблемы тут явной пока не вижу. Подскажите, плохо ли это и в чем именно, если да?

глобальную навигацию юзай + чисти стек через popUp и т.д.

а почему должна знать?) я наверно не понял, какая зависимость чего и откуда)

Да, оно как-то у меня через чур абстрактно вышло. Если конкретнее, то:
Есть WalletProvider интерфейс, он создает возвращает конкретную имплементацию Wallet. За WalletImpl прячется библиотека, для инициализации которой мне нужно взять из репозитория список ключей. Отсюда необходимость WalletProviderImpl знать про KeyRepo

В итоге думаю, что как-то это неправильно. Неправильно ли?

а тебе в провайдере нужны только ключи?
почему бы библиотеку через di не инициализировать?

С ключами весело - в бд лежат не ключи, а пошифрованный материал генерации ключей, отсюда необходимость реализацию Wallet получать асинхронно. Или я не совсем правильно тебя понял сейчас

идея с провайдером выглядит вроде хорошо

тут уже наверно не про клин)