The combination of LiveData, LiveData Transformations, and Interfaces, allows you to abstract your Realm domain model and database in a way that was not previously possible. This lesson will teach you how to use LiveData with Transformations and Realm effectively, so that you can abstract your Realm data models entirely from your Activities and Fragments.
Summary of Content (what you will learn):
- How to expose
LiveData<List<? extends Model>>from your DAOs, where
- A Read Only view of your data.
- Database Agnostic - No ties to Realm or your underlying data model entities.
- An interface that can easily be mocked for testing.
How would you go about implementing a RecyclerView adapter that supports animations (essentially supporting notifyItemRange operations) that still keeps Realm/RealmResults abstracted away in the Repo/DAO layer? There is a realm-android-adapters project that offers the functionality, but you have to bleed in RealmResults in the UI layer.
Hi Eric, thanks for the quick reply!
I was just looking at Gabor's repos. I discovered his monarchy lib with a good sample for the pagination lib.
My use case involves a long list of "conversations/messages" (it could have 2-3k+ items) that can change, be deleted, etc. I've written a small prototype with Realm (Monarchy lib) and the pagination library to download the data in steps when the user scrolls through.
I'm not super comfortable with the idea of detaching 3k+ items from realm and running a diff on that (through PagedListAdapter) every time something changes. Bleeding Realm into the UI and using its OrderedCollectionChangeSet might be a more CPU/battery friendly approach. Any thoughts on that?
Hi Tudor. You're welcome! :-) . Sorry this one took a bit longer..
I think you're spot on! Using a RealmAdapter and OrderedCollectionChangeSet, is probably better for your use case (if you can accept exposing RealmResults to your UI layer.). The clear advantage here is that nothing is copied into memory except the property data on your model as you access it to populate your ItemView. This would remain efficient even if your users scrolled through all 3k messages.
Monarchy with Paging should address the situation of efficiently handling all 3k records, loading only one page of records into memory at a time. However as you pointed out, if your user scrolls through 3k+ items eventually you'll have that many detached objects to diff. Monarchy w/ Paging or your own abstraction in an RecyclerView.Adapter would work well for casually scrolling through a large list of items, but not at the level you've described.