а че все так не любят электрон то вроде норм прилы получаются. (я не шучу)

Такие норм, что достаточно лагучие, плавающий юай, да и вообще на ноде десктопное приложение — ну чот стрёмно.

Очень годно. И есть TornadoFX.

Это просто обёртка или там свои плюшки есть какие-то?

Это просто обёртка или там свои плюшки есть какие-то?

По большей части — DSL, подробностей не знаю.

для QT есть обёртки для, например, питона. говорят не так уж и больно писать

Последний раз, когда я смотрел на PyQt, у него всё было очень плохо с кроссплатформенным деплойментом с учётом того, что не у всех, собственно, пайтон есть. Я не очень, конечно, пытался, может, это и решаемо, мне сама змея не по душе.

С актором, внутри актора дебаунсим сообщения https://gist.github.com/IRus/37ae29cc2a2df201dafcf5c50313b416

чет rx как-то проще)

чет rx как-то проще)

ходить по краю технологий непросто

сложнее для понимания

А мне акторы понравились. Я вот сейчас на плюсах пописываю по работе -- и это грустно, когда std::future даже в композицию не умеет, а thread pool надобно писать самому поверх Boost::Asio. Вроде как и корутины где-то там на горизонте маячат, да пока они появятся и обростут библиотеками, Kotlin / Native уже несколько мажорных релизов пройти усеет.

чет rx как-то проще)

Ну так сложность пишут один раз в выносят в библиотеки (небось к релизу 1.0 комьюнити все уже напишет) Реализацию внутри RX куда сложнее.

Есть ли аналог BehaviorSubject — канал с текущим значением?

Это ж можно было бы неплохой MVVM сделать на основе каналов вместо пропертей.

Ну так сложность пишут один раз в выносят в библиотеки (небось к релизу 1.0 комьюнити все уже напишет) Реализацию внутри RX куда сложнее.

надеюсь. а как это все дело будет работать например с тем же Spring Webflux, и будет ли?

Ну вот мой debounce. Акторы и AtomicBoolean-ы мне кажутся здесь лишними: https://gist.github.com/elizarov/69ff0cf47d9ffe013bc6c1aeaf5af552

Есть ли аналог BehaviorSubject — канал с текущим значением?

Есть. ConflatedBroadcastChannel. Примеры использования здеcь: https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/coroutines-guide-reactive.md#rx-subject-vs-broadcastchannel

Есть. ConflatedBroadcastChannel. Примеры использования здеcь: https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/coroutines-guide-reactive.md#rx-subject-vs-broadcastchannel

Отлично. Спасибо.

Ну вот мой debounce. Акторы и AtomicBoolean-ы мне кажутся здесь лишними: https://gist.github.com/elizarov/69ff0cf47d9ffe013bc6c1aeaf5af552

Обе предложенные выерсии (как и моя вторая) являются по сути фильтрами, то есть отсекают все сообщения, если они приходят за заданный интервал времени. Такая операция конечно простая, но не очень полезная, ведь как обычно используют debounce: берем сообщение от пользователя и отправляем скажем на сервер, причем последнее сообщение должно быть самым важным. А фильтры его отбросят. В этом то главная проблема. Кроме того предложенные реализации не котроллируют выполнение созданной задачи. Ведь если появляются более свежие данные, то предидущая задача уже не имеет смысла и ее надо бы отменить.

А при чем тут debounce? Зачем какая то временная задержка? Надо просто при получении нового задания отменять старое.

Обе предложенные выерсии (как и моя вторая) являются по сути фильтрами, то есть отсекают все сообщения, если они приходят за заданный интервал времени. Такая операция конечно простая, но не очень полезная, ведь как обычно используют debounce: берем сообщение от пользователя и отправляем скажем на сервер, причем последнее сообщение должно быть самым важным. А фильтры его отбросят. В этом то главная проблема. Кроме того предложенные реализации не котроллируют выполнение созданной задачи. Ведь если появляются более свежие данные, то предидущая задача уже не имеет смысла и ее надо бы отменить.

тебе наверное нужен sample?

который по интервалу берет самое последнее значение

http://reactivex.io/documentation/operators/debounce.html

Debounce тоже берет последнее

Да, сделаю чтобы брало именно последнее

А при чем тут debounce? Зачем какая то временная задержка? Надо просто при получении нового задания отменять старое.

Ну задержка нужна чтобы снизить нагрузку на сервер. Хоть запрос и отменен, это не значит, что данные не успели попасть на сервер и создать на него нагрузку.

тебе наверное нужен sample?

Эта операция с двумя входными потоками и одним выходным. Из нее можно сделать debounce, да, но все же это не совсем то.

