Reactive store — by Dropbox and flow

I want to share with you what is, in my opinion, a perfect, small and concise use case for reactive repository with the new Kotlin flow. Before we dive into the problem at hand, we first have to have a short introduction to our building blocks: flow and reactive store.

Flow

Hopefully, by now all of us have at least heard of flow, but just in case, here is a definition: flow is a library that represents a cold stream of data which is asynchronously computed. We can do lots of different manipulations on the values, so it is quite easy to map and filter data in any layer of your app. See example below:

Reactive store by Dropbox

This small library is an awesome addition to the Android ecosystem by the guys in Dropbox. Basically, what it does is manage data requests for you, caches the data and returns you the result as flow. I will explain it when we implement it in our little example.

Store docs are awesome and I do recommend that you read them. Just follow this link.

What are we building?

The idea is to build some sort of a message inbox that can be opened with multiple screens, based on the type of message that you need. Messages can also be deleted on any screen you want, which can lead to a lot of boilerplate code needed to handle all the callbacks.

As you can see in this gif, when the app is opened, there is a network call for messages with a number of messages and potential categories shown. After opening any of the categories, you can read and delete any message. And that is about it, the simplest case to showcase this.

Show me the code

First let’s see the repository:

To use the Store you need to define a fetcher and use the Store for any dataSource operation. Everything else is handled by the library.

On the app start streamQuestions is called and will stay active all the time.

Now for the last and the most important part, read/delete screen. Depending on what category is picked, we have an event channel to inform our flow of changes (only the latest info) and we just have to filter a type that we need. Maybe you have noticed, but we are calling streamQuestions() again, which is an unnecessary network call usually, but in this case, the Store is smart enough to give us cached data from the memory.

Finally, we have our delete operation. In many cases this can add a lot of code and complexity because of data sync issues. Not here!

ViewModel calls delete interaction, which then calls a repository operation. After dataSource (network) is called to delete a message and success is returned (ignoring error for simplicity), the final and crucial step is to inform the store that the fresh data needs to be fetched.

And that’s it! Fresh data are fetched successfully and dispatched to all the active flow channels. Our data are up to date and correctly updated on all screens. Happy times.

Conclusion

Obviously, this is far from a real world use case, but I think this bare bones example best illustrates the power of reactive programming in a very simple fashion.

Thank you for reading, I hope you found this helpful. Please comment and share if you liked it.

Code can be found on this link.

Thanks to Antonija Butković for the design!