High-Level Repository Strategies

There are many, many ways to implement a repository. How one app approaches it may differ significantly from how another app approaches it, and neither approach is necessarily wrong (or right).

That being said, there are a few commonalities among the approaches that will tend to arise, based on where the data is being stored.

Pure Network

Occasionally, you will have an app where the repository always makes network requests whenever the UI needs data. This is fairly uncommon, as it implies that caching is not an option, and usually there is some amount of caching that can be applied to the problem.

Network + Network API Caching

Sometimes, the caching can be provided by whatever API you are using to access that network:

• OkHttp offers integrated caching, assuming that the Web server uses appropriate cache-control headers
• Apollo-Android — a library for making GraphQL requests — offers its own caching, in addition to possibly using caching at the OkHttp layer
• Picasso, Glide, and other image-loading libraries often have their own caches
• And so on

In these cases, other than configuring the cache (e.g., specifying the directory to use for a disk cache), there is little cache-related code in the repository itself.

Network + External Caching

Sometimes, you may want more sophisticated caching than might be offered by the API that you are using to access the network, Or, perhaps the caching required by the app does not match what the libraries offer (e.g., the Web server does not use cache-control headers, as the caching is handled by client-side rules rather than server-side configuration). In those cases, you need to handle caching “above” the software layer represented by those networking APIs.

The Store library offers an “all-in-one” solution for this, though the learning curve is steep.

Network + First-Class Persistence

Sometimes — particularly for an app that offers rich offline functionality — you need to put the local storage first in your mind, with network functionality serving in a “sync” role.

While a robust caching system can help with “offline-first” apps, you are limited in how you can access that cached data to whatever APIs are offered by the caches. For caches integrated into the networking APIs, that means that all you can do is make a network request and deal with the failures when the device is offline and the data is not cached. Often you have no way of examining the cache to try to determine what you can do locally.

Also, most caching systems are designed for read operations, where the “system of record” is the server and the cache is a replica of data retrieved from that server. Many caches offer little to no support for buffering write operations while the device is offline. And caches, by definition, are never a “system of record”, and sometimes the device is the primary storage location, with the network serving in the role as a backup.

For these, your repository will be built around a rich local storage API: SQLite, an object database, etc. The repository will be responsible for the network I/O as well, though that network I/O may be a “side” piece of functionality, not used in the direct fulfillment of requests from the UI.

Persistence-Only

Sometimes, there is no server. In those cases, the repository wraps around your local storage API of choice, with the abstraction helping to isolate you from your choice of local storage API, in case you change your mind later.