I want to refactor my app using Volley as HTTP library.
The current architecture includes using IntentService and AsyncTaskLoader for handling REST requests, and both of them start a new background thread.
Is it possibile to keep the current architecture and use Volley in conjunction with IntentService and AsyncTaskLoader?
I presume that to do this I should use Volley starting synchronous requests inside IntentService or AsyncTaskLoader, but looking at documentation and examples this doesn't look like the standard way to use Volley and maybe it would also decrease the performance benefits of the library itself.
Does introducing Volley mean getting rid of Services in our Android apps architecture?
Related
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 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.
What is the best way to implement periodic requests in Activity using robospice (ping, for example)?
Someone had the idea of using the retry mechanism of RoboSpice for that matter (see Robospice retry policy custom implementation).
I have successfully used and would suggest using Android Alarms (more details) with a Service that contains a SpiceManager.
They tell everywhere that we should use ASyncTaskLoaders because they are very good at not blocking the UI thread. And there is Volley to use now.
I guess we cannot use both of them because Volley does backgrounding on its own. What do you think? Which one is better?
These 2 technologies are different and hardly comparable. They have different purposes and can also work together. You could for exemple implement a Loader that uses Volley to load the data and inherits directly from Loader (not AsyncTaskLoader, because Volley handles the threading as well).
Main advantages of using Loaders:
Lifecycle is synchronized with the Activity/Fragment lifecycle automatically
Data and loading state is not lost on configuration change
The loader monitors changes and pushes new results automatically to the client fragment/activity.
Main advantages of using Volley:
High performance network stack
Automatic disk cache that respects the HTTP server policy
Powerful cancelation mechanism.
You can combine both to get both sets of advantages or you can use Volley without loaders with its simple API.
I've been using Volley for a month now and I have to say that I'm very satisfied. It really does help a lot not to have to worry about threading implementation details. So far both general networking and remote image loading have been working great.
It's not that there are no issues, but so far they have been minimal.
You better ask like this volley vs Async vs RxJava
You can use this RXJava for background thread, but for better efficiency in calling restful services Volley is highly recommended, also very less coding required compare to async task loaders !
Here is a writeup on current Android best practices. It discusses the use of Volley and RXJava: https://github.com/futurice/android-best-practices
You can combine both, to get both advantages.
In your activity (main thread) you call your API with Volley.
With a simple interface mechanism, you callback your main thread when the data is available.
Then you forceLoad() your AsyncTaskLoader with the fresh data from Volley.
In your AsyncTaskLoader you hydrate all your activity's container. They will be automatically loaded when data is available.
With this approch you combine Automatic disk cache of Volley, and Automatic synchronization of Loader.
I'm writing an android app that will connect to a REST/JSON webservice. Users will be retrieving information, uploading comments, downloading and uploading images etc.
I know that I shouldn't keep all this network communication in the Activity/UI thread, as it will cause ANRs. What I'm confused about is whether I should use an AsyncTask or a Service with "manual" threading to accomplish this;
With a Service, I'd simply have a public method for each method in the webservice's API. I'd then implement threading within each of these methods.
If I used an AsyncTask, I would create a helper class that defined AsyncTasks for each method in the webservice's API.
Which method is preferred? Interaction with the webservice will only happen while the user is in the Activity. Once they switch to another application, or exit the program, there is no need for communication with the webservice.
I recommend you go for the AsyncTask solution. It is an easy and straightforward way of running requests or any other background tasks of the UI-thread.
It's also easy to implement e.g. onProgressUpdate if you need to show a progress bar of some sort while running your requests.
I recommend IntentService, it is not much more complex to implement and is definitely more robust because it is not tied so closely on the ActivityLifecycle (in particular to onConfigurationChange())
This library provides an async wrapper to Apache httpclient available in Android.
http://loopj.com/android-async-http/