RxJava and Observable on retrofit API call

Question

I am new to RxJava and want to understand the Observable. So, I am making one API call using retrofit and I am observing changes on the result so my questions are:

1. Does it make a continues API call to fetch the latest result from the server?
2. If yes then how frequently it is calling?
3. Is it call once then what's the use to observe the data?
4. Is it call once then we should use RxJava just to save a couple of lines in our code? We can simply use live data in this case.
5. Does it call once per lifecycle of the activity i.e(if activity gets killed and open again then it will fetch the new result?)

Here is a code snippet:

// fetching list of recipes
 mRecipeListViewModel.getRecipes().observe(this, new Observer<List<Recipe>>() {
            @Override
            public void onChanged(@Nullable List<Recipe> recipes) {
                // showing list of recipes
            }
        });

Answer 1

that's... a lot of questions.

1. The answer is "it depends". Show your service class (where you define the Retrofit call). Retrofit calls are usually Single instead of Observable because the API will return the result and end the call, so using observable makes no sense in that scenario (Single is... just ONE result or Error).

2. Once :)

3. You Observe a an Observable when you're expecting said observable to emit values (via the onNext) so you could Observe a list of things and get its items emitted one by one (for example). Or you could have an API that is an open socket emitting items every now and then; RXJava can help you subscribe to said emission and deal with each item (onNext()..)

4. I'd use LiveData if you have no use for RxJava; RX is nice, but it's huge and if all yopu're doing is just calling retrofit Single apis, I'd personally not bother with RX. RX's power comes from the multitude (and sometimes impossible to understand or use) operators (map, flatmap, switch, etc). and its super fluid API. It can do very powerful things and there's many adapters and extensions written for it. It can be misused to hell back and forth too. It's a moderately advanced tool for very good purposes that I wouldn't use today unless I have a specific use case that Rx Is really good at.

5. This has nothing to do with RX and more to do with your architecture. Are you calling retrofit in your lifecycle methods? (like onStart?) or are you calling it when the user interacts (press a button for example). In either case, RX has nothing to do with either and won't call anything unless told to.

More Info

• If you have an API that returns a list of "Things" like List<Thing>, you would think to make it Observable<Thing> getThings() in your service class. That will work. But that's not how it would work; the API sends an Array probably (that's why it's a list), so in reality, it must look like Observable<List<Thing>> getThings(), so then when you subscribe, it's gonna look like (this is pseudo code):

api.getThing()
    .blah()
    .blah()
    .subscribe(...)

A subscription will have 3 methods:

onError onNext and onComplete

If you look at the OnNext it would look like onNext(List<Thing> things) so, every emission from the Observable, is a LIST, instead of what you'd initially think: "onNext(Thing thing) so you can add things to the list.

That's not how it works. If your API returns a list of Things... you will probably want to declare it as:

Single<List<Thing>> because your subscription will essentially have 2 methods instead of 3:

onError and onSuccess(List<Thing> things) (apologies if the names aren't 100% accurate, I haven't touched RX in a couple of years). So you see, the API either returns the list or an error, there's no null, no next, no complete; once you get the list, your subscription will never emit again.

I hope this helps you a little bit more to grasp what it means to use RxJava (it's a commitment!)