Maximum length of scrollview / no. of elements

Solar2D General Questions/Discussion
#1

I’m working on an app that incorporates a search mechanic that pulls records from a database and spits them out into a scrollview. Just one text element per record, though it may end up a couple of images per record too, used as buttons.

It’s entirely possible though that we’re going to end up with tens of thousands of records in this database and I’m wondering if this is going to be an issue. Does Corona impose any kind of limitations as to how long the scrollview can get, or how many display objects it can contain? Or am I going to need to factor in the amount of memory available on the device?

If I need to work in a pagination system then sobeit, but I’m hoping scrollviews just handle off-screen culling automagically and I can be lazy with this part…?

#2

I looked into creating a level select system using scrollView once. I populated it with thousands of images, but the end result was that it become too cumbersome, i.e. laggy.

I don’t believe that there is a strict limit imposed by the widget, but your mileage will vary depending on your user’s device. Tens of thousands of display objects, to my ears at least, sounds like way too much to be loaded into a scrollView at once (and to be scrolled at once).

To my knowledge, there’s no automagic off-screen culling either. This is why I just decided to write my own scrollable level select system in the end. :stuck_out_tongue:

#3

Bummer, I guess this thing needs pagination then even without hard limits. Cheers for the heads up!

#4

Have you considered using a TableView instead? I believe that does utilise off-screen culling.

#5

I’ve only briefly looked at the tableView widget. Not enough to know whether it’s suitable for this particular app, and I’d already built a tonne of fancy UI into the scrollView before seeing that tableView was a thing so it’s probably a bit late now :pensive:

#6

There’s not a lot of work involved to convert from ScrollView to TableView. Rather than creating your rows in a loop and positioning them manually within the scrollView, you call insertRow in a loop, including any required data in the params field, and then within OnRowRender create the visual elements. 

Of course if your scrollView has irregular sized rows or other things going on it might be a bit more challenging, but category rows can be a way around that.

#7

My view is a bit more complex than that. It’s basically an accordion menu - each row slides open/closed to reveal input controls, and actions within some of the rows affects the content within others. The inputs themselves are arranged into adjustable columns too. The whole thing basically resizes and repositions a whole tonne of elements while it’s being used.

It’s pretty nifty actually. I was originally planning to release it as a UI plugin on its own but I’ve ended up having to rush through half of the main app build now and a bunch of project specific functions got mixed into the UI modules along the way… I’ll do a proper rewrite later and get it into the marketplace.

#8

you can make your own scrollView limit (showing only a XXX height you want) and if the user is near that limit just remove top content and add more bot content. It will micro lag in those points, but at least it will not crash the app.

#9

Excellent idea, and perhaps more intuitive to use than actual pagination. I’ve never thought to incorporate game optimisation tricks into apps before :thinking:

#10

I looked into creating a level select system using scrollView once. I populated it with thousands of images, but the end result was that it become too cumbersome, i.e. laggy.

I don’t believe that there is a strict limit imposed by the widget, but your mileage will vary depending on your user’s device. Tens of thousands of display objects, to my ears at least, sounds like way too much to be loaded into a scrollView at once (and to be scrolled at once).

To my knowledge, there’s no automagic off-screen culling either. This is why I just decided to write my own scrollable level select system in the end. :stuck_out_tongue:

#11

Bummer, I guess this thing needs pagination then even without hard limits. Cheers for the heads up!

#12

Have you considered using a TableView instead? I believe that does utilise off-screen culling.

#13

I’ve only briefly looked at the tableView widget. Not enough to know whether it’s suitable for this particular app, and I’d already built a tonne of fancy UI into the scrollView before seeing that tableView was a thing so it’s probably a bit late now :pensive:

#14

There’s not a lot of work involved to convert from ScrollView to TableView. Rather than creating your rows in a loop and positioning them manually within the scrollView, you call insertRow in a loop, including any required data in the params field, and then within OnRowRender create the visual elements. 

Of course if your scrollView has irregular sized rows or other things going on it might be a bit more challenging, but category rows can be a way around that.

#15

My view is a bit more complex than that. It’s basically an accordion menu - each row slides open/closed to reveal input controls, and actions within some of the rows affects the content within others. The inputs themselves are arranged into adjustable columns too. The whole thing basically resizes and repositions a whole tonne of elements while it’s being used.

It’s pretty nifty actually. I was originally planning to release it as a UI plugin on its own but I’ve ended up having to rush through half of the main app build now and a bunch of project specific functions got mixed into the UI modules along the way… I’ll do a proper rewrite later and get it into the marketplace.

#16

you can make your own scrollView limit (showing only a XXX height you want) and if the user is near that limit just remove top content and add more bot content. It will micro lag in those points, but at least it will not crash the app.

#17

Excellent idea, and perhaps more intuitive to use than actual pagination. I’ve never thought to incorporate game optimisation tricks into apps before :thinking: