is in the first article, where I introduced the basics of RxJava. In the second part, I showed you the power of operators. But you may still not be convinced. In this article, I will show you some other benefits of RxJava, I believe this is enough for you to use Rxjava.
Error handling
So far, we have not introduced the onComplete() and onError() functions. These two functions are used to notify subscribers that the observed object will stop sending data and why (successful completion or error).
The following code shows how to use these two functions:
Observable.just("Hello, world!")
.map(s -> potentialException(s))
.map(s -> anotherPotentialException(s))
.subscribe(new Subscriber<String>() {
@Override
public void onNext(String s) { System.out.println(s); }
@Override
public void onCompleted() { System.out.println("Completed!"); }
@Override
public void onError(Throwable e) { System.out.println("Ouch!"); }
});
PotentialException() and anotherPotentialException() in the code may throw exceptions. Each Observerable object will call the onCompleted() or onError() method when it is terminated, so "Completed!" or "Ouch!" will be printed in the Demo.
This mode has the following advantages:
1. OnError() will be called whenever an exception occurs,
which greatly simplifies error handling. Just need to handle errors in one place.
2. The operator does not need to handle exceptions
. Exception handling is handed over to the subscriber. Once an exception is thrown in the operator call chain of Observer, the onError() method will be executed directly.
3. You can know when the subscriber has received all the data.
Knowing when a task ends can help simplify the flow of code. (Although it is possible that the Observable will never end)
I find this way of error handling simpler than traditional error handling. In traditional error handling, errors are usually handled in each callback. Not only does this lead to duplicate code, but it means that each callback must know how to handle errors, and your callback code will be tightly coupled to the caller.
With RxJava, Observable objects don't need to know how to handle errors at all! Operators also do not need to handle error states - as soon as an error occurs, the current and subsequent operators are skipped. All error handling is left to the subscriber.
The scheduler
assumes that the Android app you write needs to request data from the network (it feels like this is necessary, is there a stand-alone?). Network requests take a long time, so you plan to load the data in another thread. Then here comes the problem!
Writing multi-threaded Android applications is difficult because you have to make sure that the code runs in the correct thread, otherwise the app may crash. The most common is to update the UI on a non-main thread.
With RxJava, you can use subscribeOn() to specify the thread on which the observer code runs, and observerOn() to specify the thread on which the subscriber runs:
myObservableServices.retrieveImage(url)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(bitmap -> myImageView.setImageBitmap(bitmap));
Is not it simple? Any code that executes in front of my Subscriber is running in the I/O thread. Finally, the code that manipulates the view runs on the main thread.
The best part is that I can add subscribeOn() and observerOn() to any Observable. These two are also operators! . I don't need to care about the Observable object and what operators are on it. Scheduling in different threads can be achieved using only these two operators.
If using AsyncTask or something similar, I would have to carefully design my code to figure out the parts that need to be executed concurrently. With RxJava, I can keep the code the same and just call these two operators when I need concurrency.
Subscriptions
When Observable.subscribe() is called, a Subscription object is returned. This object represents the connection between the Observable and the Subscriber.
ubscription subscription = Observable.just("Hello, World!")
.subscribe(s -> System.out.println(s));
You can use this Subscription object later to manipulate the relationship between the Observer and the Subscriber.
subscription.unsubscribe();
System.out.println("Unsubscribed=" + subscription.isUnsubscribed());
// Outputs "Unsubscribed=true"
Another benefit of RxJava is that it stops the entire call chain when it handles unsubscribing. If you're using a complex set of operators, calling unsubscribe will terminate where it's currently executing. No extra work required!
Summary
Remember that this series is just an introductory introduction to RxJava. There are more features in RxJava that I haven't covered for you to explore (such as backpressure). Of course I don't use all of my code reactively - I only use reactive code when the code is so complicated that I want to break it down into simple logic.
Originally, my plan was for this article to be the conclusion of the series, but I've received many requests for my introduction to using RxJava in Android, so you can move on to the fourth article. I hope this introduction will get you started with RxJava. If you want to learn more, I recommend you to read the official wiki of RxJava.