Viable approach to an app with 99 large scrollview groups?

I’m planning a basic tips app with 99 individual tips on a subject, and I’m trying to figure out a sound way to do it in the time I have. I’ve used scrollview groups before, but nothing of this scope. Just a single scrollview group for the “About” area of an app. Here’s a pic to illustrate what I’d like to achieve:

corona-scrollview-question-1.png?Expires

Is this a reasonable approach? Are 99 image files of 1242 x 6000 pixels for the individual tip scrollview groups excessive? It’s easier from a development standpoint for me, since it means being able to create single image files for each tip, as opposed to breaking each one up into multiple files or using Corona’s newText api (since there will also be image files between the text blocks), but I haven’t attempted anything of this scope before so I don’t know how this would perform in practice. 

Why not use a tableview for this? Then you’ll only have ~8 items onscreen and rendered at the same time.

Otherwise you’re rendering 737 megapixels (6000*1242*99) at once, which seems a bit unlikely to work well.

Hi corona273, 

Thank you for responding. I’ll look into tableview because I don’t know anything about it, but I was assuming I’d destroy/remove each of the “tips” during the navigation, so as the user clicks or slides to see another tip, I’d then destroy the previous tip that was displayed. 

Well, tableview will only work vertically, so you’ll have to roll your own if you want left-right swipes on a second screen. But your vertical use case is what it’s designed for.

What did you mean by second screen? I didn’t understand that. About tableview too, the docs state that tableview doesn’t support scaling. I’m using zoomEven in my config.lua lately and liked how it worked on one app I just finished. It made it really easy to get the app working on different devices. Is that the kind of scaling that wouldn’t work with tableview? 

Your image above includes two different views. I used the word “screen” to refer to the second view.

As far as I know tableview supports adaptive scaling.

You might want to build the tableview sample project and test this (including zoomEven) for yourself.

Why not use a tableview for this? Then you’ll only have ~8 items onscreen and rendered at the same time.

Otherwise you’re rendering 737 megapixels (6000*1242*99) at once, which seems a bit unlikely to work well.

Hi corona273, 

Thank you for responding. I’ll look into tableview because I don’t know anything about it, but I was assuming I’d destroy/remove each of the “tips” during the navigation, so as the user clicks or slides to see another tip, I’d then destroy the previous tip that was displayed. 

Well, tableview will only work vertically, so you’ll have to roll your own if you want left-right swipes on a second screen. But your vertical use case is what it’s designed for.

What did you mean by second screen? I didn’t understand that. About tableview too, the docs state that tableview doesn’t support scaling. I’m using zoomEven in my config.lua lately and liked how it worked on one app I just finished. It made it really easy to get the app working on different devices. Is that the kind of scaling that wouldn’t work with tableview? 

Your image above includes two different views. I used the word “screen” to refer to the second view.

As far as I know tableview supports adaptive scaling.

You might want to build the tableview sample project and test this (including zoomEven) for yourself.