понял спс

но можно поглядеть KotlinRx примочки

а где подробнее по лямбдам можно почитать?

а где подробнее по лямбдам можно почитать?

английкий покатит?

https://kotlinlang.org/docs/reference/lambdas.html

ага норм, спасибо!

сделать свою функцию принимающую три лямбды и 2 из них с дефолтным значением

сделать свою функцию принимающую три лямбды и 2 из них с дефолтным значением

Ага спасибо, открыл статью и сразу об этом догадался

С completablefure можно строит нормальный пайпы и обрабатывать в конце, а тут привет из 90-х с try/catch/log/re-throw В C# это кстати тоже бесит, но видимо судьба такая у коррутин.

Так а кто в Котлине просто так try/catch/finally делает? Ты обычно какие-нибудь extensions/DSLs используешь (такие как use из stdlib) в которых это всё _инкапсулировано_. Собственно, корутины тебе позволяют _одинаковыми_ extensions пользоваться как в своем обычном коде, так и в асинхронном (если эти extensions сделаны inline)

Ну это хорошо, если “extensions/DSLs” есть на все случаи жизни (надеюсь на android это без anko возможно)

Так а кто в Котлине просто так try/catch/finally делает? Ты обычно какие-нибудь extensions/DSLs используешь (такие как use из stdlib) в которых это всё _инкапсулировано_. Собственно, корутины тебе позволяют _одинаковыми_ extensions пользоваться как в своем обычном коде, так и в асинхронном (если эти extensions сделаны inline)

Кстати, можно парочку примеров? А то кажется кроме тебя про них никто и не слышал (раз try/catch предлагают).

Я всегда их чаще всего себе сам пишу. Ошибки же обычно централизованно обрабытаюся - одна функция на все приложение. Ну и use использую из stdlib для closeable штук. А зачем нужные try/catch/finally еще? У меня их в коде обычно почти нигде нет

Подскажите еще пожалуйста, есть абстрактный CustomPagerAdapter<T> и есть CustomViewPager<T> . В CustomViewPager<T> есть параметр mAdapter:CustomPagerAdapter<T> и я пишу ему сеттер super.setAdapter(value). когда я пытаюсь присвоить переменной mAdapter пишет что "setter for mAdapter is removed by type projection" где я не прав? как исправить ситуацию?

А разве тут есть ответ на мой вопрос? Я пробежался (хотя я вполне мог что-то пропустить), там в основном про CPS transformation и state machine. Я тут осознал, что мои вопросы не к корутинам, а к ComputableFuture и к select, видимо

@relizarov Роман, не подскажете, я тут прав или нет? Сам вопрос звучал так: И если заговорили про корутины, объясните пожалуйста такую вещь: вот запустили корутину на тредпуле и вызвали await, в пуле нашёлся поток и он вызвал, допустим, бд на долго(это насколько я понял будет суспендбл поинт). Что или кто и в какой момент решит, что это на долго и что нужно вернуть поток в пулл? Должен же быть какой-то шедулер, нет? Тоже самое когда пришёл ответ от бд. Когда тред вернётся к начавшейся корутине? А-то я наконец, прочитал https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md (хотя может что-то пропустил или не правильно понял), но ответов там не нашёл

Поток будет освобожден _сразу же_ как только корутина заснула в ожидании чего-либо

Поток будет освобожден _сразу же_ как только корутина заснула в ожидании чего-либо

а проснётся корутина когда? вот у меня UI поток в бизилупе, из сокерта постучали, когда и как корутина поймёт что настал тот момент когда нужно отнять у бизилупа поток и продолжить выполнение с того места где уснули

Поток будет освобожден _сразу же_ как только корутина заснула в ожидании чего-либо

и вот этот момент "заснула в ожидании чего-либо" - имеется в виду await или аналогичный механизм?

Проснется тогда, когда та функция, которая её усыпила скажет "пора просыпаться" (вызовет continuation.resume)

