RxJava. Убираем магию

[xGromMx]

Сколько можно мусолить про Rx?) Хватит глянуть одного видео про это и все http://xgrommx.github.io/rx-book/content/resources/video/index.html (первое по списку)

[KomarovI]

Смею с Вами не согласиться — RxJava ( а в особенности — вторая ветка ) является очень даже глубокой темой для обсуждения, другое дело, что таких триалов как у автора в сети, равно как и на хабре, тысячи, а вот хороших комплексных юз-кейсов в продашне как раз-таки не хватает.

[Vacxe]

Я долго боялся использовать RxJava в production

Скажу честно, мы вот полгода как выпустили продукт, который 100% Kotlin и на «Реактивной тяге».

Почему вы боитесь Rx??? Вы просто не умеете его готовить!!! Он вкусный, надо просто научиться.

PS. Никогда. Повторяюсь Никогда, не используйте конструкции «Зачем мне использовать новую технологию, если я могу писать стандартными методами».

[xGromMx]

А еще он очень простой) Правда могут быть у новичков запарки с Subjects ну и с подогревом или охлаждением Observable) Как кстати Kotlin в бою?

[vba]

Kotlin для Android хорош, я долго ждал выхода. До этого пробовал писать под Android на Scala и даже Groovy. В Scala убивало то что компиляция долгая и официальный джар нельзя использовать из-за размера, приходилось обходными путями. Ну а Groovy тоже мороки навалом. Порог вхождения в язык Kotlin почти нулевой, да и генерация из Java помогает очень. Впечатления только положительные, ждем версию 1.1.

[xGromMx]

ну у скалы рантайм под андроид очень большой и иногда прогвард не справляется. А вот у Kotlin есть еще прикольная штука Anko

[vba]

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

[Optik]

Начиная с 2.12 у скалы размеры сильно сократились.

[yarulan]

И минимальная версия джавы стала 8.

[Vacxe]

Попробуйте Kotlin Android Extensions

[xGromMx]

А вообще тут много чего) https://kotlin.link/

[KomarovI]

И с Вами также смею не согласиться, rx далеко не простой инструмент, многие по нескольку лет осваивают его. Как минимум понимание проблемы упомянутых Ваши Subject-ов доходит не сразу до человека, начавшего свой «реактивный» путь

[Vacxe]

Котлин в бою превосходен. Код более удобочитаем и понятен. Ушли вечные проблемы Java с NPE. Скажу честно. Год как пишу на Kotlin, возвращаться не Java нет желания. Всем советую попробовать.

А у «Новичков» проблемы будут не только с Hot-Cold-Observable (Это лишь малая часть, которую легко выучить), а скорее с правильной архитектурой на RxJava

[Bringoff]

Никогда. Повторяюсь Никогда, не используйте конструкции «Зачем мне использовать новую технологию, если я могу писать стандартными методами».

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

[Vacxe]

Скорее всего мы с вами просто о разных вещах подумали.
Допустим мы вошли в какой нибудь старый проект интерпрайза, где уже оверхед костылей и есть свой кодстайл. Естественно, внедрять в него новомодные штуки-дрюки не имеет смысла, так как вероятнее всего это приведет к новым костылям.
Однако, если мы начинаем новый проект и у нас есть свобода выбора технического стека, то почему бы сразу не начать строить проект с использованием тех же самых Di, Rx, DataBinding?

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

[Bringoff]

Di — это вообще не о библиотеках, а принцип разработки inversion of control. И реализовать этот принцип вполне можно без даггера того же. Rx — опять же вкусовщина. Если кто-то выберет lightweight stream api + bolts, или еще что-то типа async job queue, я его осуждать не буду. Data binding — интересная штука, но в ограниченных случаях, на полноценное mvvm в андроиде не легло у нас.

[AlexeyGorovoy]

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

[adev_one]

Всё же, не зря боялся. На тестировании всплыло, например, что на некоторых устройствах приложение падает при ∽50 одновременных соединениях. Или то, что где-то InAppBilling API не цепляется к серверу, не выдавая никакой ошибки (даже timeout). А теперь на нём завязаны некоторые запросы.

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

[vba]

Здесь вы ошибаетесь, проводя параллели со streams api. Не нужно представлять rxJava как библиотеку для java <v8. Между streams api и реактивными расширениями есть одна существенная разница, которая заключается в том что streams по сути построены на pull а observable построены на push. Результат таков что на streams можно "подписаться" только один раз а у observable может быть сколько угодно подписчиков.

