Комментарии 35
Я долго боялся использовать RxJava в production
Скажу честно, мы вот полгода как выпустили продукт, который 100% Kotlin и на «Реактивной тяге».
Почему вы боитесь Rx??? Вы просто не умеете его готовить!!! Он вкусный, надо просто научиться.
PS. Никогда. Повторяюсь Никогда, не используйте конструкции «Зачем мне использовать новую технологию, если я могу писать стандартными методами».
Kotlin для Android хорош, я долго ждал выхода. До этого пробовал писать под Android на Scala и даже Groovy. В Scala убивало то что компиляция долгая и официальный джар нельзя использовать из-за размера, приходилось обходными путями. Ну а Groovy тоже мороки навалом. Порог вхождения в язык Kotlin почти нулевой, да и генерация из Java помогает очень. Впечатления только положительные, ждем версию 1.1.
А у «Новичков» проблемы будут не только с Hot-Cold-Observable (Это лишь малая часть, которую легко выучить), а скорее с правильной архитектурой на RxJava
Никогда. Повторяюсь Никогда, не используйте конструкции «Зачем мне использовать новую технологию, если я могу писать стандартными методами».
Вы так говорите, будто это что-то плохое. Лучше, конечно, использовать в продакшене первую попавшуюся хайповую библиотечку и фреймворк. В крайности бросаться не надо, многие (да что там, большинство) приложения жили без Rx, живут и вполне себе проживут дальше. И странно их за это осуждать.
Допустим мы вошли в какой нибудь старый проект интерпрайза, где уже оверхед костылей и есть свой кодстайл. Естественно, внедрять в него новомодные штуки-дрюки не имеет смысла, так как вероятнее всего это приведет к новым костылям.
Однако, если мы начинаем новый проект и у нас есть свобода выбора технического стека, то почему бы сразу не начать строить проект с использованием тех же самых Di, Rx, DataBinding?
Я скорее имел ввиду, что если мы начинаем как раз новый проект, то имеет смысл пробовать новые технологии, о которых все говорят.
Di — это вообще не о библиотеках, а принцип разработки inversion of control. И реализовать этот принцип вполне можно без даггера того же. Rx — опять же вкусовщина. Если кто-то выберет lightweight stream api + bolts, или еще что-то типа async job queue, я его осуждать не буду. Data binding — интересная штука, но в ограниченных случаях, на полноценное mvvm в андроиде не легло у нас.
Осторожность связна не столько с самим Rx, как бы он ни был хорош, сколько с совместимостью со всеми остальными технологиями, которые мы, порой вынужденно, используем
Здесь вы ошибаетесь, проводя параллели со streams api. Не нужно представлять rxJava как библиотеку для java <v8. Между streams api и реактивными расширениями есть одна существенная разница, которая заключается в том что streams по сути построены на pull а observable построены на push. Результат таков что на streams можно "подписаться" только один раз а у observable может быть сколько угодно подписчиков.
По мне так главная мешанина с rxJava начинается с того что люди мешают многопоточный и асинхронные подходы. Просто в Java из за отсутствия машины состояний(state machine) асинхронизм построен поверх многопоточных библиотек.
В Kotlin 1.1, кстати, обещают ко-рутины построенные поверх машины состояний(state machine).
А зачем вы дублируете машину состояний (state machine)? И что это значит?
Просто в Java из за отсутствия машины состояний(state machine) асинхронизм построен поверх многопоточных библиотек.
Можно по разному. Вот, например, не идеальный вариант, но вполне рабочий. В синглтоне все операции идут, а фрагмент/активити лишь подписываются для получения последней полученной информации:
Используем RxJava и Retrofit на Android, учитывая поворот экрана
Это нужно для того, что если пользователь сворачивает активити, некоторые процессы должны продолжаться. Для повторной переподписки на presenter.
Извиняюсь за офтоп. Ушел чутка от темы)
Используя MVP, вы делаете любую реализацию какого-нить «кеша» в презентере. А потом просто опрашиваете презентер, если данные есть, берете готовые, если нет загружаете новые. Если загрузка в процессе, то просто ждете конца.
В Rx же так же в onResume идет подписка и в onPause отписка?
Нет, Rx не привязан к контексту активити.
Observable.just(42)
.subscribeOn(computation())
Если не ошибаюсь с оператором just subscribeOn бесполезен. Код все равно выполнится на вызывающем потоке. Для того чтобы все работало как Вы хотите необходимо, например, еще обернуть в defer
RxJava. Убираем магию