Ну обычно мы спим в ожидании когда какой-нибудь async io вызовет какой-нибудь callback. И в коде этого коллбека стоит вызов resume. Смотри вот этот слайд: https://www.slideshare.net/elizarov/introduction-to-kotlin-coroutines/20

Про это же написано в спецификации корутин здесь: https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#wrapping-callbacks

ну т.е. я правильно понимаю что если у нас блокирующее IO то корутины тут не помогут?

Смотря в чем вам нужна помощь. Если вы хотите чтобы ваше блокирующее IO вообще потоков не использовало — не помогут. Если вы всего-лишь хотите чтобы во время блокирующего IO не блокировался ваш UI поток — помогут

@relizarov если у нас JDBC, будет ли польза от того что мое приложение начиная от сервера будет асинхронное и неблокирующее, а в базу будет какой-то thread-pool с очередью перед ним?

Смотря в чем вам нужна помощь. Если вы хотите чтобы ваше блокирующее IO вообще потоков не использовало — не помогут. Если вы всего-лишь хотите чтобы во время блокирующего IO не блокировался ваш UI поток — помогут

> Если вы всего-лишь хотите чтобы во время блокирующего IO не блокировался ваш UI поток — помогут но это будет равносильно вызову из тредпула какого-нибудь Callable, да? И я так понимаю нужно будет использовать пулл который не использует UI поток

@HeapyHop Польза это очень относительное понятие. Очень зависит от того, какую вы систему пишете. Если у вас большой backend который использует в перемешку JDBC и еще 100500 REST микросервисов, то от корутин _огромная_ польза, так вы сможете четко контролировать сколько у вас одновременно JDBC запросов и коннекций к базе, но при этом масштабироваться на огромное чисто одновременно обрабатываемых запросов, пиша вашу бизнес-логику в совершенно естественном, как бы синхронном стиле

@HeapyHop Польза это очень относительное понятие. Очень зависит от того, какую вы систему пишете. Если у вас большой backend который использует в перемешку JDBC и еще 100500 REST микросервисов, то от корутин _огромная_ польза, так вы сможете четко контролировать сколько у вас одновременно JDBC запросов и коннекций к базе, но при этом масштабироваться на огромное чисто одновременно обрабатываемых запросов, пиша вашу бизнес-логику в совершенно естественном, как бы синхронном стиле

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

По котлину на русском книги есть? В бумажном варианте

@qvava Конечно равносильно. Только код будет элегантый. Вы один раз возьмете свою blockingOperation и используя функцию run сконвертируете её в non-blocking написав в одну строчку suspend fun nonBlockingOperation() = run(CommonPool) { blockingOperation() }. После этого можете спокойно использовать nonBlockingOperation из UI-bound корутин, например: launch(UI) { .. do somethin on UI; nonBlockingOperation(); ... do something else on UI ... }. То есть вы _инкапсулируете_ всё ваше блокируещее API и весь остальной код будете писать в асинхронном, неблокирующем стиле.

@HeapyHop Если у вас всё упирается в базу, то от корутин пользы не будет. Но это прошлый век. Сейчас популярны микросервисы и уже редко увидишь, что всё в базу упирается

Ну в смысле что конечный микросервис будет ходить в базу, асинхронного JDBC у нас нет, и вот общении между микросервисами и прием запросов от пользователя будет асинхронными, но в базу то мы упремся (в том смысле что там нету хорошего асинхронного драйвера к популярным ORM/мапперам).

@qvava Конечно равносильно. Только код будет элегантый. Вы один раз возьмете свою blockingOperation и используя функцию run сконвертируете её в non-blocking написав в одну строчку suspend fun nonBlockingOperation() = run(CommonPool) { blockingOperation() }. После этого можете спокойно использовать nonBlockingOperation из UI-bound корутин, например: launch(UI) { .. do somethin on UI; nonBlockingOperation(); ... do something else on UI ... }. То есть вы _инкапсулируете_ всё ваше блокируещее API и весь остальной код будете писать в асинхронном, неблокирующем стиле.

