Не идет у меня связка котлин+ тесты хоть убей... вроде сделал, но теперь следующая проблема вылезла из этого. у меня в качестве слушателя для рх метода написано subscribeBy, т.к. метод completable и мне не нужен результат. при тесте этого метода вылетает ошибка java.lang.IllegalArgumentException: Parameter specified as non-null is null: method io.reactivex.rxkotlin.SubscribersKt.subscribeBy, parameter $receiver

https://gist.github.com/indrih17/64c8133d5bf3d1ad6075058e6a7b2000 В одном случае падает с ошибкой на тему циклических зависимостей, а в другом нет. В чём фишка?

потому что в первом случае циклическая зависимость разрешима (var же), во втором — нет

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

потому что в первом случае циклическая зависимость разрешима (var же), во втором — нет

Хм... Но всё же не очень понятно, почему. Это ведь тоже зависимость. Autowired конструкторы жёстче? Или момент соединения бинов у autowired property позже?

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

Переписывай на корутины ?

Хм... Но всё же не очень понятно, почему. Это ведь тоже зависимость. Autowired конструкторы жёстче? Или момент соединения бинов у autowired property позже?

В коде явно видно, что в первом случае объект нужно сначала создать, потом заинжектить. Во втором это делается одним махом.

В коде явно видно, что в первом случае объект нужно сначала создать, потом заинжектить. Во втором это делается одним махом.

Понятно, спасибо. :)

Переписывай на корутины ?

хотелось бы прикрутить рх + котлин всё таки. потом уже корутины буду юзать

не комильфо на пол пути бросать

хотелось бы прикрутить рх + котлин всё таки. потом уже корутины буду юзать

А зачем? Лучше ж сразу корутины

А зачем? Лучше ж сразу корутины

+

А зачем? Лучше ж сразу корутины

почти весь проект уже написан на рх

хочу доделать

потом версию с корутинами напишу

+

На фоне парк Галицкого?)

потом версию с корутинами напишу

Ага, рефакторить больше

Кайф

потом версию с корутинами напишу

ого, много свободного времени

так что, может есть у кого идеи, что не так?

На фоне парк Галицкого?)

Да)

ого, много свободного времени

он не большой

где альтернатива Flowable из RxJava2 в Coroutines?

где альтернатива Flowable из RxJava2 в Coroutines?

channel, нет?

channel, нет?

нет. это Publish в RxJava2

Channel, да

Каналы бывают разные Черные белые красные

не. вы путаете. Room в RxJava2 возвращает с помощью  Flowable

не. вы путаете. Room в RxJava2 возвращает с помощью  Flowable

При чём здесь Room?

При чем здесь room?

На странице корутин есть таблица, что чем заменять.

я прекрасно понимаю, как работают Channels. просто, где реактивный подход-то? неужели мне самому нужно сказать Coroutine обновлять RecyclerView, если я в БД добавлю данные?

я прекрасно понимаю, как работают Channels. просто, где реактивный подход-то? неужели мне самому нужно сказать Coroutine обновлять RecyclerView, если я в БД добавлю данные?

не, подписаться на канал, обновлять при каждом изменении

не, подписаться на канал, обновлять при каждом изменении

это немного другое. вообщем нашел вот это : https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive/kotlinx-coroutines-rx2

не, подписаться на канал, обновлять при каждом изменении

хотя придется так сделать. уж не очень люблю добавлять Channel в проект

это немного другое. вообщем нашел вот это : https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive/kotlinx-coroutines-rx2

а coroutines уже не экспериментальные, а релизные?

Я: пора переходить на котлин! Kotlin: Unresolved reference: Any

а coroutines уже не экспериментальные, а релизные?

до сих пор экспериментальный

Я: пора переходить на котлин! Kotlin: Unresolved reference: Any

где я уже облажался?

а coroutines уже не экспериментальные, а релизные?

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

а coroutines уже не экспериментальные, а релизные?

а какая разница?

а какая разница?

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

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

Что-нибудь поменяется, но незначительно

а какая разница?

AndroidX релизнули 21 сентября, и долгое время она была в бете. и так как она была в бете, многие библиотеки не решались переходить на AndroidX. и вот в 21 сентября выходит AndroidX, а многие либы просто не готовы моментально перейти в AndroidX. из-за чего просто работа встала. переходить-то мы перешли в AndroidX, а из-за того, что многие UI библиотеки резко стали legacy, то работа реально встала

то есть сейчас корутины экспериментальные в 1.2, а в 1.3rc уже релизные?

то есть сейчас корутины экспериментальные в 1.2, а в 1.3rc уже релизные?

rc - это release candidate

это почти что релизные

но это почти

rc - это release candidate

это я понимаю

я к тому, что в kotlin 1.2 корутины будут экспериментальными, правильно?

потому что 1.2 stable, а 1.3 только rc

