How does Single differ from Observable?
Of course, it doesn't have all the methods that Observable has. The Single subscriber also differs in that it contains only two methods, not three. I think that you can find all the differences in terms of implementation in the documentation.
The question arises:
what caused such changes?
The answer is obvious: Single (which can even be understood from the name) contains only one element, unlike Observable.
Someone will think and say
pfff, so what? And I will always use Obsevable, let it have only one element.
In my opinion, there is nothing wrong with that, but are there any disadvantages from such use?
- If you know that you will be working with only one element, then there is no need to use Observable or, as they say, overkill;
- You also need to understand that Observable is heavier than Single (and they say that Single is even faster);
You say Single, hmm ...
In single, two situations are possible:
- one meaning
- exception
It is important to understand what you are trying to achieve, or what is your policy? If you think that an empty result is okay for you, then, most likely, Single will not suit you, but if it is not, and you know that the result must be, then Single is what you need. By the way, it's worth noting that Single does not have an empty () method. I decided to report this, just in case.
Yes, finally show me how to use this Single!
A common example from life. Let's assume we have a microservice architecture (I love microservices).
Input: We have three mikroservisa A , Bed and , the C .
A - orchestration service.
Task: make a request to service B and C from microservice A and aggregate the data.
Answer: of course, you can make a request to microservice B , and then to microservice Cand then aggregate data in microservice A, but then you have to wait for results from one microservice, and then from another. Wow, how long it is!
But remember that we have rx.Single, hooray!
Single<String> b = Single.fromCallable(() -> serviceA.getResponse()) .subscribeOn(Schedulers.io()); Single<String> c = Single.fromCallable(() -> serviceB.getResponse()) .subscribeOn(Schedulers.io()); Single.zip(b, c, (resultA, resultB) -> resultA + resultB);
And here it is!
What exactly ?
The request to microservice B and the request to microservice C occur independently of each other, and microservice A simply waits for the results.
Interesting
Here is a link to the documentation. Very good documentation. You can find a lot of useful things. Well, I can also recommend a book: "Reactive Programming with RxJava".