Image from Pexels

Android Paging Library — Make your lists as efficient as possible literally in just an hour directly from the network! ヽ(*・ω・)ノ

So, the new Paging Library is coming to Android as a part of the Architecture Components. It’s still in alpha but there is no doubt that you are already ready to try it! And I’m not gonna tell you about the usage of all this stuff. Because this article it’s just a short addition of the great article by Chris Craik that you are able to read here.
So, when you should use it. Ok, if you gradually load information as needed from a data source and you don’t wanna overload the device or wait too long for a big database query then probably it’s the right moment to try it.

Because from the examples at first glance it seems like all those nano technology work only with Room we might wanna avoid the usage of the library if we don’t need it. Let’s see a short example, implement it and prove that there is some hope.

Ok, imagine that we wanna write some test application in order to test our API. We don’t wanna use any database or storage but we still wanna do it efficiently and don’t load all data at once because it will be horrible application even if it’s only for test purposes. What are you thinking about in the first place. Yeah, I’m sure about some tricky onScrollListener or about the approach with binding of the last item through the ViewHolder to know the right time to start fetching. Anyway, you are thinking about some sorta paging to fetch data only when we need it. But while we are in the process of thinking we lose the idea of the fast check of our API. Ok then let’s see what we’ve got with this library.

As an example we are gonna test Kitsu API (yeah, I like such kinda stuff ). And we have a simple task. We just wanna display a list with some content fetched using our API. And yes, our API support paging! So, it’s a sign! (ノ´ヮ`)ノ*: ・゚


So, we definitely need the main thing like Activity with our list:

nothing special here. We have our simple ViewModel. Our layout contains only RecyclerView to display data and some search view to specify some particular query. By default we search for something to display at least some fancy results because I have no time for shiny empty view here. Also notice that there won’t be any sorta clean patterns and super-duper Kotlin’s stuff. Thanks for understanding because it’s just an example (>﹏<)


Right. There is more. Let’s do it just step by step with some brief explanation. Now we need to explore our ViewModel:

Every time when we specify some new query we need to update our datasource to be up-to-date and fetch the right data and also we invalidate our current LiveData to use fresh one later. Please notice the important moment that to use the undefined number of items (DataSource#COUNT_UNDEFINED) easily (because I really have no idea beforehand how much items I have) we have to disable placeholders (or make it as contiguous). Why? Because if we wanna use them and see nice empty views while data in the loading process then we have to specify the exact number of items. Ok, keep moving!


Let’s see how our provider for PagedList looks like:

Here we create our DataSource based on the abstract custom DataSource to be able to override the behaviour of the conversion (we don’t need it here, but just as an example). We backed it in the separated field to be able to change the query filter. And finally using this datasource we create LivePagedListProvider to create LiveData later. And yes you probably noticed that we also pass the API object to fetch our data using Retrofit.


What kind of data do we have? No magic, it’s simple data that will be converted from the Retrofit’s call:


Now it’s time to see how our abstract custom DataSource looks like:

We use TiledDataSource to simplify the usage but it’s probably the wrong way because in a case of TiledDataSource we need some exact number of items but due to disabled placeholders it will be transformed to the ContiguousDataSource and everything will work magically. Because our API supports paging you see how easy to implement the loadRange method. And yes it’s safe to call some sorta long-running operations directly in the loadRange method because it’s called on the background thread.


Ok, look briefly at our API stuff:

Adapter & ViewHolder

I think we are almost done. Now it’s time for UI parts. Adapter and ViewHolder:

Nothing interesting about ViewHolder. Just my weird bind method with lots of “Oughhh…” stuff ヾ(  ̄O ̄)ツ More interestingly it’s that we extends PagedListAdapter and guess why? Because everything here is based on the concept of pages and this adapter is special one. Also we provide DiffCallback to compare our items properly and perform more efficient changes in our list via a special internal diff algorithm.


And that’ it! We are finally done! Congrats! But how does it work??? ( ̄0 ̄)
See below of course ᕕ( ᐛ )ᕗ

And I almost forgot to mention that Chris Craik told us:

Paging alpha1 doesn’t drop data — wanted to get that in, but wasn’t able to for the first alpha. Will be added in the future, and the in-memory max count will be configurable.

UPD: Don’t miss your chance to listen to a great episode with Florina Muntenescu about Android Architecture Paging Library! Check this out here!
Good luck! ヾ(。・ω・)シ
UPD: Handled the request about the source code, see it here, the rough java version here! ヽ( ・∀・)ノ

So… It’s great news! Stay tuned! And if you still read here then thank you very much ヾ(・ω・`)ノヾ(´・ω・)ノ゛Bye-bye! Cheers! ( ◡‿◡ *)

Malyshev Yegor aka brainal · Absorbed Android Developer @ Google · Kotlin lover · Sport Programming · Algorithms · Programming · Android · J`world