Можно коллбек заменить на flow, используя callbackFlow.

Хм, это что-то для меня новое, чекну тоже

class WindowsSizeNotifier {
   private val action = ConflatedBroadcastChannel<WindowsSize>()
   fun setNewWindowSize(size: WindowsSize) {
       action.offer(size)
   }

   fun sizeChanges() = action.asFlow()
}

Просто тоже сейчас юзаю firebase c похожим кейсом и этот вариант хорошо живет.

@mentarey @yakowweber спасибо, как минимум есть пища о размышлении и пробел в знаниях)

Вроде как это будет холодный поток, ну если он подходит то тоже можно заюзать

Там под капотом ченелы,  поэтому он горячий.

https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/callback-flow.html  Creates an instance of the cold Flow with elements that are sent to a SendChannel provided to the builder’s block of code via ProducerScope. It allows elements to be produced by code that is running in a different context or concurrently.

Все таки холодный

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

Можно, делитесь и кидайте ссылку на чат)

git + /NekrutovEd/Multi-Module-Navigation

Было бы очень интересно увидеть табличку сравнения с другими либами.
И почитать, о том, что сподвигло на написание либы

Я пока хочу набрать вопросов и после написать статейку с описанием, сравнением и ответами на вопросы.

Основной принцип, это отдельная сущность, которая умеет создавать фрагмент и проставлять зависимости. И навигация осуществляется через эту сущность. В данной реализации это FragmentModule

В readme есть описание плюсов данной реализации.

зачем зависеть от Toothpick, если можно затянуть в проект только аннотации, а пользователь сам ими воспользуется, как посчитает нужным? (а можно вообще без аннотаций - руками вызвать конструктор в своем DI не проблема)

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

В readme есть ссылка на чатик для обсуждения. Наверное лучше писать туда, чтобы не спамить тут.

Привет ребята.
Такой вопрос, есть репозиторий

interface TreeRepository {
    fun getTree(): Observable<List<Tree>>
}

Данные идут с сервера и кэшируются в DB. Если есть кэш то репозиторий дает данные из кэша, а если данных нет то лезет в сеть.

Но есть такой кейс: при pulltorefresh, данные в любом случае должнны тянутся с сервера и обновляться в кэше(DB).

Варианты решения:
1) метод getTree репозитория принимает параметр

fun getTree(ignoreCache: Boolean): Observable<List<Tree>>

2) перед выполнением запроса getTree() выполняем очистку кэша clearTree()
3) реализация репозитория инжектится в момент запроса (при каждом запросе создаем объект репозитория, первый может взять из кэша, а второй берет только с сервера и кэширует в DB)
4) ...?



- Если выбрать первый вариант, то возникает вопрос, нормально ли вообще, что клиент знает о наличии кэша и вот таким образом все это разруливает?..
- Если выбрать второй вариант, то кто должен заниматься очисткой? - где этот метод clearTree()? Ну допускаем только вариант, что в репозитории т.к. по другому нет доступа к слою данных. Допустили этот вариант, а что будет есть у нас появится какой то репозиторий который вообще не умеет кэшировать и метод clearTree() никак не реализовать, рузультат выполнения всегда false(условно)?
- Если третий вариант, то вроде бы гуд, или нет?


В итоге, как вы реализуете такой кейс?