Best suited for four scenarios with Rxjava processing

Let's start by introducing the four scenarios that Rxjava is most suitable for, and the code sample is based on RXJAVA1

Scenario One: Single-Request asynchronous processing

Because in the Android UI thread can not do some time-consuming operations, such as network requests, large file saving, etc., so in development often encounter asynchronous processing situation, our most typical use scenario is Rxjava+retrofit processing network requests

MyService MyService = retrofit.create (Myservice.class); Myservice.getsomething () . Subscribeon (Schedulers.io ()) . Observeon (Androidschedulers.mainthread ()) . Subscribe (This::updateui, this::showerror);

To make the code look concise, a lambda expression is used here, and it needs to be updateUI showError implemented in the current class, such as:

public void UpdateUI (data data) { TODO something } public void ShowError (Throwable t) { Show Error MSG }

Scenario Two: Multiple asynchronous requests for continuous invocation

This kind of scene is also very common, we do the use of the user Picture editor, generally there will be three requests need continuous calls:

1. Request the address of the Avatar upload
2. Upload Avatar
3. Update user Information

In the normal code, we need to step by step callback nested down, code lengthy too ugly, and not good maintenance, using Rxjava chain call processing code logic will be very clear

MyService MyService = retrofit.create (Myservice.class); Myservice.getuploadurl () . FlatMap (This::uploadimagetask) . FlatMap (This::updateuserinfo) . Subscribeon (Schedulers.io ()) . Observeon (Androidschedulers.mainthread ()) . Subscribe (This::updateui, this::showerror);

Here the just send a fixed value of 1, no practical meaning, just I think that more information
You can also create observable with Observable.create.

Scenario Three: Multiple asynchronous request merge processing

Sometimes in a project, we encounter the result of combining multiple requests, then update the UI, for example, we have a project to get notification data from multiple request addresses, and then in the app and then in chronological order to display the requirements, then we can use the Rxjava zip function to deal with

MyService MyService = retrofit.create (Myservice.class); Observable O1 = Myservice.getnotification1 (); Observable O2 = Myservice.getnotification2 (); Observable.zip (O1,o2, this::combinotification) . Subscribeon (Schedulers.io ()) . Observeon (Androidschedulers.mainthread ()) . Subscribe (This::updateui, this::showerror); Public list<notification> combinotification (list<notification> N1, list<notification> n2) { TODO Merge Notification list }

After the zip function waits for two requests to complete, call our merge method Combinotification, and then callback the method in subscribe after the merge process.

Scenario Four: Timed polling

Rxjava is also particularly suitable for the processing of timed polling tasks, a typical example is that the app submitted a task to the background asynchronous processing, assuming that the background processing takes about 1-2 minutes, we need to schedule to the background to query progress, and update to the UI, The traditional approach is to use the handler Postdelay method, with the Rxjava implementation of the words will be very concise

Subscription Subscription = observable.interval (2, Timeunit.seconds) . Map (this::getprogress) . Takeuntil (Progress-progress! = 100) . Subscribeon (Schedulers.newthread ()) . Observeon (Androidschedulers.mainthread ()) . Subscribe (New subscriber<long> () { @Override public void oncompleted () { TODO finished } @Override public void OnError (Throwable e) { } @Override public void OnNext (int progress) { TODO Update Progress } });

We check 2 seconds at a time until the progress is progress=100, and the polling is automatically terminated.

All of the above Rxjava methods are asynchronous time-consuming calls, and we need to cancel the Rxjava call in the activity's OnDestroy method, considering that the request has not been completed while the activity exits.

Best suited for four scenarios with Rxjava processing