аа, всё, ок, теперь я понял. Просто у меня было ощущение что там ещё какая-то подковёрная магия, которая определяет что поток сейчас не нужен и передаёт его управление другой корутине =) спасибо большое !

Сохрани дерево. Скачай пдф

Никакой подковерной магии нет! Вы бы это могли всё написать сами, но только получится говнокод. А так этот говнокод за вас сделает компилятор и вам не надо на него смотреть и глаза будут целы

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

@HeapyHop Если у вас всё упирается в базу, то от корутин пользы не будет. Но это прошлый век. Сейчас популярны микросервисы и уже редко увидишь, что всё в базу упирается

Например сейчас спринг пионерит реактивные API, например у них есть реактивный mongodb. Чтобы действительно получить всю мощь от корутин в вебе нужно такое же, но только для более популярных баз типо постгри и мариядб. Было бы хорошо, если бы такое появилось.

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

Не знаю насколько это качественный код, но тут я хожу в три места с помощью AsyncHttpClient(apache), который обернут в suspend функцию. В корутине runBlocking я делаю три параллельных запроса и ожидаю ответа с таймаутом, агрегирую результат и отдаю. Проблема в том, что окружающий мир - блокирующий, но хотя бы в маленьком месте я заюзал корутины)

да, я видел его, хороший пример

@qvava Конечно равносильно. Только код будет элегантый. Вы один раз возьмете свою blockingOperation и используя функцию run сконвертируете её в non-blocking написав в одну строчку suspend fun nonBlockingOperation() = run(CommonPool) { blockingOperation() }. После этого можете спокойно использовать nonBlockingOperation из UI-bound корутин, например: launch(UI) { .. do somethin on UI; nonBlockingOperation(); ... do something else on UI ... }. То есть вы _инкапсулируете_ всё ваше блокируещее API и весь остальной код будете писать в асинхронном, неблокирующем стиле.

если кто-то всё таки начнёт блокировать UI сложно будет диагностировать с таким корутинным подходом? Наверное в худшем случае всё также как и в обычной ситуации, запускаешь профайлер, смотришь стектрейсы по времени. Так что вопрос скорее про то насколько хорошие стектрейсы у корутин.

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

если кто-то всё таки начнёт блокировать UI сложно будет диагностировать с таким корутинным подходом? Наверное в худшем случае всё также как и в обычной ситуации, запускаешь профайлер, смотришь стектрейсы по времени. Так что вопрос скорее про то насколько хорошие стектрейсы у корутин.

Мне кажется можно сделать соответсвующую инспекцию в идее. Все-таки набор блокирующих API в джаве конечный.

Примерно это же код на CompletableFuture Если нет “бизнес логики” (а тут ее почти нет), то код получается почти одинаковым. https://i.gyazo.com/a6d38955d9e096e87dfd362c16123c7f.png (P.S. awaitOrNull это моя 3-х строчная фукция, которая делает anyOf с промисом на таймаут)

Примерно это же код на CompletableFuture Если нет “бизнес логики” (а тут ее почти нет), то код получается почти одинаковым. https://i.gyazo.com/a6d38955d9e096e87dfd362c16123c7f.png (P.S. awaitOrNull это моя 3-х строчная фукция, которая делает anyOf с промисом на таймаут)

twitter = facebook.... fb = twitter....

:D

как легко допустить ошибки без корутин

Примерно это же код на CompletableFuture Если нет “бизнес логики” (а тут ее почти нет), то код получается почти одинаковым. https://i.gyazo.com/a6d38955d9e096e87dfd362c16123c7f.png (P.S. awaitOrNull это моя 3-х строчная фукция, которая делает anyOf с промисом на таймаут)

На лицо нарушение принципа DRY. Зачем мы повторяем спиоск в allOf(...)? Забыли там чего-нибудь указать и поросли.... Всё это очень error-prone

Говорила мне мама — не используейте futures.... (и вам того же советую)

