I have asked question recently on stackoverflow regarding my slow network calls using Retrofit and RxJava
I have made some changes of scheduler.io in it and removed main thread from all the execution. But still the result is not that much satisfying. I have digged in the code of OkHttp and Retrofit. Below are my findings:
Retrofit uses scheduler.io which will execute all the requests in the threadpool. Previously it was creating new threads. Does changing it to scheduler.io from newthread make any difference?
Now OkHttp has limit of max requests per host of 5 in the code. So does that make any difference?
All the calls are happening in Dispatcher using enqueue. Do we need to set some configuration to Retrofit and OkHttp for that?
Any suggestions to increase the performance of webservice call will be appreciated?
Related
I am creating an app which is like queue displaying. For my scenario, the queue data is always updating. Is there any method that enable I efficiently calling API to get latest data, beside using Handler. Using Handler, might can solve my issue but it's not a good practise because keep calling API for every 5 seconds, might causing server overload/ memory issue? Btw, the API is restful API.
You can implement RxJava with Retrofit such that the Retrofit Service is called every x seconds in your Android Application.
RxJava - is a Java VM implementation of ReactiveX a library for
composing asynchronous and event-based programs by using observable
sequences
In order to create a Retrofit service that runs after certain time intervals, we can use the following :
Handlers (are used to pass data from the background thread to the UI thread)
RxJava
Using RxJava we can do much more than that and very easily as well, using RxJava operators.
We can use the interval operator to call a certain method ( retrofit network call in this case) after every given period.
Observable.interval operator is used to emit values after certain intervals. It looks like this:
Observable.interval(1000, 5000,
TimeUnit.MILLISECONDS);
1000 is the initial delay before the emission starts and repeats every 5 seconds.
We can subscribe our observers which would call the Retrofit method after every 5 seconds.
Calling Retrofit service after certain intervals is fairly common in applications that provide live updates, such as Cricket Score application, etc.
For more details,
Basics of RxJava and Retrofit together
Android Retrofit call every x seconds
I understand you need to update the data when there is the latest data on the server.
I think you need to apply Socket.io for server and client. When the server has new data, it will notify the client through the socket.
Method 1: When the server sends the event to the client, it will send the latest data.
Method 2: When the client receives the event, it will call the API to get the latest data.
This is advisable because when the number of users is very large, it will save resources.
I used to have a problem like yours and found it a bad thing to have clients calling APIs all the time.
Another way is that when the user clicks or manipulates you will call the API to update the data, but this is not recommended
I am new to Android development and it's my first time on API. I am getting a message log that application main thread may working too much . I am using Retrofit with enqueue callback, a java class Model.
I just want to take advice from you guys that should I use AsyncTask to make application working smooth? or Retrofit is already doing the work like that of AsyncTask? or is there a need or not of AsyncTask in my application?.
I have been searching this for few days but I am confused
Note
I am using the Picasso library for downloading the image and an
image would be 100 kb in size.
Also as the application is still in its build there is no too much data on the server.
Purpose
I just want the application to work smooth and good on all devices.
AsyncTask is deprecated
Here.
Retrofit has its own async calls mechanism which is far more appropriate
Here.
Also, you can use rxJava with retrofit which will help you even more in creating async calls.
I recently switched to Retrofit, and very new to the retrofit concepts. I found out about it Here and found it very interesting and made my work more easier and simpler.
As per the rules any HTTP request must be in a AsyncTask extended class,
from the above tutorial I found that the retrofit call are made in the main UI thread itself.
I am finding it difficult to implementing the same tutorial in a AsyncTask class. How can I do this?
please help me as for every retrofit call my app is betting slower and I get skip frames 1076.
There is 2 methods in retrofit2, First is execute that will call the request synchronously. The second is enqueue method that will make the request asynchronously.
As per the rules any HTTP request must be in a AsyncTask extended class
You misunderstand - A network request cannot be run on the UI thread. An AsyncTask just happens to be one way to do that. Retrofit/OkHttp is another, and Volley, and AsyncHttpClient are others.
I am finding it difficult to implementing the same tutorial in a AsyncTask class
Probably that is because that tutorial is specifically for Retrofit?
How can I do this?
A high-level overview of what Retrofit gives you that you would have to toss together in an AsyncTask
Building an HTTP Request
Adding HTTP Headers (if needed)
Reading an InputSteam to a String
String to JSON conversion
JSON to Java Object Conversion
Callbacks to the main thread
Now, that all seems complex if you don't really understand that stuff. That being said, you should just stick to Retrofit's enqueue
I am using the Retrofit 2 library for an android REST client. Retrofit itself supports synchronous and asynchronous request (cf. here), the reason for the latter being not to block a thread and thus not to get interrupted by android.
In practice, is it better to use synchronous calls in a native AsyncTask or asynchronous calls directly from Retrofit?
If one is preferable over the other, what are the technical reasons?
One of the main reasons to use any of the popular REST clients (retrofit, volley, etc) is that they reduce the amount of details you have manage at the application layer. One of those details is making sure your network requests happen off the main thread. Why would one use an AsyncTask when a library they are already using for other features provides the same functionality with less ceremony? The only reason I can think of is -- you don't think the library's threading is very good. That concern does not apply to retrofit 2, it uses OkHttp to dispatch async calls. OkHttp has been around awhile and used extensively, it manages its own thread pool to execute async requests, and is solid.
So, the upside to using retrofit async is cleaner code, and no downside I know of vs AsyncTask with retrofit sync calls. The only time I use the sync calls is when my code is already executing in a background thread for another reason. I never create a separate thread or asynctask just for the network call and use enqueue instead.
OKHttp supports both synchronous and asynchronous api.
If I want to issue an async request, I can:
Use a AsyncTask, and issue OKhttp synchronous api.
Issue a OKhttp asynchronous api.
What is the difference between these 2 options? And which one is better?
Quite a lot differs!
Using AsyncTask for HTTP requests is pretty much one of the worst things you can do on Android. It's fraught with problems and gotchas that are best unconditionally avoided. For example, you cannot cancel a request during execution. The patterns of using AsyncTask also commonly leak a reference to an Activity, a cardinal sin of Android development.
OkHttp's async is vastly superior for many reasons:
It supports native canceling. If a request is in-flight, the reference to the Callback is freed and will never be called. Additionally, if the request has not started yet it never will be executed. If you are using HTTP/2 or SPDY we can actually cancel mid-request saving bandwidth and power.
It supports tagging multiple requests and canceling them all with a single method call. This means every request you make in, say, an Activity can be tagged with the Activity instance. Then in onPause or onStop you can cancel all requests tagged with the Activity instance.
If you are using HTTP/2 or SPDY requests and responses are multiplexed over a single connection to the remote server and by using the asynchronous Call mechanism this is much more efficient than the blocking version.
So if you can, use Call.enqueue!
Nothing much. OKHttp async is OKHttp API driven. So as long as you bundle the jars together for all platforms you should be good. AsyncTask is Android way of doing things.
However since Honeycomb Async task runs the tasks sequentially and not in parallel. This means that though the execute method of AsyncTask spans a new thread which runs your job away from the UI thread but all the tasks sent to one AsyncTask run in the same spanned thread.
So for 3 tasks submitted u don't get 3 threads they all run sequentially on a single spanned thread. With OKHttp you can achieve true parallelism using callbacks and async GET and POST.
Though you can do true parallelism in AsyncTask methods as well (check the overloaded execute methods in AsyncTask) but default Android behavior is not to do so.