what is the difference between retrofit synchronous and asynchronous request? which one is better and why?

Question

I have really searched for this every where, I can make both synchronous and asynchronous data requests, but I can't actually understand which is asynchronous with what? and what is sync with what?

Solution 1

when you asynchronous, it means not in the foreground(it does not block the users interface while it accomplishes the given task), on other hand synchronous means in the foreground while your application execute things in the same thread the UI consuming.

In your case(making REST requests via retrofit or any other REST api) you must not make that in that foreground and you have to make in a background thread.

In the case of retrofit you have the following methods to make the request:

call.execute() // works in the foreground.
call.enqueue() // works in the background.

So you have a choice of two: either you make the call.enqueue directly or you can user call.execute but wrapped with a service(I mean you have to handle the background work your self).

Solution 2

call.execute() runs the request on the current thread.

call.enqueue(callback) runs the request on a background thread, and runs the callback on the current thread.

You generally don't want to run call.execute() on the main thread because it'll crash, but you also don't want to run call.enqueue() on a background thread.

Solution 3

Synchronous requests are declared by defining a return type.Synchronous methods are executed on the main thread. That means the UI blocks during request execution and no interaction is possible for this period. Using the .execute() method on a call object will perform the synchronous request. The deserialized response body is available via the .body() method on the response object.

Asynchronous requests don’t have a return type. Instead, the defined method requires a typed callback as last method parameter.Using asynchronous requests forces you to implement a Callback with its two callback methods: success and failure. When calling the asynchronous getTasks() method from a service class, you have to implement a new Callback and define what should be done once the request finishes.

Comments

[Mohammad Elsayed]

this is very helpful, I will read it and ask if there is something I can't grasp

[Mohammad Elsayed]

I know what is sync and what is async but in the case of data requesting from web service what fetching this data is sync with(when talking about sync) and what is async (when talking about async data req)

[Mohammad Elsayed]

so should I prevent using synchronous request

[Mohammad Elsayed]

or if I make the call in service can I then share the thread the service is using.

[EpicPandaForce]

call.execute() makes sense on a threadpool / executor / IntentService.

[Ritt]

@EpicPandaForce explained it well. Your question is not clear.

[Mohammad Elsayed]

thanks, that is very helpful, sorry other question: u mean execute in external thread(IntentService for ex) is the same as using enqueue in the main thread??

[Mohammad Elsayed]

many thanks you really helped me so much, in the course I am taking right now, the instructor used the sync with intent service(I was thinking that the normal is to use intentService in all cases) but when he came to the async part he made it in the main activity(lynda course, so I could not ask there sorry) you really helped me

[EpicPandaForce]

Yeah, he used enqueue in the MainActivity because he was on the main thread, and not on a background thread.

[IgorGanapolsky]

execute is synchronous. It has nothing to do with UI thread: square.github.io/retrofit/2.x/retrofit/retrofit2/Call.html

[IgorGanapolsky]

How does this explain enqueue?

[Sudhanshu Gaur]

@EpicPandaForce, Correction - call.enqueue runs the callback always on the UI thread, not on the current thread

[EpicPandaForce]

True, they added support for detecting that if it's on Android, then it should call the enqueue callback on UI thread