ну неявность – плохо. Если там не point, а например foo.bar() in a..b, где bar - экстеншн функция на nulalble receiver возвращающая nullable, а foo какое-то свойство, которое мы тут сделали nullable, и внезапно вся эта штука неожиданно и молча стала работать неправильно

Еще если заоверрайдить метод из джавы, то будет например override fun onCreate(savedInstanceState: Bundle?). Убираем нуллабельность и не получаем никаких предупреждений и ошибок.

На лицо нарушение принципа DRY. Зачем мы повторяем спиоск в allOf(...)? Забыли там чего-нибудь указать и поросли.... Всё это очень error-prone

Тут вообще изначально очень странный код с 3-мя инъекциями одинаковых сервисов, давайте не будет Руслана спрашивать за архитектуру ?

если кто-то всё таки начнёт блокировать UI сложно будет диагностировать с таким корутинным подходом? Наверное в худшем случае всё также как и в обычной ситуации, запускаешь профайлер, смотришь стектрейсы по времени. Так что вопрос скорее про то насколько хорошие стектрейсы у корутин.

Если кто-то блокирует, то диагностировать просто. Вы сразу увидите с стеке какой-метод вам заблокировал главный поток и строчку вашего кода из которой он был вызван

Тут вообще изначально очень странный код с 3-мя инъекциями одинаковых сервисов, давайте не будет Руслана спрашивать за архитектуру ?

Да с фьючерсами такой код _вообще_ нормально не написать. Какой комбинатор не используй, будут или повторы или очень error-prone из-за разбора результатов по индексу

Да с фьючерсами такой код _вообще_ нормально не написать. Какой комбинатор не используй, будут или повторы или очень error-prone из-за разбора результатов по индексу

Роман остановитесь, ну видно же что изначально код написан для примера, “без архитектуры”. Я конечно понимаю что вы маркетолог коррутин, но надо же быть объективнее.

Да и вообще на futures/Rx нормально ложиться только _очень_ простая логика. Когда у тебя последовательный pipeline, следующий результат зависит строго только от предыдущего (не нужные промежуточные) и никаких лишних ветвлений или циклов в логике нет.

На лицо нарушение принципа DRY. Зачем мы повторяем спиоск в allOf(...)? Забыли там чего-нибудь указать и поросли.... Всё это очень error-prone

просто нужен комбинатор чтобы не повторяться. тип ShareCount <$> fb <*> twitter <*> linkedin

Вот, Руслан _объективно_ про резюмировал. Остальное это мантры и попытки продать свою технологию, которая "лечит все на свете”.

Если тебе ок все чейнить, и так же обрабатывать ошибки то тогда тебе корутины совсем не нужны, они про то чтобы отказаться явной передачи колбеков и упростить жизнь разработчика не обремененного ФП

@angmarr А как еще с фьчерсами сделать параллельно три запроса, дождаться ответа и как-то их объединить? При чем тут архитектура. Если перед вами всатала такая задача, то вам как-то надо её выразить в коде. Можно конечно ради этой задачи сделать Framework и Архитектуру, которая позволит такие задачи решать элегантно, но если эта задача встала один раз, то зачем?

+1. Еще надо добавить, что если ты готов для каждой нетривиальной задачи писать свой комбинатор ;)

(for the record — я RX очень люблю — это супер вещь для решения тех задач, для которых он был создан)

ну у rx в андроид есть некоторые штуки, помимо того что он решает проблемы с конкаренси. 1. то что приятно выражать свой асинхронный апи в типах rx. особенно со вторым, мол это событие произойдёт максимум один раз, вот это несколько. хотя чувствуется, что это всё могло бы быть написано сразу в джаве/в котлине все эти мапы, синглы, мейби. 2. то что есть потенциальный подписчик со своим жизненным циклом и потенциальный обсервабл. и подписать можешь совершенно из третьего места – получается такой (в худшем случае) эвентбас.если использовать корутины, то придётся его переизобретать

