Android LiveData vs RxJava

We just’ve lunched Android project in which tried to adopt the Android Jet pack’s feature called LiveData and replace RxJava snippets with it.

Short story is “we’ve rollbacked all the changes and wiped out LiveData completely” and summary is “you do not need LiveData if already used to use RxJava but it worth to take look at LiveData if want to avoid RxJava learning curve”

First disadvantage of LiveData they are all about UI. It is cumbersome to use them to get updates from a service to service.

Next they do not give you freedom of to choose threads (do you need it?) — you only have “ui thread” and “current thread” and only one direction of switch “from current to ui”. Generally it is enough, but still brings some uneasiness. The worst thing is the sender of the change notification has to make switch. If a background service sends notification to live data object it must use postValue method to ensure the value change will be observed on the main UI thread. But who said the receiver will be ui? The RxJava’s approach to choose a thread during the subscription, not in time of the sending is much more appropriate.

Actually the only advantage of LiveData over RxJava we have noticed is they automatically subscribe and unsubscribe on Activity life cycle events (or over android components implementing life cycle). So loosing all the power of RxJava for sake of getting rid off, well, dozen lines like compositeDisposable.add(...) in onResume and oneCompositeDisposable.dispose in onPause looks like obvious overprice.

But from other hand. If one comes to me having not knowledge of RxJava i would definitely say: “Use LiveData instead — they will cover 90% of the real android developer needs, and you will be able to use them after few hours of reading”