Caching

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 URLCache has 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 URLCache interacting 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.

See more

public protocol EntityCache