I wanted to (and still am) write a blog post about caching with Store, but I'm suspecting it will be a bit before I finish it... So here's a small thread about Store basics!

"What is Store?"

Store is a library for caching in JVM projects. It was originally created at the New York Times and is now hosted by @friendlyMikhail and some other awesome folks. In modern apps/software, you want data to always be available - and that's tough to get right.

Ever had a spotty internet connection and that post you started reading at home just didn't load? Or you were super close to hitting your data limit and had to watch out what you spend data on?

Making sure data is always available is one of the core principles for great apps.

If you've ever built a caching mechanism, you'll know that there are a lot of challenges in designing it. You need to make sure everything is well-tested, edge-case scenarios are considered and that you are not making too many (or too few) network calls or disk writes.

That's not an exclusive list obviously, but this is just to say: Caching is hard. Not impossible to build or anything, but it can take a good amount of time to get right. So having a library that thinks about these things is very nice! https://twitter.com/secretGeek/status/7269997868

Store (4) is really awesome because it is based on Kotlin Flow and Coroutines which make life around concurrency and async a lot easier. It's written in Kotlin, too!

It also offers APIs to use it with RxJava 2/3, so it doesn't limit you to specific libraries.

Ok, enough of the prelude, let's talk Store!

Looking at an example similar to one in Store's Readme, there are a few core concepts we need to talk about:

- Keys
- Fetchers
- Source of Truth

A Store in its most basic form includes a Fetcher. Fetchers are responsible for fetching data from a remote source, aka an API. A Fetcher is essentially a function that gets invoked with the Key and returns the desired data from the network.

What are Keys in Store?

A key is the parameter that Store uses for your request.

For example, if you were working on a newspaper app and wanted to cache articles, your key would be the article id.

Basically, it is what you use to identify data.

Store also uses the key to read from and write to the Source of Truth. The SoT is the persistence that backs Store. It is used to store data locally and then read it.
A SoT is optional for Store, but you need it to persist data on the disk.

So we have our Fetcher and our Source of Truth, let's build the Store and use it!

What I really like about Store is that it's flexible but still opinionated - it lets you do a lot of things, but also makes making mistakes harder.
The API surface is really great too! While it might take a bit for it to click, it is an amazing abstraction for a complex topic.

We have been using Store in prod since Alpha 04 and didn't have any issues with it. It has recently graduated to Stable, so you don't have any excuses not to use it anymore :) https://github.com/dropbox/Store 

A lot of samples in this thread were inspired by the Readme, so make sure to check that out! I only covered some parts of Store and there is a lot more to it, so I'd recommend exploring it on your own too.

@friendlyMikhail also wrote a great post! https://dropbox.tech/mobile/store-grand-re-opening-loading-android-data-with-coroutines

Some questions I had been asked: https://twitter.com/i549/status/1333743744798003201

"Usually there are multiple methods in a repository, do we have to create a store for each one of them?"

Store is very similar to the repository pattern. You might be able to replace whole repositories with it!

You don't need multiple Stores for each method you might have in...

... a repository, but rather one per data model/type. So if you had a repository that offered methods for getting/storing "Article"s as well as methods for getting/storing "Author"s, it would make sense to have a Store for each of the models.

"How can I manage Stores w/o Dependency Injection?"

It makes sense to use DI for this, similar to how you would probably use it for repositories.
In any case, you can build Stores without a DI solution! For example, you could collect them in an object.

The Store sample app also has a nice example for providing a Dependency Graph manually: https://github.com/dropbox/Store/blob/main/app/src/main/java/com/dropbox/android/sample/Graph.kt

That marks the end of what I have prepared for this thread! Let me know if you have any more questions and if I made any mistakes!