views:

88

answers:

2

Hi guys.

This is the problem I'm facing right now:

I've got a lot of UITableViews with two sections each (only one is displayed at any time, on demand). The first section has got 3 cells, which might need to be resized. Because of that, I'm using heightForRowAtIndexPath.

The second section might have up to 3.000 cells, all using the default height of 44 points.

My heightForRowAtIndexPath determines whether it is treating a cell from section 1 or from section 2 and then either measures (section 1) or immediately returns the default value (44 section 2).

By using this method, large table views take a little while to be displayed, since heightForRowAtIndexPath is a performance issue in cases like this (more than about 1.000 cells).

My question is: Is there any way to resize just the 3 cells presented in the first section? Any way to maybe force heightForRowAtIndexPath to be called just for indexPath.section == 0?

In case it makes any difference, I'm using a grouped table view.

Thanks.

+2  A: 

heightForRowAtIndexPath is going to be called if it is implemented in your delegate. If you're only looking to change the values in the first section, then just use a simple if statement. This could look like:

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
    // Test to see what section you're in
    if ([indexPath section] == 0) {
        // return the height for the first section
    } else {
        // return the height for everything other than the first section
    }
}

Cheers.

Neal L
A `switch-case` tree is a much cleaner approach to testing the `indexPath` section value and returning the desired height, but it is the same idea.
Alex Reynolds
That's actually how it looks like in my code. The problem is that it is a performance hit with very large tableviews, although I only need it because of 3 cells. So what I wanted to know is if there is a way around this.
Aloha Silver
Another approach you could consider (if it works with your problem domain) is not placing this information in a UITableViewCell. Have you considered displaying this information as the tableview's header? This would not be called nearly as many times as `heightForRowAtIndexPath`, and if it is the first section then it stands to reason that it could be implemented this way...
Neal L
I chose this as the answer because I ended up modifying the tableview header, as Neal suggested as a comment.
Aloha Silver
A: 

Why not just use 2 table views--one for your top section, and one for the second section?

You could either give each UITableView a different delegate, or if they share the delegate, you could return immediately from heightForRowAtIndexPath for the bottom UITableView.

I'd probably give them each a different delegate, to avoid a lot of switching in the delegate methods to figure out which section you're in.

chrispix
Would they scroll together? I actually thought about it for a while, but didn't think it would actually be possible.
Aloha Silver
Yes, they'll scroll together. It's just like having any other set of views inside a UIScrollView.
chrispix
Although I chose tomodify the tableview header, two tableviews is also an excellent solution. One that I didn't think as possible, actually. So thank you very much.
Aloha Silver