http://reactivex.io/documentation/operators/debounce.html

Ага. Точно. Последнюю надо брать. Вот исправленная версия: https://gist.github.com/elizarov/69ff0cf47d9ffe013bc6c1aeaf5af552

Хотя тоже не фонтан. Она пока спит до следующего интервала, то ничего не принимает (посылающая сторона ждет)... А наверное должна принимать и выкидывать. Хз. Я вообще не понимаю зачем это кому-нибудь нужно, и поэтому не понимаю какое правильное должно быть поведение

Ну паттерн использования ровно такой же, как и в rx. Там эта операция довольно популяраня.

@leukinrs тебе нужно поверх канала, или generic использование?

Что значит generic?. Вот такой интерфейс, как предложил @relizarov довльно универсален. Думаю на нем остановиться. Через него можно уже заимплементить и контроль над Job.

ну на самом деле ты же можешь дебаунсить случайную функцию, как я предложил. дебаунсить канал это частный случай

И для какого use-case она там используется? Мне, в своей жизни, приходилось только один раз подобное делать, чтобы ограничить частоту обновления UI, когда сервер очень часто посылал обновления (но потом мы пофиксили сервер). А обратную сторону всегда был шаблон такой, что если пользователь инициирует новое действие, то старое отменяется и посылается новое.

Ну в JS очень частный паттерн делать debounce ввода пользователя

Хотя тоже не фонтан. Она пока спит до следующего интервала, то ничего не принимает (посылающая сторона ждет)... А наверное должна принимать и выкидывать. Хз. Я вообще не понимаю зачем это кому-нибудь нужно, и поэтому не понимаю какое правильное должно быть поведение

Это важно Android разработчикам. У нас частый кейс, когда есть живой поиск, пользователь что-то набирает и нам нужно делать запрос не на каждый набранный символ (в случае если человек вводит их быстро), к с некой минимальной задержкой.

+

Ага. С задержкой. Этот момент я тоже упустил. В моем коде сейчас задержки нет. Первая шлется сразу.

Ага. С задержкой. Этот момент я тоже упустил. В моем коде сейчас задержки нет. Первая шлется сразу.

Первая и должна

Скорее последняя за 300 ms

В Rx, созласно нарисованной marble диаграмме в методе debounce, первая с задержкой уходит

Вот с первой не всегда верно. Иногда должна, иногда нет. Там вроде есть опции.

Это какое-то шаманство. А зачем это надо? Чтобы очень активные пользователи не положили сервак? Просто в моем мире между клиентом и сервером всегда был back-pressure, поэтому если клиенты пытаются положить сервер, то часта запросов от них автоматом уменьшается из-за backpressure и не надо никаких временных интервалов "ручками" вводить.

Это чтобы на UI ввод в формочку реактивно обновлял что-то, но при этом не мельтешило. Например.

Это какое-то шаманство. А зачем это надо? Чтобы очень активные пользователи не положили сервак? Просто в моем мире между клиентом и сервером всегда был back-pressure, поэтому если клиенты пытаются положить сервер, то часта запросов от них автоматом уменьшается из-за backpressure и не надо никаких временных интервалов "ручками" вводить.

От части что бы и сервер не забрасывали, от части и потому что интернет медленный и стараемся не плодить лишних запросов, которые с высокой вероятностью прийдется отменить при следующем введённом символе

Если рассматривать данный кейс)

Кейсов много просто

Обе предложенные выерсии (как и моя вторая) являются по сути фильтрами, то есть отсекают все сообщения, если они приходят за заданный интервал времени. Такая операция конечно простая, но не очень полезная, ведь как обычно используют debounce: берем сообщение от пользователя и отправляем скажем на сервер, причем последнее сообщение должно быть самым важным. А фильтры его отбросят. В этом то главная проблема. Кроме того предложенные реализации не котроллируют выполнение созданной задачи. Ведь если появляются более свежие данные, то предидущая задача уже не имеет смысла и ее надо бы отменить.

вторая часть (про отмену задачи предыдущей) вообще к debounce отношения не имеет

Это чтобы на UI ввод в формочку реактивно обновлял что-то, но при этом не мельтешило. Например.

Да, обычно же это сопровождается различными анимациями и если результаты поиска у нас в кэше, то это все будет прыгать. И тут обычно делает задержку в продолжительность анимации или более

Вот диаграма именно того, что я пытаюсь добиться http://reactivex.io/documentation/operators/images/throttleFirst.png

ну так это ровно мой "debounce"

вторая часть (про отмену задачи предыдущей) вообще к debounce отношения не имеет

Ну это, чтобы не отменять.

как и debounce Ромы

