Hello all Is there something to allow loading larg...

# android

[Sergio C.]

Hello all
Is there something to allow loading large lists asynchronously in a RecyclerView?
In my app I have to display a very big list of items in a RecyclerView and that takes a while to load and layout, locking the entire UI for a few second which is not optimal…
The items have just two TextViews which combine to about one line of text, so it's not anything complex...
I've checked PrecomputedTextCompat but it makes it even slower 😄
Maybe Paging?..

[gian]

why do you think it's the RecyclerView? RV only creates as many views as will be displayed, so even if your list is huge, if your phone displays 10 items, only 10 rows will be created

[Dominaezzz]

Paging perhaps?

[Sergio C.]

Yes, RV should be drawing just the needed items, but with very large lists it struggles... probably because it's a nested recyclerview..

[Sergio C.]

need some more testing

[Adam Powell]

Are you nesting horizontally scrolling rows inside of a vertical scrolling list, or are you trying to nest a vertically scrolling list inside another vertically scrolling list?

[Adam Powell]

Vertical inside vertical with RecyclerView basically means you've turned the outer RecyclerView into an overly complicated LinearLayout

[Adam Powell]

If that's what you have, you'll want to create a concatenating adapter so that you only have one vertically scrolling RecyclerView that presents the concatenated content

[Sergio C.]

Yes, it's a vertical RV inside another vertical RV.
It's done that way because there's a lot of data to display.
the concatenating adapter solves the problem? how can we create it?

[Adam Powell]

you want a single adapter, the idea of a concatenating adapter is just one approach to that

[Adam Powell]

you can delegate to some other smaller adapter-like interface of your own as well if you'd like it to be simpler

[Adam Powell]

the reason nesting vertical recyclerviews inside other vertical recyclerviews causes the problem you're seeing is because you've created an unstoppable force meets immovable object scenario:

[Adam Powell]

RecyclerView offers infinite vertical space to its children but only creates enough children to fill its own space

[Adam Powell]

if you put a vertical RV into a vertical RV, the outer one gives infinite space to its children, so each of the inner RVs will create and lay out child views for their full adapters

[Adam Powell]

so there might be only one visible inner-RV on screen, but it's created views for its entire data set, creating the performance problems you're seeing

[Sergio C.]

Yes @Adam Powell you are right. The inner RV is creating and binding views for the entire data set! 😮

[Sergio C.]

I specially created an inner RV to try to solve this problem with a big data set...but no I didn't solve the problem.

[Sergio C.]

It is still very slow.

[Sergio C.]

I'm not sure how I can implement your ideas of an adapter-like interface or concatenating adapter... do you have any examples I can check?

[Adam Powell]

There are some examples of the idea around the web if you search for "RecyclerView merge adapter" and similar terms

[Sergio C.]

Thanks! I'll see what I can do.

[Pablichjenkov]

Have you checked FastAdapter or Epoxy or Yelp's Bento libs. Not sure exactly what's your use case but these libraries remove RV boilerplate in general.

[Sergio C.]

I'm checking this merge adapter https://github.com/martijnvdwoude/recycler-view-merge-adapter but, this is creating the RV items independently, my items are nested. the main RV item has a RV with sub items. they depend on each other. I think this won't work.

[Sergio C.]

@Pablichjenkov no. I'll check it out, thanks.

[Pablichjenkov]

@Sergio C. I just checked the above project. As its names indicates is basically an adapter merger. Which is fine depending on your use case but you will still have to code for MultiCell type and sort of.
The libraries I mentioned have way more features.

[Sergio C.]

FastAdapter looks good. Have you used it?

[Pablichjenkov]

Yes although I haven't explode all its potential. On a previous company that I worked (https://play.google.com/store/apps/details?id=com.ncl.bge) I used it although modifying it a little bit. I did end up not using their Selectable API, my own code was easier to me to resolve certain design request. Also for Sticky Header you will need to integrated with another library, it offer the extension but is basically abstract. You need to fill the abstraction with another library or your own StickyHeader code. There is a sample for that.
I am working on a sample project to test coroutines concepts and I included this library just in case. Haven't done any major UI work yet, just a couple of grid screens.
https://github.com/pablichjenkov/Android-Actor

[Sergio C.]

Yes I see FastAdapter uses multiple dependencies we can implement to add more functionality. Its a good idea to avoid adding unnecessary code. I need to explore it too.
Your cruise app looks awesome. with many downloads also. 👍

[Sergio C.]

I've stared your repo so I can check it later, Just learned a new trick from your code 🙂 always learning.

[Pablichjenkov]

Jiji, learning never stops and the more you know the more you don't know too 🙂.
The take away with all this RC.Adapter wrapper libs is checking what they do in code and extract it. You may doing your own, you may not need all the features or you may not like certain api.
I usually extract the multi-view-type logic and the methods related to see the cell coordinates and data position as the RV scrolls.
Then on top of that build my Frankenstein.
By the way the multi-view-type logic in Epoxy is just fast.

[Sergio C.]

The more I know the more I know there's more things to know...
I also prefer to extract the piece of logic I need and solve the problem with less code.
Cool. need to check out Epoxy.
Still don't know how to solve my issue... Need to sleep I'll check it out tomorrow. maybe I'l wake up with ideas. thanks for the tips. 👍 👍

[Pablichjenkov]

Exactly!
Epoxy spins around the same principle. Is an RV.Adapter wrapper with the purpose of removing the boilerplate we would write if using the raw API. They started good, I haven't followed it. Last time I checked it they were doing heavy annotation processing to generate everything pretty much for you. I kind of dislike some pert of their API too. Is the typical case where I just extract what I need.
Regarding you initial problem I never understood it in full. If your screen and cell design have no other option than having two scrolling components nested. You may try to set a fixed height/width to the inner RV. It would smooth the computations a bit. Try also a plain Scroller with a LinearLayout and see what happens even though your RAM consumption will spike a little bit.
Eat healthy, workout, properly sleep and smile. Your code will get better.