I'm using Volley as network library on Android. I ran into 'limited functionality' problems when using ImageLoader. It seems to be quite useful class with caching and stuff, so I want to continue using it. However, it doesn't give any access to the Request objects it creates. As a result, I'm not able to do some stuff that I can do in other cases (like setting a tag on the request for cancelling it from queue).
My current problem is - how can I set a retry policy on requests made using ImageLoader?
I think there is no way to set retry policy for ImageLoader. But you have access to all requests through volley singleton (if you use one). Try to change retry policy in addToRequestQueue method. If you need different retry specification for images and other requests - you can simply create two request queues (bad practice).
Related
What i want to do is at a specific time bypass cache, make an http request and then update the new result back to cache for the next time I need it. Is there any way to do this with retrofit + okhttp in android??
You can force a network request by using CacheControl.FORCE_NETWORK for the request. You could either do it when creating the request, or in an interceptor.
Another way would be to use Cache.evictAll() to clear the cache completely. Any subsequent requests will be put in the cache.
You can use a Timer to schedule and trigger the eviction process.
I have to send four different request in an api at the same time. Do i need to make AsyncTask background thread for each request or all request could be done through a single AsyncTask. Can somebody please help.
This is a concurrency issue. There is literally dozens of ways to do this in Android. I've written almost every single one for courses that cover this material... and even then it isn't 'simple'.
I'd personally make use of HaMeR (Handler, Messages, Runnable) framework of Android. Create 4 runnables and have them post their results to a Handler.
However... That isn't the easiest to implement. and would require you to understand how to safely create your own custom handler (making use of WeakReference properly, etc.)
Therefore, I'd recommend running the asyncTask(s) on the executorService
myTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR); The default thread pool executor should start with 4 threads (I believe off-hand without looking it up).
I am assuming you are using HttpURLConnections. Unfortunately each of those connections, as specified in the documentation, is capable of handling only a single request.
However, you can (and possibly should) still perform all your requests in a single AsyncTask. Each AsyncTask will require the creation of a new thread which takes lots of time and resources. So don't listen to anyone who tells you to create a new task for each request.
You also have the option of exploiting HTTP persistence. If you add the header Connection: Keep-Alive to your request via connection.setRequestProperty("Connection", "Keep-Alive");, you will be able to send multiple requests over the same connection and save a lot of time and resources.
It's a little complicated in Java, because of the one-request-per-httpurlconnection rule, but it can be done. First, when you are done with your first request's HttpURLConnection do not close that connection. Then, to create the next connection, call url.openConnection() on the same URL object that you used to create your first HttpURLConnection. The JVM will know to reuse that connection if possible to save bandwidth.
You also have the option of using HTTP/2.0 multiplexing, which allows you to send multiple requests literally at the same time. Unfortunately I am not yet well versed enough in HTTP/2.0 to tell you exactly how to make use of this, but the multiplexing feature was included to solve exactly this problem.
I have 2 class of AsyncTask for handling request one for sync and other class for handling other request but when I send sync request and move to other page and request response for second request will get after sync request responds. How I solution this?
Hope any one help me
Basically you can use Volley
Volley offers the following benefits:
Automatic scheduling of network requests.
Multiple concurrent network connections.
Transparent disk and memory response caching with standard HTTP
cache coherence.
Support for request prioritization.
Cancellation request API. You can cancel a single request, or you
can set blocks or scopes of requests to cancel.
Ease of customization, for example, for retry and backoff.
Strong ordering that makes it easy to correctly populate your UI
with data fetched asynchronously from the network.
Debugging and tracing tools.
You can easily find a tutorial for it and
It much faster then AsyncTask .
For reference check this
You can make asyntask run parallel execution by replacing execute() with executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR).
I have an android app using Robospice with Jackson + Spring to perform REST requests. This is working, except that Robospice doesn't seem to be caching the responses. I've also made sure that the cache key is consistent between requests.
I'm setting up the SpiceManager like this:
private SpiceManager mRestManager = new SpiceManager(JacksonSpringAndroidSpiceService.class);
Then, I'm executing the request like this:
mRestManager.execute(customSpiceRequest, requestCacheKey,
DurationInMillis.ALWAYS, new CustomRequestListener())
I don't know if it's relevant, but my customSpiceRequest extends SpringAndroidSpiceRequest. I've made certain that requestCacheKey is identical between requests too.
Is there something else I need to do to enable caching between requests?
Indeed, RoboSpice is doing what you are asking for : you pass
DurationInMillis.ALWAYS as a parameter to execute.
This means that the data
in cache will always be considered expired. Thus, the SpiceRequest will
always perform a network call. You should just use a different
cacheDuration value when invoking execute.
Since then, Javadoc has been enhanced :
cacheExpiryDuration : duration in millisecond after which the content of the cache will be considered to be expired. For instance DurationInMillis.ALWAYS means that data in cache will always be considered expired, thus requests will always perform their network operations to get new data. DurationInMillis.NEVER means data will never be considered as expired, requests will never perform network operations to refresh data but will always return cached data. (see {#link DurationInMillis}).*
In an Android app, I am using one static instance of org.apache.http.impl.client.DefaultHttpClient and sharing that instance in all activities and services of the app, so that this client may be used to log in once to a remote server and all subsequent user requests to that remote server will remain authenticated.
Every activity or Service that makes a GET or POST to this remote server calls the same method : MyUtilityClass.gettHttpClient()
Do I need to worry about synchronization of this httpclient? If so, what is the best way to handle this?
Use ThreadSafeConnectionManager, but be sure to call httpResponse.getEntity().consumeContent() after processing the response in order to ensure that connections are released back to the pool.
Use a ThreadSafeConnectionManager, then you do not need to synchronize.
You can use AndroidHttpClient1. It is properly configured and already uses ThreadSafeClientConnManager