Мы брали первый, и отбрасывали новые

Последний должен сохраниться.

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

Ну там просто не нарисован этот случай.

:) ну вот так только не так

Вот если розовый убрать, то синий должен прийти.

Значит ты именно debounce хочешь

вот тут сохраняется последний

У debounce есть задержка на первом. В принципе такое поведение тоже допустимо, но не всегда.

ERROR: S client not available

т.е. ты хочешь первый элемент в стриме пустить без задержки, а все последующие пустить через debounce

throttleFirst совсем другую логику имеет же

Например представь случай, пользователь тыкает кнопку, мы начинаем ждать 300мс перед отправкой запроса, а потом ждем еще 300мс, в сумме 600, хотя могли получить за 300

даже на rx это будет типо три стрима. один входной, один для первого и один для всех остальных

у debounce всегда должен пройти интервал времени между 2я ивентами с throttleFirst/Last у тебя 2 сообщения могут пройти с разницей меньше чем интервал

Например представь случай, пользователь тыкает кнопку, мы начинаем ждать 300мс перед отправкой запроса, а потом ждем еще 300мс, в сумме 600, хотя могли получить за 300

это и есть debounce. жмаканул кнопку - ушел ивент, жмаканул еще раз в течении интервала - ниче не ушло

с throttle ты жмаканул кнопку и уйдет запрос только в конце интервала. если интервал 5 секунд то тебе эти 5 секунд выйдут задержкой

Привет !

Не знаю кому как, но Rx на котлине это такая дичь. На джаве я спокойно пишу себе выражения - студия все адекватно подсвечивает, генерирует и все збс Но на котлине, что не напишу все красным - очень бесит. Даже простое что то типа флатМап и ни в какую. Начинаю гуглить пример нет. единственный выход писать на яве и конвертировать в Котлин. Но на кой хрен мне котлин если теперь я только в 2 раза больше времени трачу

Очень жаль это признавать

Но писал правду

Понимаете нагуглить на котлине rx просто онреал

Кто столкнулся?

Часть проблем для меня решил rxKotlin (https://github.com/ReactiveX/RxKotlin)

Часть проблем для меня решил rxKotlin (https://github.com/ReactiveX/RxKotlin)

Гляну

Но писал правду

Это же так сложно перевести вызовы rx из java в kotlin ?‍♂️

а под котлин что нужно свой rx подключать?

Это же так сложно перевести вызовы rx из java в kotlin ?‍♂️

Напрягает

нельзя джавовским разве?

в чем профит?

чегооо

нельзя джавовским разве?

Сразу в котлин классе нет

а под котлин что нужно свой rx подключать?

Не нужно, обычного rxjava хватает в 99.999% случаем

Может просто rx не нужен? )

Ну и это конечно ?

Котлин рх этож набор экстеншенов, не?

Не нужно, обычного rxjava хватает в 99.999% случаем

Not really. По крайней мере для того 0.001% случаев, когда нужно заюзать zipWith(). В связке с дефолтной Java приходилось писать так, ибо type inference не справляется: val obs1: Observable<Type1> = ... val obs2: Observable<Type2> = ... obs1.zipWith(obs2, BiFunction { t1: Type1, t2: Type2 -> Pair(t1, t2) }) С rxKotlin можно написать так: obs1.zipWith(obs2, { t1, t2 -> Pair(t1, t2)}) Первый вариант, конечно, рабочий, но второй вариант выглядит лаконичней. Выглядит ли он настолько лаконичней, чтобы в проект тащить еще одну либу каждый решает сам для себя. Хотя, оба варианта не очень, ибо все равно не получается написать: obs1.zipWith(obs2, ::Pair)

Тогда подскажите такое У меня летят ответы с разных сокетов, обернутые в Observable как лучше скомбинировать результаты - чтобы на финише сделать обшие вычисления над ними, (естетсвенно все летит из разных потоков) при учете что некоторые будут по любому кидать ошибки zip - не подходит - так как при ошибке одного обзервебла он не вызывается

Тогда подскажите такое У меня летят ответы с разных сокетов, обернутые в Observable как лучше скомбинировать результаты - чтобы на финише сделать обшие вычисления над ними, (естетсвенно все летит из разных потоков) при учете что некоторые будут по любому кидать ошибки zip - не подходит - так как при ошибке одного обзервебла он не вызывается

Если там retrofit, то можно использовать конвертер в Optional с rxJava, тогда zip будет работать. А вообще вот: launch(UI) { val request1 = try { api.request1() } catch (e: Exception) { null } val request2 = try { api.request2() } catch (e: Exception) { null } val combineResult = yourCombineFunction(request1.await(), request2.await()) }