Is Retrofit .execute method is already background task or should I call this method in AsyncTask in retrofit official documentation it mentions that callbacks executed in mainThread, but its not clear if execute method is background task.
Retrofit documentation:
SYNCHRONOUS VS. ASYNCHRONOUS
Call instances can be executed either synchronously or asynchronously. Each instance can only be used once, but calling clone() will create a new instance that can be used.
On Android, callbacks will be executed on the main thread. On the JVM,
callbacks will happen on the same thread that executed the HTTP
request.
call.execute() //not a background task, works in the foreground(synchronous).
call.enqueue() //This is a background task(asynchronous).
call.execute() runs the request on the current thread.
call.enqueue() runs the request on a background thread, and runs the callback on the current thread.
This link has a nice explanation on what you are asking for. In short Asynchronous requests will have callbacks like onResponse and onFailure. If you are making request to API, you would certainly want to go with asynchronous.
Related
I know that execute() is a synchronous function which means Until you are able to use it should execute it in other threads.
But I want to understand why would I use execute function even though enqueue function exists that does this work (execute on other thread) itself.
what are cases that should use execute function in it?
Sometimes, you are already on a background thread, supplied by something else:
JobIntentService
WorkManager
Kotlin coroutines
RxJava
Etc.
In those cases, you may not need OkHttp or Retrofit to use yet another background thread and can use execute() for simpler code.
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?
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.
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).
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.
Retrofit is a type-safe HTTP client for Android and Java. And I would highly recommend using this over any other library.
Do you understand what is sync and async call, or what is blocking and non-blocking call?
To answer your question, any api call you do or any heavy or time-consuming task you do on Android, it should be non-blocking (async) as it should not block the Main or UI thread in Android.
Please read this article for more understanding
https://developer.android.com/guide/components/processes-and-threads.html
I would like to run asynchronous server call using AsyncTaskLoader. Method loadInBackground() should return the result synchronously. I am returning null and I call deliverResult() in callback which is executed on manually created HandlerThread. This implementation is sending to UI null at first, then (when async server operation is done) real data. I'm not sure this is good solution.
How to implement custom AsyncTaskLoader properly, where I want to load data by asynchronous server calls (thus using callbacks)?
Thanks for any help
use join() on manually created HandlerThread (without code it's hard to give a working example)
The Retrofit Documentation states the following:
For desktop applications callbacks will happen on the same thread that executed the HTTP request.
I've attempted to understand this by studying the Retrofit source (particularly RestAdapter.java) and looking at a number of other similar SO questions (such as this) but I am still puzzled.
If I have a background thread which calls void getUserPhoto(#Path("id") int id, Callback<Photo> cb) (for example), exactly how does this library execute a callback on that thread?
If you pass same executor to the RestAdapter, let's say:
ExecutorService backgroundExecutor = Executors.newCachedThreadPool();
restAdapterBuilder.setExecutors(backgroundExecutor, backgroundExecutor);
Then the callback Runnable will be executed on this background executor, which means you will receive callback in same thread, otherwise the thread will be shutdown or reused and the callback will happen on thread different from the one that executed the http request.
When Retrofit checks if you are running it on desktop app or Android App, it checks if there is a present package from android sdk, and then obtains the executor(s) for http request and callbacks will happen, i.e if you are running on Android, it will run the callback Runnable on main thread. If you are running on non-Android it will get the synchronous executor (the same that is used for http request) unless you don't pass something else. These are the default Platform settings that are built, if you don't do it yourself.
I'm new to Android and Java and I'm trying to use loopj's Android Async Http Client. I don't understand all the technical nuances of the introduction the library states: "All requests are made outside of your app’s main UI thread, but any callback logic will be executed on the same thread as the callback was created".
For instance, why is having the callback logic executing on the same thread as it was created important/useful? What is that opposed to? What other alternative threads could the callback logic can be executed?
Thanks in advance.
For instance, why is having the callback logic executing on the same
thread as it was created
The main reason it the UI. Only the original thread that created a view hierarchy can touch its views. This means that your application will crash if a different thread tries to update the UI
What other alternative threads could the callback logic can be
executed?
this is strongly implementation-dependent. For instance the callback could be executed on the same thread which performed the async call
I can see that execution happening on the same Thread good for at least one situation. The UI can't be modified from outside the UI Thread, so in the case you make a connection and get some data that you want to display in a EditText it is helpful to have the callback executing on the same UI Thread (Assuming you created the callback in such Thread).