There are multiple ways to persist data locally for later consumption, but the most robust and convenient way on Android is the bundled SQLite database.
It is simple enough to use and will let us query data in the future based on the fields. An even simpler approach would be to store data just in plain files in the internal storage on the device, but that usually limits the possibilities to query and filter data in the future.
As SQLite doesn't have an interface to RxJava by default, we will have to rely on a specific library again. A perfect tool for the job is the StorIO library (https://github.com/pushtorefresh/storio) by Artem Zinnatullin. It is a great tool because it does not only provide a reactive interface to SQLite (as, for example, SQLBrite would) but gives the means to map domain classes to SQL calls with a fluent API as well.
SQLBrite (https://github.com/square/sqlbrite) is another possible option; however, it mostly manages just a system where notifications are sent when a specific table is updated and doesn't provide any means to easily map SQL-returned data to domain classes (ORM-like functionality).
There is a library call, SQLBrite DAO (https://github.com/sockeqwe/sqlbrite-dao); however, it isn't as well established as StorIO yet.
There are a lot of things to cover about StorIO. So, in this chapter, we will start with the data writing (persistence) aspect, and we will leave data reading for later chapters.
Finally, we will get to use the techniques that we've learned to integrate RxJava 1.0 and RxJava 2.0 libraries. In addition to that, we will make use of the things we have learned about Schedulers to offload write intensive tasks of the main thread so that the applications always stay responsive and snappy.