RxJava in Android - all the same "fashion" or "urgency"?

Question

Java

More and more employers require knowledge of RxJava. More and more projects need to be supported already implemented in RX.
1. Why can't anyone really explain why rx is in Android?
2. Is the Android SDK so poor that there are no alternatives?
3. How did you manage without RX in Android before?
4. What asynchrony??? - if in principle it should not be in Activity and Fragments? (There are Services for this)
5. Why is it already the 3-4th year of the RX surge in Android - but (so to speak "official fathers") Google - are silent like a fish on ice?
6. Why is the reference Google IO App not yet rewritten for RX?
7. Rx - invented for high-load servers, the paradigm has already climbed into mobile,
but Java-server developers still don't actively use it (I haven't met such people before).... where is the logic?
8. As I understand it, the classic problems of Android development, Rx did not solve
(Runtime Change Configuration - ??? Interprocess - ??? Resume - work (onRestoreStateInstance) after "beating" Activity ???, memory leaks in inner-classes and listeners - ???)
9. AOSP - written imperatively, overwriting - functionally - involuntarily forces dances, tambourines and bicycles - in the end, the project is still very far away - from "purely functional" - isn't it? 10. How did Virgil Dobjansky
's Most Reactive, Functional, Scalable Paradigm (Google IO 2010, 3 Android App Patterns) fail?
11. why iOS brothers - remain more conservative - and still get by?
Some people walk around, they tell everyone what they need, but no one says why, they hand out some smart books - very far from real life, they refer to their rx-"gurus".
People Explain please)) how to be? what to believe? taking into account modern realities, a mere mortal Android Developer? Why do I need it?
Thanks

Answer 1

MAIN trump card of RxJava : CONVENIENCE OF CODING and SAVING OF TIME FOR DEVELOPMENT and, as a result, almost instantaneous release of the product to the public.
MINUS : extra. execution time, because this is the "layer".
And now, about the rest:
In short : why for simple operations LITERAL CODERS do not connect jquery, but write in native javascript'e? To provide the application with better performance.
RxJava is like the same jquery (or framework), i.e. one more "layer" that reduces development time and simplifies the process of writing code for coders, BUT!!! at times increasing the execution time and requirements for hardware.

RxJava in Android - all the same "fashion" or "urgency"?

this is a "temporary" framework, PR-I that can keep the mobile developer market for some time (gain time to release a replacement) on this platform.
Indeed, Google understands that the ratio of the developer market to the performance of finished applications is 80/20, while others have 20/80 (Nokia is the same) and that soon Google will most likely change the development language to its own (and all paradigm as a whole), otherwise they will not be able to compete. But as long as they do it, they will remain silent. Most likely they will switch to javascript with a native "engine" on the OS core.
Links:
1. 4 part translation about RxJava for A development...
2. What to expect from using javascript in 2016...

Answer 2

It's comfortable. There are many reasons, read on the Internet.
They coped, for example, with loaders, asynctasks, and other bicycles.
Asynchronously go to the database, for example.
Google is not silent: https://github.com/google/agera
Many smartphones already have 4-8 cores, and using them without Rx is rather inconvenient.
Rx is not intended to solve the problems you describe.
There are all sorts of RxBindings on top, using them, you can easily move from imperative to reactive.
iOS, in general, has RxSwift. But in general, comparing platforms is so incorrect.

Answer 3

Firstly, elements of reactive programming in android were and are. Think about DataSetObserver.
If you are a modern developer, then using RecyclerView, you create an adapter for it containing the implementation of this interface, which means that the data flow controls the execution of the program - these are Rx elements.
Secondly, when you process data, you want to quickly know about their change, here react is in its place. But, often they try to create a two-way model-view relationship from Rx, and this violates the principles of MVC.
About asynchrony. Java is inherently a multi-threaded language. You can create threads as much as you want, anywhere. And don't forget Service is not asynchronous!

Answer 4

"1. Why can't anyone really explain why rx is in Android?"
Because they were told - they must use it, they use it, they were not explained to them, and they did not get to it themselves, therefore they do not understand, and they cannot explain it to you.
Apparently, this is one of the problems of "smart books", their authors convey an idea to the reader, but do not care about explaining it, so you get "zombies", thoughtlessly chanting slogans.
And you come. Compare with and without it, think about what tasks it is well suited for.
Use it in your work, and then explain to others.
"2. Is the Android SDK so poor that there are no alternatives?"
It is very miserable, if you had a wider outlook, you would simply be amazed at it.
"What kind of asynchrony ??? - if in principle it should not be in Activity and Fragments?"
How should it not be? Rather, on the contrary, any high-quality UI should be asynchronous, that is, all heavy operations should be on a thread separate from the UI.
"classic problems of Android development"
For me, the main problem of Android development is that you write a lot and do little (like the motto of jQuery, only in reverse). Libraries are very verbose, IDEs are not designed for Rapid Application Development.
Maybe Rx partially solves this problem in some cases?

Answer 5

that's right, rxjava does not solve the main problems with the life cycle, a useless thing
until I know nothing better than the task queue (BlockingQueue), thread pool (Thread) and EventBus

"What kind of asynchrony ??? - if in principle it should not be in Activity and Fragments?"
How should it not be? Rather, on the contrary, any high-quality UI should be asynchronous, that is, all heavy operations should be on a thread separate from the UI.

that's why the UI (View layer) is not asynchronous, asynchronous operations outside of Activity and Fragments