I am using Teller in an app I am working on at the moment. During development, I came up with this scenario:

• The app keeps track of a history of activity for you. This history of activity is obtained by a GET http call to the network API. That makes a great use of Teller, OnlineRepository.
• However, activity is also created locally on the device in the local database. When activity rows are added locally to the local database, I should show this local cache to the user. However, what if: the app has never had a successful api sync before? Then, we will never show the local cache that exists.

Is this use case worth solving?

The way to solve this problem right now is to:

• Create a separate observe() function where you perform a local database query where you can show the cache to the UI.
• Call refresh(force = false) in the same place that you would have called observe() which will perform a refresh if needed, but not if not needed.
• Have another call to the OnlineRepository.observe() where you can retrieve the last fetched property.

Is this use case worth solving? I believe so. Why? Because it seems like a use case that is understandable and may happen to more apps. Also the fact that it could be considered a bug in a way because if a refresh call has never been successful before, we will never load the local cache. That is not good!

The current way to solve this problem is not horrible. But, it's also easy to forget about. Having a better solution where the developer can remember to enable some functionality would be better to prevent bugs.

Ideas to solve this problem:

1. Create another Repository abstract class that has the behavior of, "Be an onlinerepository, but if there is an existing cache, show that."

Pros:

• Easy for developer. Just change subclass of repository and done.
• Could customize the with a separate CacheState instance that combines properties from local and online cache state.

Cons:

• Yet, another repository which means yet another one to learn about.
• There is so much similarity between this repo and the other 2 that I wonder if there is another way to build this instead. Share more code.
• If this use case is rare, having another repository subclass added to lib sounds like a lot of work when it's a rare use case.

2. Modify OnlineRepository to allow the loading of a local cache even before first fetch is done.

Pros:

• Quick, easy, optional functionality that gets hidden by the main use cases of Teller.
• Because this is so similar to OnlineRepository, by using it's abstract functions already, the dev doesn't need to change anything.

Cons:

• How do we handle OnlineCacheState?