Caching

The Vizco Android SDK includes a built-in LRU (Least Recently Used) cache that stores widget responses to reduce API calls and improve performance.

How it works

When VizcoWidget fetches a widget by slug:

1. Cache check — The SDK first looks for a cached response for that slug.
2. TTL validation — If found, it checks whether the cached entry has expired (5-minute TTL).
3. Cache hit — If valid, the cached data is used immediately. No network request.
4. Cache miss — If not found or expired, the SDK makes an API call and caches the response.

Cache parameters

| Parameter | Value | |---|---| | Max entries | 20 | | TTL (Time-to-Live) | 5 minutes | | Eviction policy | LRU — least recently accessed entry is removed when full | | Thread safety | All operations are synchronized | | Scope | Global, shared across all VizcoWidget instances |

Cache key

The cache key is the widget slug. Each unique slug gets its own cache entry.

What's cached

The full WidgetApiResponse is cached, which includes:

• Widget metadata (slug, layout, config JSON, theme JSON)
• All associated asset data (URLs, dimensions, alt text)

Cache behavior

• First render — Always hits the network (cold cache).
• Subsequent renders — Served from cache if within the 5-minute TTL.
• Recomposition — Cache prevents redundant API calls when the composable recomposes.
• Multiple widgets — Each slug is cached independently. Up to 20 different widgets can be cached simultaneously.
• Cache full — When the 21st unique slug is fetched, the least recently accessed entry is evicted.

Clearing the cache

There is no public API to clear the cache. The cache is automatically managed:

• Expired entries are removed on the next access attempt.
• The LRU eviction policy handles memory limits.
• The cache is cleared when the app process is terminated.