Observable and Flowable interfaces seem to be identical. Why Flowable was introduced in RxJava 2.0? When should I prefer to use Flowable over Observable?
Observable: emit a stream elements (endlessly) Flowable: emit a stream of elements (endlessly, with backpressure) Single: emits exactly one element. Maybe: emits zero or one elements.
If there is a possibility that the consumer can be overflooded, then we use Flowable. One example could be getting a huge amount of data from a sensor. They typically push out data at a high rate. In the previous version of RxJava, this overflooding could be prevented by applying back pressure.
Single and Completable are new types introduced exclusively at RxJava that represent reduced types of Observable , that have more concise API. Single represent Observable that emit single value or error. You can think of the differences like the differences of a method that returns: Collection of Objects - Observable.
An Observable is like a speaker that emits the value. It does some work and emits some values. An Operator is like a translator which translates/modifies data from one form to another form. An Observer gets those values.
As stated in the documentation:
A small regret about introducing backpressure in RxJava 0.x is that instead of having a separate base reactive class, the Observable itself was retrofitted. The main issue with backpressure is that many hot sources, such as UI events, can't be reasonably backpressured and cause unexpected
MissingBackpressureException
(i.e., beginners don't expect them).We try to remedy this situation in 2.x by having
io.reactivex.Observable
non-backpressured and the newio.reactivex.Flowable
be the backpressure-enabled base reactive class.
Use Observable
when you have relatively few items over time (<1000) and/or there's no risk of producer overflooding consumers and thus causing OOM.
Use Flowable
when you have relatively large amount of items and you need to carefully control how Producer
behaves in order to to avoid resource exhaustion and/or congestion.
Backpressure When you have an observable which emits items so fast that consumer can’t keep up with the flow leading to the existence of emitted but unconsumed items.
How unconsumed items, which are emitted by observables but not consumed by subscribers, are managed and controlled is what backpressure strategy deals with.
Ref link
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With