Похоже что 1. вытекает из 2, если у вас по “архитектуре” все возвращается только одни раз, то и observable и не нужен, а нужны промисы. Конкретно Observable на самом деле нужен редко и заменяется какой-нибудь EventBus/broadcasts RX с его Observable + Single (Completable вообще не нужен в Kotlin) выглядит как солянка из reactive-streams + promises Single/Completable изначально не были частью RX и по факту вносят скорее дискомфорт (toCompleble и тд) тем что не имеют общих интерфейсов. В android я вообще пользуюсь только rx.Single и то потому что нет нормальных промисов из коробки (типа CompletableFuture).

А вот и статейка в тему с̶р̶а̶ч̶а̶ ̶к̶о̶р̶у̶т̶и̶н̶ы̶ ̶v̶s̶ ̶п̶р̶о̶м̶и̶с̶ы̶ https://medium.com/@vjames19/kotlin-futures-a-better-completablefuture-api-for-kotlin-using-extension-functions-bb50b989ea26

но в этом примере мы все равно заблокируемся на методе getCount? какой профит? в параллельном выполнении?

ERROR: S client not available

но в этом примере мы все равно заблокируемся на методе getCount? какой профит? в параллельном выполнении?

Руслан же написал ниже: "Проблема в том, что окружающий мир - блокирующий, но хотя бы в маленьком месте я заюзал корутины)" Профит в том что бы писать с корутинами ? (может даже в продакшене)

Кто-нибудь хочет стать моим ментором? :))

Зачем программисту нужен ментор и где его найти: https://goo.gl/v4aqow Спойлер: для тех случаев, когда Google не может помочь.

Чаще всего нужна помощь не в какой-то определенной библиотеке, а в построении ООП-модели.

Кто-нибудь хочет стать моим ментором? :))

имхо хороший ментор это злой и опытный тимлид

Кто-нибудь хочет стать моим ментором? :))

Блин, столько компроментирующих подколок есть к этому предложению, но чатик слишком sfw ? (и не надо мне в личку писать, я не из этих, в смысле менторов)

Кто-нибудь хочет стать моим ментором? :))

50 оттенков менторства

а как в корутинах хэндлить ошибки без трай-кетч блоков?

есть что-то типа аналога onError из rxjava?

Вопрос непонятен. Стандартный механизм работы с ошибками в языке – исключения, и корутины следуют этому. Зачем ещё что-то сверху наворачивать?

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

Так причем тут корутины? :) Пиши на Rx если нравится onError

как можно сделать статическую ссылку на контект в андроиде?

как можно сделать статическую ссылку на контект в андроиде?

через companion object

а точнее? я чет подзабыл и не получается теперь =(

Так причем тут корутины? :) Пиши на Rx если нравится onError

решил корутины потыкать обстоятельно, а тут уже в рх посылают)

а как в корутинах хэндлить ошибки без трай-кетч блоков?

А ты не кидай исключения, а юзай монадический Result<T> или Option<T>

Кстати вот например внутри launch бросаю эксепшен, об этом можно как-нибудь извне узнать?

Кстати вот например внутри launch бросаю эксепшен, об этом можно как-нибудь извне узнать?

обернуть launch в трайкетч?

Не

Пробовал

Ну сейчас уже с телефона пишу, а так это единственное что пробовал

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

У job может статус ставится специальный

Если установлен CoroutineExceptionHandler, тогда туда свалится, иначе в currentThread.uncaughtExceptionHandler

что-то в такой духе не получится написать? launch(UI) { run(CommonPool) { updateErrorMessages() }.ifError { handleError(it) } notifyChange() }

а чем это лучше completable future и зачем тут coroutines?

completable future нету на андроиде можно сказать)

беда…

Что-то такое хотите? fun Job.onException(f: (Throwable) -> Unit) = invokeOnCompletion { if (it != null) f(it) }

Так причем тут корутины? :) Пиши на Rx если нравится onError

вот тут должны прийти парни с js и сказать про промисы)