public class CustomRequest extends JsonObjectRequest {
public CustomRequest(String url, JSONObject params,
Listener<JSONObject> listener, ErrorListener errorListener)
throws JSONException {
super(Method.POST,url, params, listener,
errorListener);
this.setShouldCache(Boolean.TRUE);
}
}
I was hoping that this piece of code would be enough for me to get implicit caching of responses. I'm not sure if it works or not, because i was under the assumption when a request is sent:
it would hit the cache first and send that to onresponse
then when the results come through from the remote server it would provide it to the onresponse
Update:
I figured how to manually retrieve the cache and reconstruct it into a JSONObject and send it through OnResponse function but that doesn't seem to efficient considering there is implicit caching. JsonObjectRequest class should return JSONObject as the cached entry instead of raw response data.
But i'm still interested to know if i'm making some mistake.
The ambiguity is solely due to the lack of documentation, so i apologize if i'm missing something quite obvious.
oleksandr_yefremov provides great codes that can help you when you dealing with cache strategy of Android Volley, especially when the REST API has improper "Cache-Control" headers or you just want more control on your own app cache strategy.
The key is
HttpHeaderParser.parseCacheHeaders(NetworkResponse response))
. If you want to have your own cache strategy. Replace it withparseIgnoreCacheHeaders(NetworkResponse response)
in corresponding class.If your class extends JsonObjectRequest, go to JsonObjectRequest and find
and replace
HttpHeaderParser.parseCacheHeaders(response)
withHttpHeaderParser.parseIgnoreCacheHeaders
I was able to force Volley to cache all responses by extending
StringRequest
and replacing request I want to forcibly cache withCachingStringRequest
.In overridden method
parseNetworkResponse
I removeCache-Control
headers. This way Volley is persisting the response in it's built-in cache.See this answer - Set expiration policy for cache using Google's Volley
This means Volley decides whether to cache response or not based only on headers "Cache-Control" and then "Expires", "maxAge".
What you could do is change this method
com.android.volley.toolbox.HttpHeaderParser.parseCacheHeaders(NetworkResponse response)
and ignore these headers, setentry.softTtl
andentry.ttl
fields to whatever value works for you and use your method in your request class. Here is an example:Use this method in your Request class like this:
+1 for oleksandr_yefremov and skyfishjy also, and offering here a concrete, reusable class suitable for json or other string-based APIs:
where the function parseIgnoreCacheHeaders() comes from the oleksandr_yefremov answer above. Use the CachingStringRequest class anywhere that the resulting json is ok to cache for 3 minutes (live) and 24 hours (expired but still available). A sample request:
and within the callback object's onResponse() function, parse the json. Set whatever caching limits you want--you could parameterize to add custom expiration per request.
For fun, try this in a simple app that downloads json and renders the downloaded info. Having filled the cache with the first successful download, watch the speedy rendering as you change orientations while cache is live (no download occurs given a live cache hit). Now kill the app, wait 3 minutes for that cache hit to expire (but not 24 hours for it to be removed from cache), enable airplane mode, and restart the app. The Volley error callback will occur, AND the "successful" onResponse() callback will occur from cached data, allowing your app to both render content and also know/warn that it came from expired cache.
One use of this kind of caching would be to obviate Loaders and other means of dealing with orientation change. If a request goes through a Volley singleton, and results are cached, refreshes that happen via orientation change are rendered quickly from cache, automatically by Volley, without the Loader.
Of course, this doesn't fit all requirements. YMMV