RxJava в Android — все таки «мода» или «острая необходимость»?

Question

[nikitosgleb]

Все больше работадателей требуют знания RxJava. Все больше проектов нужно поддерживать уже реализованных в RX.
1. Почему никто толком не может объяснить, зачем rx в Android-е?
2. Неужели Android SDK так убог, что нет альтернатив?
3. Как раньше справлялись без RX в Android?
4. Какая асинхронность??? - если её в принципе в Activity и Fragments не должно быть? (есть Services для этого)
5. Почему уже 3-4-ый год всплеска RX в Android - но (так сказать "официальные отцы") Google - молчат как рыба об лед?
6. Почему эталонный Google IO App - не переписан еще под RX?
7. Rx - изобрели для высоконагруженных серверов, парадигма уже залезла в mobile,
но Java -серверные разработчики - до сих пор активно её не используют (таких еще не встречал).... где логика?
8. Как я понимаю - классические проблемы Android разработки, Rx так и не решил
(Runtime Change Configuration - ??? Interprocess - ??? Возобновление - работы (onRestoreStateInstance) после "прибития" Activity???, утечки памяти в inner-классах и слушателях - ???)
9. AOSP - написан императивно, писать поверх - функционально - невольно принуждает к пляскам, бубнам и велосипедам - в итоге все равно проект очень далек - от "чисто функционального" - не так ли?
10. Как Самая Реактивная, Функциональная, Масштабируемая парадигма от
Virgil Dobjansky(Google IO 2010, 3 Android App Patterns) - оказалась "негодной"?
11. почему iOS братья - остаются более консервативными - и до сих пор обходятся?

Ходят какие-то люди, всем говорят - что надо, но никто не говорит - зачем, вручают какие-то умные книжки - весьма далекие от реальной жизни, ссылаются на своих rx-"гуру".
Люди Объясните пожалуйста )) как быть? во что верить? с учетом современных реалий, простому смертному Android-Разработчику? Зачем мне это?

Спасибо

Answer 1

[xmoonlight]

ГЛАВНЫЙ КОЗЫРЬ RxJava: УДОБСТВО КОДИРОВАНИЯ и ЭКОНОМИЯ ВРЕМЕНИ НА РАЗРАБОТКУ и как следствие чуть ли ни мгновенный выпуск продукта в паблик.
МИНУС: доп. время на исполнение, т.к. это "прослойка".

А теперь, про остальное:
Если кратко: почему для простых операций ГРАМОТНЫЕ КОДЕРЫ не подключают jquery, а пишут на нативном javascript'e? Чтобы обеспечить приложению более высокую производительность.

RxJava - это как бы тот же jquery (или фреймворк), т.е. еще одна "прослойка" уменьшающая время разработки и упрощающая процесс написания кода для кодеров, НО!!! в разы увеличивающая время исполнения и требования к "железу".

RxJava в Android — все таки «мода» или «острая необходимость»?

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

Действительно, Google понимает, что отношение показателя рынка разработчиков к производительности готовых приложений у него: 80/20, в то время как у других: 20/80 (Nokia та же) и что скоро Google скорее всего поменяет язык разработки на свой (и всю парадигму в целом), в ином случае - они будут не конкурентно способны. Но пока они это делают - они будут молчать. Скорее всего они перейдут на javascript с нативным "движком" на ядре ОС.

Линки:
1. В 4-х частях перевод о RxJava для разработки под A...
2. Что ожидать от использования javascript в 2016 год...

Comments

[Rou1997]

jQuery не увеличивает требования к железу и почти не влияет на время исполнения, думаю, про Rx вы тоже сильно преувеличиваете.

[xmoonlight]

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

[Rou1997]

xmoonlight: А я сравнивал вес скрипта в байтах, и время в миллисекундах, с jQuery нет никаких заметных различий и не может быть, кстати, "в разы" тоже ни о чем не говорит, при загрузке страницы 500 мсек вместо 50 - это "в разы", но реально это не заметишь, есть толстые клиенты с API в формате JSON, есть просто сайты с избытком наворотов, вот там "тормоза", и, кстати, веб-сервисы вышеупомянутого Google тоже отличаются медленной загрузкой, но похоже кроме меня никто этого не видит (просто у меня интернет 8 Мбит/с, процессор 1.0 GHz, при этом я часто тороплюсь), и здесь все от рук зависит и от задачи, в целом нет смысла отказываться от быстроты разработки ради каких-то десяток, соток секунды.