По мне так главная мешанина с rxJava начинается с того что люди мешают многопоточный и асинхронные подходы. Просто в Java из за отсутствия машины состояний(state machine) асинхронизм построен поверх многопоточных библиотек.

В Kotlin 1.1, кстати, обещают ко-рутины построенные поверх машины состояний(state machine).

[zagayevskiy]

А зачем вы дублируете машину состояний (state machine)? И что это значит?

Просто в Java из за отсутствия машины состояний(state machine) асинхронизм построен поверх многопоточных библиотек.

[vba]

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

[adev_one]

Согласен, что Rx не заканчивается на замене streams, но применение этого, скорее, про сервера и Scala. Я пока не видел кейсов под Android, в которых долгоиграющий Observable или Flowable приносит больше пользы, чем проблем из-за сложного жизненного цикла UI-компонентов (потребителей данных), который нужно обслуживать. Буду рад, если вы приведёте пример

[vba]

Я например был вдохновлен вот этим примером от команды Яндекса.

[adev_one]

Спасибо, действительно интересный кейс

[KomarovI]

Пример — пагинация списка, здесь можно посмотреть мою реализацию с использованием RxJava, а также еще пару кейсов использования реактивного расширения в Android: https://gitlab.com/i.komarov/my-feed

[adev_one]

Спасибо за пример.

Смущает использование Flowable, он может упасть из-за размера буфера и имеет больший оверхед, чем Observable. Так же не понимаю, зачем нужен synchoronized в BindableAdapter. Он тоже создаёт оверхед и не имеет смысла. RxJava позволяет писать код без синхронизаций.

[anton9088]

А как в RxJava решается проблема, когда запрос к сети завершился, когда Activity было свернуто? В Rx же так же в onResume идет подписка и в onPause отписка? И как сделать так чтобы не было повторного запроса, если он еще выполняется, при пересоздании Activity (речь не про поворот экрана, а про то что Activity можно закрыть кнопкой назад, а потом вернуться обратно).

[kuchanov]

Можно по разному. Вот, например, не идеальный вариант, но вполне рабочий. В синглтоне все операции идут, а фрагмент/активити лишь подписываются для получения последней полученной информации:

Используем RxJava и Retrofit на Android, учитывая поворот экрана

[Vacxe]

Дорогой мой друг, это решается построением человеческой архитектуры (допустим MVP) где при паузе происходит дроп View. Таким образом даже если Subscription завершит свою работу мы не получит ответ в пустой вью. Ну или отписку можно делать.

Это нужно для того, что если пользователь сворачивает активити, некоторые процессы должны продолжаться. Для повторной переподписки на presenter.

Извиняюсь за офтоп. Ушел чутка от темы)

[shakagamii]

Тут больше вопрос не к Rx, а к используемому шаблону проектирования.
Используя MVP, вы делаете любую реализацию какого-нить «кеша» в презентере. А потом просто опрашиваете презентер, если данные есть, берете готовые, если нет загружаете новые. Если загрузка в процессе, то просто ждете конца.

В Rx же так же в onResume идет подписка и в onPause отписка?

Нет, Rx не привязан к контексту активити.

[Vacxe]

Тут bind-unbind самого View имел ввиду

[Gustik]

Можно использовать паттерн MVP и делать запросы в presenter. Ну а чтобы повторно запрос не выполнялся, можно хранить состояние представления и перерисовывать при необходимости. Например как в moxy.

[AndroidNoob]

Observable.just(42)
                .subscribeOn(computation())

Если не ошибаюсь с оператором just subscribeOn бесполезен. Код все равно выполнится на вызывающем потоке. Для того чтобы все работало как Вы хотите необходимо, например, еще обернуть в defer

[adev_one]

Да, верно, вычисление самого числа произойдёт в основном потоке, но исполнение ObservableJust — в потоке для вычислений. Здесь я использовал just просто чтобы не усложнять пример, а уже на github выложил более сложный кейс

[3draven]

Колупаю rx2, после использования rx я в затруднении :), прочитал про отсутствие backpressure в Observable и наличие в Flowable. При этом в пояснениях указано, что если вы имеете дело с генерацией событий в размере «около 1000», то используйте Obsrvable, в противном случае Flowable. Я так понимаю, что если Observable генерит события быстрее чем может обработать Subscriber, то он рухнет с исключением. В данном случае просто предполагается, что я в обязательном порядке реализую логику кэширования самостоятельно или я что то не понимаю в использовании Observable в rx2?