views:

507

answers:

2

I've got an UIScrollView with a grid of images. Currently they're only 6, but there might be a few hundred some day. So of course it would be a bad idea to create a few hundred UIImageView objects inside that UIScrollView and fill them all up with image data. I think I was reading this somewhere in the Apple docs: They recommend to only create so mutch elemends as you need to fill up the scrollable visible area.

But I fear performance issues if I would instantly reposition UIImageView elements. I think. As the user starts to scrolls down (lets assume it starts at 0,0), I'd have to reposition those UIView objects that go out of visible area at the top, positioning them quickly to the bottom and then assigning very (!!) quickly an new image object to that UIImageViews in the row. I mean... what if the user starts scrolling like a wild gazelle, faster and faster?

How's your approach for doing that?

+1  A: 

UIScrollView (or actually UIKit) is very good at not redrawing things that don't change. If you only move (or remove to recycle) off screen (or clipped) views your will not incur a redraw. Ditto with adding subViews off screen.

If you don't have paging enabled, you will probably have to implement some faster drawing code that UIView offers. However I would test first - the physical limitations of the iPhone limit scrolling to some extent.

Roger Nolan
+1  A: 

In a similar, though smaller scale situation, I dealt with this by loading more than I needed for the scroll view dimensions, but not the entire data set. I was only scrolling horizontally and I found that loading 1 or 2 images on each side of the currently-visible one kept things nice and smooth. That's still loading 3 or 5 images when only 1 is visible, but it's a hell of a lot better than loading up dozens of them. You'd need to experiment a little to see how much slop you need to allow around the visible area.

Dynamically loading/unloading images is best handled in the scroll view's delegate methods.

Tom Harrington