[xmoonlight]

Rou1997: если операции, потребляющие время исполнения, не итеративны (не цикличны) и проект достаточно сложный - все верно: проще либу, в ином случае - я вынужден не согласиться.

Про скорость исполнения всё просто: есть 100% устройств, 40% из которых отстают по производительности, т.к. морально устарели.
Вы хотите чтобы приложение работало "без тормозов" на максимуме используемых устройств или только на оставшихся 60% ?

[Rou1997]

xmoonlight: Хватит нести чушь, у вас там 100500 итераций на клиенте, вот не могу себе такого представить, а если их 10 или 50 и все "тормозит", то дело не в jQuery, а в том, что вы на клиенте парсите JSON, рисуете анимашки, грузите что-то тяжелое AJAX'ом и т.д. - делаете то, что должен делать сервер, или чего делать вообще не стоит, если уж заботиться о быстродействии клиента.
Про устройства вообще не понял, что значит "морально устарели", если это медленный интернет, процессор, то у меня такое устройство, и, еще раз, проблем на нем не вижу, хоть убейте.

[xmoonlight]

Rou1997: "Устройства - медленный интернет"))
С Вами всё понятно и чушь я несу, а не Вы!)

[Rou1997]

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

[xmoonlight]

Rou1997: Верно. Исправил.

[nikitosgleb]

xmoonlight: Интересное мнение .... конечно, хотя очень похоже на правду.
Про фреймфорк-времянку, про js и молчание прямо подозрительное))
80/20 - так и есть))
Просто все вокруг кричат этот RX - пишут - восторженно хвалят.
Сначала думал - ну юзаете либу - и юзайте, их сто тыщ от Robo-спайсов до ретрофиксов -что ж кричать-то. А сейчас наблюдаю Хабр, кишащий - "манифестами" и "призывами" - вакансии почитал.... и вот решил, думаю, у пацанов на Toster поспрашивать, где я не там свернул или проспал что ли)))
Спасибо Вам!

[xmoonlight]

nikitosgleb: Да и я не 7 пядей во лбу))) Чем мог) Спасибо!

[belozerow]

Простите, но это чушь.

[Денис Загаевский]

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

[xmoonlight]

Денис Загаевский: если Вы задаёте подобные вопросы, Вы не разбираетесь ни в в JS, ни в Rx. Про JS - зависит от того, что именно необходимо реализовать и возможно ли это, используя эмуляцию работы функций и прочее на доступных в этой версии браузера технологиях. Про Rx - Вы же ответили сами: "читайте в интернетах" ))

[Денис Загаевский]

xmoonlight: угу, ещё я не разбираюсь в Java, Android, и вообще к программированию отношения не имею. По теме-то есть что сказать? Я читать в интернетах предлагал вовсе не про автомагическое ускорение разработки приложений до "почти мгновенного".
JQuery вам даёт кроссбраузерность многих вещей. Делая это " руками" вы, в конце концов, напишете свой кривой аналог. И зачем?

[xmoonlight]

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

[Денис Загаевский]

xmoonlight: O_o вы сделали весьма и весьма спорные утверждения, я задал вопросы - вы не ответили и теперь уже мне нечего сказать по существу? Хитрó :)

[xmoonlight]

Денис Загаевский: ок. Высказывайте свою точку зрения с обоснованием по моим утверждениям. (не задавая вопросы)

Answer 2

[Денис Загаевский]

Это удобно. Причин множество, читайте в интернетах.
Справлялись, например, лоадерами, асинктасками, и прочими велосипедами.
Асинхронно сходить в базу, например.
Гугл не молчит: https://github.com/google/agera
Во многих смартфонах уже 4-8 ядер, а юзать их без Rx довольно неудобно.
Rx не призван решать описанные вами проблемы.
Поверх есть всяческие RxBindings, используя их, можно легко уходить от императивного к реактивному.
В iOS, в общем, есть RxSwift. Но вообще-то сравнивать платформы так некорректно.

Comments