AndroidX релизнули 21 сентября, и долгое время она была в бете. и так как она была в бете, многие библиотеки не решались переходить на AndroidX. и вот в 21 сентября выходит AndroidX, а многие либы просто не готовы моментально перейти в AndroidX. из-за чего просто работа встала. переходить-то мы перешли в AndroidX, а из-за того, что многие UI библиотеки резко стали legacy, то работа реально встала

ну не сравнивай продукты JB и продукты Google

я к тому, что в kotlin 1.2 корутины будут экспериментальными, правильно?

В 1.2 они ещё эксперементальные, а скоро 1.3 релизнут, там они релизные.

ну не сравнивай продукты JB и продукты Google

+

В 1.2 они ещё эксперементальные, а скоро 1.3 релизнут, там они релизные.

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

AndroidX релизнули 21 сентября, и долгое время она была в бете. и так как она была в бете, многие библиотеки не решались переходить на AndroidX. и вот в 21 сентября выходит AndroidX, а многие либы просто не готовы моментально перейти в AndroidX. из-за чего просто работа встала. переходить-то мы перешли в AndroidX, а из-за того, что многие UI библиотеки резко стали legacy, то работа реально встала

От корутин хотя другие либы не зависят.

JB занимаются разработкой разработческих инструментов, их прибыль напрямую зависит от их качества. Прибыль Google зависит от качества их поиска, на разработческие штуки им вообще плевать.

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

4 числа, по идее

4 числа, по идее

а где можно узнать эту инфу?

а где можно узнать эту инфу?

https://kotlinconf.com/

ERROR: S client not available

Как гарантированно избежать ConcurrentModificationException при работе с коллекцией?

На странице корутин есть таблица, что чем заменять.

Это хде таблица?

Как гарантированно избежать ConcurrentModificationException при работе с коллекцией?

не изменять коллекцию, пока итерируешь её / использовать персистентные коллекции

https://kotlinconf.com/

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

Как гарантированно избежать ConcurrentModificationException при работе с коллекцией?

Не пользоваться мутабельными коллекциями?

AndroidX релизнули 21 сентября, и долгое время она была в бете. и так как она была в бете, многие библиотеки не решались переходить на AndroidX. и вот в 21 сентября выходит AndroidX, а многие либы просто не готовы моментально перейти в AndroidX. из-за чего просто работа встала. переходить-то мы перешли в AndroidX, а из-за того, что многие UI библиотеки резко стали legacy, то работа реально встала

https://developer.android.com/jetpack/androidx/migrate#migrate enableJetifier, или тут про другое?

Это хде таблица?

Уже не знаю. Вот есть нечто похожее https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/coroutines-guide-reactive.md

но несмотря на это, некоторые библиотеки все равно жалуются

Не пользоваться мутабельными коллекциями?

а если необходимо сделать очередь загрузки в несколько потоков с ограничением в N загрузок одновременно?

не, подписаться на канал, обновлять при каждом изменении

сделал по твоему способу. thank you! просто запутался. проект гибрид из RxJava2 и Coroutines

а если необходимо сделать очередь загрузки в несколько потоков с ограничением в N загрузок одновременно?

map/reduce?

map/reduce?

каким образом map/reduce поможет избежать concurrent modification exception?

каким образом map/reduce поможет избежать concurrent modification exception?

map/reduce преполагает, что ты сначало получаешь данные, а потом их объединяешь, тебе тут как бы не понадобятся мутабельные коллекции

Можно посмотреть например на дизайн java Stream api (госпади помилуй), там как раз все операции в collect описываются как пребразование + склеивание

И это было сделано для concurrent Streams

а если необходимо сделать очередь загрузки в несколько потоков с ограничением в N загрузок одновременно?

Канал (ограниченного размера) + Диспатчер с ограниченным кол-вом потоков?

где я уже облажался?

Вероятно stdlib не подключил

Канал (ограниченного размера) + Диспатчер с ограниченным кол-вом потоков?

Надо над этим подумать. Спасибо.

https://m.habr.com/post/425077/

https://m.habr.com/post/425077/

там неточности есть кое-где, вечерком подправлю =)

и надо было про when написать, он вообще не очевидный)

spring fu конечно прикольно выглядит... на ktor смахивает, но нафиг тащить весь спринг если можно просто ktor заюзать??

spring fu конечно прикольно выглядит... на ktor смахивает, но нафиг тащить весь спринг если можно просто ktor заюзать??

Звучит как "спринг не нужен"

Звучит как "спринг не нужен"

Всё так

Ну если есть время писать свой spring - то да, а если бац-бац и в продакшен то spring вполне ок

https://m.habr.com/post/425077/

а инлайн классы не такие уж и "бесплатные", хотя я наверное много хочу

а инлайн классы не такие уж и "бесплатные", хотя я наверное много хочу

они бесплатные в плане памяти и GC pressure на рантайме

они бесплатные в плане памяти и GC pressure на рантайме

не это отлично, но отдельный класс генеритсья, нужно быть осторожним. Я думал там полностью на статик-методах сделано (без класса)