I/O 2017. The development landscape has shifted. Google Android With the newly introduced , the way Android applications are designed will change drastically. “architectural components” If I had been using all this time, I’d be filled with confusion. “How do and fit into my application?” Loaders ViewModels LiveData But I’ve been lucky. I had the opportunity to use instead. I could simplify most of my problems just by . Any changes made to Realm from any thread reflected on the UI thread without additional work beyond keeping a reference to a , and adding a to it. Realm “ ”, and everything was always up to date listening to changes in the database RealmResults RealmChangeListener With the introduction of , a lot of benefits that I took for granted with Realm are now available for everyone else — but on top of SQLite. Room DAOs and observing the database With Room, your typical reactive data access layer would look like this: As you can see, all DAO methods return a that you can subscribe to for changes. LiveData<T> Subscription to changes isn’t a new concept at all. Realm had received a lot of criticism for “being all over the codebase”, but in reality, no one ever stopped anyone from creating their own Realm-based DAOs to collect the queries in one place. In fact, it would look something like this: — — — — — — — — — — — — — — — — — — — Once we have that, we can observe the changes like so: And while traditionally, you’d have the (and maybe even the instance) managed by the activity/fragment’s lifecycle callbacks directly, this is partly what is responsible for (the other half being a data holder for Activities and Fragments — which can store subscoped Dagger components, for example). RealmResults Realm ViewModel scoped If we leverage the new lifecycle integration and wrap Realm in a ViewModel, we can even re-use this code above, and just use this view model instead: There’s an interesting thing to note here based on this example. Conceptually, and are the same thing. MutableLiveData<List<T>> RealmResults<T> In fact, even previously when anyone asked, I told them: if they use Clean Architecture with Realm, and their data layer returns a instead of something like a that would mutate in place and provide the means to add/remove a change listener, then they were using Realm wrong, they were making their life far more complicated. List<T> MutableLiveList<T> and Still, a key difference is that SQLite will eagerly evaluate your query results, while Realm provides lazy-loaded ones. As Realm’s results are lazy-loaded, this kind of “scoped caching” provided by ViewModel wouldn’t even be necessary, but it’s nice to see a code that and can abstract Realm away from the Fragment itself, doesn’t it? :) provides reactivity properly Turning the data layer reactive, instead of just concating Singles Now, there’s a very common architectural decision I see all over the place, but I never truly undestood. People often create a class that is responsible for “selecting data from an in-memory cache, the local data source, or the remote data source” — I think this comes from but it might even originate from Repository Fernando Cejas’s “Architecting Android: The Evolution” , Dan Lew’s “Loading Data From Multiple Sources” . Typically this results in a operation that has a sort of algebraic beauty to it: concat // from Dan Lew's articleSingle<Data> memory = ...; Single<Data> disk = ...; Single<Data> network = ...;Single<Data> source = Single .concat(memory, disk, network) .first(); // <-- return only 1! In the new world where you can observe changes in the database, you don’t only ask for element. You ask for an . It can be elements. 1 Observable 1…* If you just retrieve a element from your data sources and otherwise for changes made to the database, then ? Where’s the REACTIVEness of your Rx-based solution? single don’t listen where’s the reactivity As such, I do NOT understand this data layer design. I drew a graph in Paint to illustrate the point (also available ): here Traditional “cold” repository implementation with multiple data sources As you can see, the presenter does not subscribe . How would any background operation that changes the data set reflect in the presenter? There is no way to listen. for changes Instead, a possible approach would be to start a one-off operation that retrieves the data from remote , but otherwise listen only for changes in the local data source. if necessary Repository listens to local datasource as “hot” event source Previously, your caching could be done via , which would return the latest value upon subscription (which already replaced the in-memory cache as a data source). Jake Wharton’s RxReplayingShare Now this is handled by (scoping of data) and (holding previous value, and allowing subscriptions — similarly to ), so caching is no longer the responsibility of the Observable chain: ViewModel LiveData BehaviorRelay This way, we have created scoped data and listening for changes using Architecture Components, while we’ve (instead of requesting the data only once, and then having no means of update if the data has changed). kept reactivity in our data layer Conclusion I personally welcome the new change brought to Android applications using and . After more than a year of having used Realm, this simplicity introduced by reactivity feels just like home — whether it’s or :) ViewModel LiveData Realm Room. The concept is the same, and thankfully it’s much better, much easier, and much more stable than either loaders, or concating singles.