[nikitosgleb]

Agera заинтересовала(но она вот тока-тока еще свежая)
Конечно, если б была хоть мало-мальски какая-то официальная отмашка от них.
А так, rx конечно при первом знакомстве - создает очень неприятное впечатление*
и прежде чем нырять - хочется дважды подумать - мож и в лоадерах и хандлерах разобраться на 100%- они хоть ... ну ... типа "одобрено и рекомендовано" авторами оси.

Ps: неприятное - простите, никого не хочу обидеть. Но это факт, что - смотришь в код, в logcat - пошагово ничего не дебажится, и одни лишь классы U, A ))) и какие-то занебесные абстракции.

Спасибо, Денис!

[Денис Загаевский]

nikitosgleb: Retrofit, dagger, butterknife - к примеру, тоже "не одобрены авторами оси", ну и что? Ждать одобрения от гугла глупо. Агера ещё ОЧЕНЬ сырая, на самом деле.
Ну а про неприятно - возможно, вы неправильно его готовите. Не надо дебажить map, надо дебажить mapper, условно говоря.
И ещё про гугл хотел добавить - они выкатили Android data binding, который нужен для MVVM, по сути. А двигают MVP. Странно.

[nikitosgleb]

Денис Загаевский: databinding - посматривал, но все тож руки еще недоходили(интересная штука). ...тоже верно... не везде у них у самих прослеживается "единство" (взять material design))) ну... ок ... понял

[werktone]

Денис Загаевский: А где гугл двигают MVP? Вот это https://github.com/googlesamples/android-architect... не считается.

[Денис Загаевский]

werktone: почему не считается?

[werktone]

Денис Загаевский:
>Android data binding, который нужен для MVVM, по сути.

data binding – просто инструмент, использовать можно по разному

[werktone]

Денис Загаевский: хотя бы потому, что в подписи написано "A collection of samples to discuss" и "This project is built by the community"

[werktone]

Под iOS еще есть ReactiveCocoa, которая появилась сильно раньше RxJava.

Answer 3

[Александр Варакосов]

Во-первых, элементы реактивного программирования в андроиде были и есть. Вспомните о DataSetObserver.
Если вы современный разработчик, то используя RecyclerView, создаёте для него адаптер содержащий имплементацию этого интерфейса, а значит поток данных управляет выполнение программы - это элементы Rx.
Во-вторых, когда вы обрабатываете данные, хочется оперативно знать об их изменении, здесь реакт на своём месте. Но, часто из Rx пытаются создать двухстороннюю связь модель-представление, а это нарушает принципы MVC.
Об асинхронности. Java изначально многонитевый язык. Вы можете создавать нити сколько угодно и где угодно. И не забывайте Service - не асинхронен!

Comments

[nikitosgleb]

Да, вы правы, есть механизмы из Content Provider-а уведомляться. и др. Loader's опять таки.... Service - не асинхронен - от него сложно получить результат - только события.
Асинхронности в UI - не должно быть, возможно не очень корректно. Я имел ввиду - что в Activity и фрагментах - никаких трейдов, executors, даже асинктаскков - максимум подтянуть данные Loaderom - ну это единственное место, потокам в UI.
Глядя, через эту призму - конечно не понятно, зачем RX решает проблему многопоточности, когда если её исключить)) и решать не нужно.
В целом, я понял Вас, Александр, thanks!

Answer 4

[Rou1997]

"1. Почему никто толком не может объяснить, зачем rx в Android-е?"
Потому что им сказали - надо использовать, они используют, им не объясняли, и они не дошли до этого сами, поэтому не понимают, и вам объяснить не могут.
Видимо, это одна из проблем "умных книжек", их авторы доносят до читателя мысль, но не заботятся об ее объяснении, вот и получаются "зомби", бездумно скандирующие лозунги.
А вы - дойдите. Сравните с ним и без него, подумайте, для каких задач он хорошо подходит.
Используйте это в своей работе, и другим потом объясняйте.

"2. Неужели Android SDK так убог, что нет альтернатив?"
Очень убог, был бы у вас шире кругозор, вы бы просто поражались с него.

"Какая асинхронность??? - если её в принципе в Activity и Fragments не должно быть?"
Как это не должно быть? Скорее - наоборот, любой качественный UI должен быть асинхронным, то есть все тяжелые операции - в потоке, отдельном от UI.

