AN
Ну там всё просто. Он как канал с буфером. Засыпает когда буфер переполнился. Убирает из буфера когда все подписчики забрали.
Я понял. Просто обращаю внимание на то, что в доке этого нет. Не у всех же Елизаров в чате. Сейчас напишу issue
Size: a a a
2020 May 07
I
Мне кажется это совершенно не то, о чем человек просил в любом случае. Тут надо заранее будет знать число подписчиков, это раз, два — когда данные начнут потребляться, возникнет сдвиговый эффект внутри канала и получится очередь?
RE
Да я всё сплю и вижу его задепрекейтить (ну удалять-то конечно не будем — уже много народу использует). Сейчас как раз работаем над flow sharing. Там будет более обширная конфигурация и будет покрыто намного больше всяких экзотических случаев. Вроде пока удается полностью покрыть всё что делают всё BroadcastChannels и еще кучу всего сверху.
AN
Да я всё сплю и вижу его задепрекейтить (ну удалять-то конечно не будем — уже много народу использует). Сейчас как раз работаем над flow sharing. Там будет более обширная конфигурация и будет покрыто намного больше всяких экзотических случаев. Вроде пока удается полностью покрыть всё что делают всё BroadcastChannels и еще кучу всего сверху.
Интересно.
AN
Я тут на днях такой велосипед накрутил с конструкцией, которая присасывается к flow, делает на нем редукцию, но двигается дальше только когда кто-то требует вычислить что-то с большей точностью. Получилось как-то некузяво, но тем не менее такой вот неортодоксальный кейс
AN
Y
Мне кажется это совершенно не то, о чем человек просил в любом случае. Тут надо заранее будет знать число подписчиков, это раз, два — когда данные начнут потребляться, возникнет сдвиговый эффект внутри канала и получится очередь?
Да, число подписчиков может быть разным.
Получается я не смогу реализовать то что мне нужно?
Получается я не смогу реализовать то что мне нужно?
AN
Да, число подписчиков может быть разным.
Получается я не смогу реализовать то что мне нужно?
Получается я не смогу реализовать то что мне нужно?
А как? Вам же надо заранее знать сколько подписчиков ждать, чтобы хранить для них данные
I
Да, число подписчиков может быть разным.
Получается я не смогу реализовать то что мне нужно?
Получается я не смогу реализовать то что мне нужно?
Мне кажется тебе надо какой-то враппер вокруг канала делать. Т.е. я не помню подобного функционала из коробки
AN
Или хранить определенное время или определенное количество элементов (это как раз вариант, что Роман предложил)
Y
ждать нужно пока все кто подписан не обработают данные
Y
обычный foreach по всем подписчикам
I
ждать нужно пока все кто подписан не обработают данные
Тебе нужна тут совместимость с АПИ каналов? Если нет, создай свой объект, который будет работать под нужным поведением
I
Там тебе надо будет внутри сделать подобие семафора
Y
я в итоге хочу получить flow и его возможности, подписчиками будут flow.collect()
I
Так тебе горячо или холодно надо?
Y
получается горячо
Y
потому я сразу и делал conflated, чтобы было последнее значение
I
Ну жди ответов по готовым решениям из библиотеки Котлина. Я подходящих не знаю. Но спроектировать что-то такое локальное не очень тяжело
I
Иногда проще не постыдиться и написать "велосипед", чем на столько сильно расширять существующее, чтобы получить в итоге монстра