Caching Strategies for Android Apps

"There are only two hard things in computer science: cache invalidation and naming things." On Android, caching is also essential: users on slow networks, data caps and flaky connections notice every unnecessary request. The goal is a deliberate policy per data type, not caching everything.

Cache layers on Android

Core strategies

Stale-while-revalidate with Room

class ProfileRepository(
    private val api: ProfileApi,
    private val dao: ProfileDao,
    private val clock: Clock,
) {
    private val maxAge = Duration.ofMinutes(10)

    /** Emits cached profile immediately; refreshes in the background if stale. */
    fun observeProfile(userId: String): Flow<Profile?> = dao.observe(userId)
        .onStart { refreshIfStale(userId) }
        .map { it?.toDomain() }

    private suspend fun refreshIfStale(userId: String) {
        val cached = dao.get(userId)
        val stale = cached == null ||
            Duration.between(Instant.ofEpochMilli(cached.fetchedAt), clock.instant()) > maxAge
        if (stale) {
            runCatching { api.profile(userId) }
                .onSuccess { dao.upsert(it.toEntity(fetchedAt = clock.millis())) }
            // On failure, keep serving the cached copy; the UI can show "last updated".
        }
    }
}

Running the refresh in onStart delays the first emission until the refresh attempt finishes. To show the cache instantly, launch the refresh in a separate coroutine from the ViewModel instead.

HTTP caching with OkHttp

If your server sends proper Cache-Control and ETag headers, OkHttp's disk cache handles freshness and conditional requests (304 Not Modified) automatically:

val client = OkHttpClient.Builder()
    .cache(Cache(directory = File(context.cacheDir, "http_cache"), maxSize = 50L * 1024 * 1024))
    .build()

// Offline fallback: accept stale cached responses when there is no connectivity
class OfflineCacheInterceptor(private val isOnline: () -> Boolean) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        var request = chain.request()
        if (!isOnline()) {
            request = request.newBuilder()
                .cacheControl(CacheControl.Builder().onlyIfCached().maxStale(7, TimeUnit.DAYS).build())
                .build()
        }
        return chain.proceed(request)
    }
}

HTTP caching is great for GET responses you display as-is. When you need to query, combine or modify data locally, Room is the better cache.

In-memory caches

class ExchangeRateCache(maxEntries: Int = 50) {
    private val cache = LruCache<String, Pair<Double, Long>>(maxEntries)

    fun get(pair: String, maxAgeMs: Long, now: Long): Double? =
        cache.get(pair)?.takeIf { now - it.second < maxAgeMs }?.first

    fun put(pair: String, rate: Double, now: Long) { cache.put(pair, rate to now) }
}

Memory caches are fast but vanish with the process, so use them for hot, recomputable data. Respond to onTrimMemory by clearing large ones.

Images

Image libraries such as Coil and Glide provide memory and disk caching, downsampling and request deduplication. Don't build your own. Make sure image URLs change when content changes (versioned URLs), or use cache headers correctly.

Invalidation rules

• Time-based (TTL): simple and predictable. Choose per data type.
• Event-based: after a user edits their profile, update or invalidate the cache immediately.
• Server-driven: ETags and versions, or push messages that trigger a refresh.
• On logout: clear all user-specific caches, including the HTTP cache if it contains personal data.

Policy per data type: an example

Common mistakes

• Caching without any invalidation, so users see outdated data indefinitely.
• Different screens caching the same data separately, so they disagree.
• Personal data left in caches after logout.
• Unbounded caches that grow until storage or memory runs out.

Frequently asked questions

Conclusion

Effective caching is per data type: choose cache-first, network-first, stale-while-revalidate or network-only; pick the right layer (memory, Room, HTTP); and define clear invalidation, including on logout.

Next step: secure the credentials behind those requests with Secure Token Storage, or move on to quality with Unit Testing in Android with JUnit.