Configure OkHttp Cache for Retrofit and force network requests
This tests HTTP caching semantics in mobile networking. A strong answer covers Cache setup with a 50 MiB directory, server Cache-Control driving expiration, and CacheControl.FORCE_NETWORK to bypass.
What's really being asked
This question probes whether you treat HTTP caching as a cooperative protocol between client and server rather than a client-side switch. Interviewers want to see that you understand OkHttp owns the cache, Retrofit merely delegates to it, and that cache behavior is ultimately governed by response headers and OkHttp's RFC-compliant policy.
The full answer
First, constructing a Cache instance with a dedicated directory and a maxSize such as 50 MiB, then attaching it to an OkHttpClient Builder. Second, passing that OkHttpClient into your Retrofit Builder so all requests share the same client and cache. Third, explaining that server-sent Cache-Control headers like max-age, no-store, must-revalidate, and ETag or Last-Modified drive whether OkHttp stores a response, serves it without validation, or performs a conditional GET. Fourth, demonstrating how to force a network request by adding a CacheControl.FORCE_NETWORK header to the Request, which makes OkHttp skip the cache lookup entirely. Fifth, noting that the cache directory must be exclusively owned by one OkHttpClient instance and should persist across app restarts.
The mistakes people make
Claiming Retrofit has a built-in cache abstraction separate from OkHttp. Stating that adding the Cache object alone guarantees all responses are cached regardless of headers. Forgetting that responses must be fully consumed, closed, or read to completion before OkHttp writes them to disk; cancelled or stalled streams are discarded. Suggesting you invalidate the cache by creating a brand new OkHttpClient instead of using cache evictAll or the urls iterator. Ignoring that a 304 Not Modified response merges the cached body with updated network headers.
What usually comes next
How would you implement a pull-to-refresh force refresh without disabling the cache permanently? What happens when a response contains both a Cache-Control max-age and an Expires header? How would you handle cache size limits when users are offline for extended periods? Can you safely delete the cache directory manually, and what are the risks?
A concrete example
Suppose your Retrofit service fetches a user profile. You build an OkHttpClient with Cache(File(context.cacheDir, "http_cache"), 50L 1024L 1024L). The server returns Cache-Control: max-age=3600 with an ETag. The first request hits the network. Within the hour, Retrofit serves the cached response instantly with a CacheHit event. After the hour, OkHttp sends a conditional request with If-None-Match. If the profile has not changed, the server returns 304 Not Modified, OkHttp returns the cached body, and you see CacheConditionalHit followed by CacheHit. To force an update after the user pulls to refresh, you build a new request with .cacheControl(CacheControl.FORCE_NETWORK) and remove the specific URL from the cache urls iterator before reissuing the call.
Interview question
After a cached response's max-age expires and the resource is unchanged, what does OkHttp do on the next request?
- a.Sends a conditional GET with If-None-Match and serves the cached body on a 304Correct
- b.Returns a 304 with an empty body since 304 responses cannot carry a payload
- c.Returns the stale response immediately without contacting the server
- d.Discards the entry and downloads the full response again
Why? this is the answer
OkHttp sends a conditional GET using the stored ETag after max-age expires, and on a 304 it transparently serves the cached body with updated headers. Option B is tempting because 304 responses themselves have no payload, but OkHttp's cache layer handles merging the cached body so the caller still receives the full response.
Just read this? Test yourself on what you have been reading.
Read the original → square.github.io
- #android
- #okhttp
- #retrofit
- #http-caching
- #networking
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles