How to reuse/recycle custom element like uitableviewcell does?

Question

When using UITableView, we can reuse its cells using [[ UITableViewCell alloc] initWithStyle: reuseIdentifier:] and [uiTableViewInstance dequeueReusableCellWithIdentifier:] methods. This helps keep memory in check for huge tables as only a few cells are there in the view at a given instant.

I want to create a UIScrollView that has many subviews. Inserting all the subviews takes up a lot of memory and initial time that I want to avoid. Does Apple API provides ways to reuse such custom components (a UIView or a subclass of it here) just like cell views using a identifier?

I will create one if there is no API, but have some doubts regarding this. For example, for every new subview, I am setting its frame position, after the previos views. How should I go about updating the frame for each subview while recycling? Should I delete and reload the content of every subview as it gets recycled? Should I do all these calculations in another thread to avoid jerky scrolling? In all, I would like to have a smooth scrolling experience like in UITableView with all the reusing stuff.

Here is a sample of code that I have written so far:

int numberOfPages = 0;
int pageWidth = 100;
int pageHeight = 100

UIScrollView *myScrollView = //allocate and initialize a scrollview
//set its size to 100 by 100 (width equal to pageWidth)
//set paging enabled for myScrollView

Adding subviews to it from a method, that is called multiple times

- (void) appendSubViewToScrollView {
    UIView *view = //allocate and initialize a view and dump data in it.

    CGRect rect = view.frame;
    rect.size.height = pageHeight;
    rect.size.width = pageWidth;
    rect.origin = CGPointMake(pageHeight * numberOfPages, 0);
    view.frame = rect;

    [myScrollView addSubview:view];

    numberOfPages++;

    [scrollView setContentSize:CGSizeMake(pageHeight * numberOfPages, pageWidth)];

    [view release];
}

Edit:
Some insight into how tableview and its cells achieve this behind the scenes would be useful.

Answer 1

Yes, you should restore each subview content each time, exactly as in the table view. The advantage of recycling subviews is in memory saving for view storage, and time saving for view allocation, but of course content data management is up to you.

So the standard recycling approach requires you to use a number of cells which is equal to the number of views visible at the same time on screen + the number of extra cells you may get when starting scrolling. Let's say for example you're showing 5 full views at a time (scroll view stable) and then while scrolling you will need one extra view which is partially shown, so at the end you need 5+1=6 views. This is in theory, it is recommended to use 2 more views. So you need to write two pools: one called "visibleViews" which is made of all views added as subviews to the scrollview, and another one called "availableViews" which is made of all views available for re-use. Then you create all these views and add them to the scroll view (yes: you need to adjust their frame according to their position in the scrollview, and yes, you need to setup the content again). Finally you need to track the scroll view movement by setting a delegate. The purpose of this tracking is to calculate which of the visible views is no more visible, then remove it from the visible pool and move to the usable pool. Besides the delegate must understand when a new cell is going to appear but it is still not visible, then getting it from the available pool (or alloc/init it if the pool is empty) and adding to both the visible pool and as subview of the scrollview. Of course if you want to increase performance you can place more subviews in the scroll view in order to avoid to move cells exactly when they start appearing on screen, that's why I recommended to use a couple of extra views at the sides of the scroll view.

There is a great video from WWDC 2010 (you can access it if you're a registered developer) about usage of scroll views in iOS: it explains this technique.

The Apple's PhotoScroller example code in the XCode documentation does essentially what is stated in the WWDC video and explains this technique.