A strategy for saving entities between runs of the app. Allows apps to:
- launch with the UI in a valid and populated (though possibly stale) state,
- recover from low memory situations with fewer reissued network requests, and
- work offline.
Siesta uses any HTTP request caching provided by the networking layer (e.g.
URLCache). Why another type of caching, then? Because
URLCachehas a subtle but significant mismatch with the use cases above:
- The purpose of HTTP caching is to prevent network requests, but what we need is a way to show old data while issuing new requests. This is the real deal-killer.
Additionally, but less crucially:
- HTTP caching is complex, and was designed around a set of
goals relating to static assets and shared proxy caches — goals that look very different from reinflating Siesta
resources’ in-memory state. It’s difficult to guarantee that
URLCacheinteracting with the HTTP spec will exhibit the behavior we want; the logic involved is far more tangled and brittle than implementing a separate cache.
- Precisely because of the complexity of these rules, APIs frequently disable all caching via headers.
- HTTP caching does not preserve Siesta’s timestamps, which thwarts the staleness logic.
- HTTP caching stores raw responses; storing parsed responses offers the opportunity for faster app launch.
Siesta currently does not include any implementations of
EntityCache, but a future version will.
EntityCachemethods on a GCD background queue, so your implementation must be thread-safe.
public protocol EntityCache