"классические проблемы Android разработки"
По мне, основная проблема разработки под Android - это то, что пишешь много, а делаешь мало (как девиз jQuery, только наоборот). Библиотеки очень многословны, IDE - не заточены под Rapid Application Development.
Может быть, Rx частично решает эту проблему в некоторых случаях?

Comments

[nikitosgleb]

Rou1997, Спасибо.

1) Видимо, вы правы.

2) Возможно. На кругозор, времени сейчас мало(да и не гонюсь особо за широтой). Пока фокус на том, что кормит)

Асинхронность - "все тяжелые операции - в потоке, отдельном от UI."
Всё верно, такие операции называют "фоновыми задачами" - всегда во все времена (по крайней мере, в документации, во всех официальных примерах) - учат сервисам поручать эту работу, а уж внутри служб - все может быть и линейно и попорядку(синхронно).
Ну ок ... для более гладкого "стыка" "фона" и "нефона" есть еще Loaders и Broadcasts

3) "пишешь много, а делаешь мало" - есть такое. Конечно досадно, но если открыть коды стоковых (вроде простеньких) апов - "Календарь" "Контакты" - понимаешь что это нормально. Я вижу что, для Android - это так - да, много писанины - для вполне тривиальных вещей. Ну вот такая ОС...

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

Просто странно... с развитием платформы - Google перекрывает потихоньку дыры.... и видится, что все "неровности" в разработке и коде - в максимально удачном духе уже перекрыты. То что впринципе возможно было как то подточить - потихоньку подтачивается.
Вряд ли бы они выбрали неправильный путь. Видится что на данном этапе эволюции - код Android Open Sorce достаточно хорош и вышлифован - и это вроде как лучший источник подходов и примеров. Ну ....из того что можно было из него вообще сделать.

Rou1997, Еще раз спасибо, возьму на заметку ваши доводы.

[Rou1997]

nikitosgleb:

Всё верно, такие операции называют "фоновыми задачами"
учат сервисам поручать эту работу

Не путайте фоновые и асинхронные. Фоновые задачи всегда асинхронные, но асинхронные не всегда фоновые.
Приведу пример. Приложение Блокнот. Нажимаю кнопку Открыть, выбираю файл, он "грузится", а файл тяжелый, времени займет много.
Это не фоновая задача, создавать сервис здесь излишне. Но UI не должен зависать на этот момент, поэтому создаем поток или AsyncTask, и в нем "грузим" файл, тем самым делаем задачу асинхронной, но не фоновой.

но если открыть коды стоковых (вроде простеньких) апов - "Календарь" "Контакты" - понимаешь что это нормально

Из этого следует только то, что SDK убог. Но ни в коем случае не то, что вам тоже стоит так писать.
У вас свои задачи, у разработчиков тех "апов" были свои.
Меряйте себя своей линейкой, а не чужой.

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

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

Вряд ли бы они выбрали неправильный путь

Еще раз: у них свой путь, у вас свой.
Путей - много, нет такого, что один правильный, остальные - неправильные.
У меня есть четкая цель - это RAD. А тот самый Google этой концепции совсем не следует. И что? У меня широкий кругозор, поэтому я не прогибаюсь под Google, не учусь у него жизни, я знаю, что еще есть Borland и Microsoft, которые как раз следуют RAD или следовали раньше, и тоже достигли успеха. Поэтому авторитетами для меня являются они, а Google пошел вон, и абсолютно неважно, что я работаю и с его технологиями тоже, хотя, конечно, быть первопроходцем поначалу тяжелее.

Answer 5

[Dmtm]

все верно, rxjava не решает основных проблем с жизненным циклом, бесполезная вещь,
пока не знаю ничего лучше очереди задач (BlockingQueue), пула потоков (Thread) и EventBus

"Какая асинхронность??? - если её в принципе в Activity и Fragments не должно быть?"
Как это не должно быть? Скорее - наоборот, любой качественный UI должен быть асинхронным, то есть все тяжелые операции - в потоке, отдельном от UI.

вот поэтому UI (слой View) не асинхронный, асинхронные операции вне Activity и Fragments