CODEWITHSUNDEEP
iphoneobjective-ccocoa-touch
Coocoo4Cocoa
Coocoo4Cocoa

Reputation: 50866

Better way of handling UITableViewCell

I have a table which has roughly 10 cells, 4 different types. I subclassed UITextViewCell because I wanted to have an IBOutlet to a label and to a UITextField. Not sure if that was the best way of handling it, but it works thus far. Next, I had a cell for gender, so I figured instead of subclassing UITableViewCell, I took my already subclassed cell with a UILabel and UITextField, and wrote the following code:

NSArray *buttonNames = [NSArray arrayWithObjects:@"Male", @"Female", nil];
UISegmentedControl* segmentedControl = [[UISegmentedControl alloc] initWithItems:buttonNames];
segmentedControl.momentary = YES;               
segmentedControl.autoresizingMask = UIViewAutoresizingFlexibleWidth;
segmentedControl.segmentedControlStyle = UISegmentedControlStyleBar;
segmentedControl.frame = CGRectMake(75, 5, 130, 30);
[segmentedControl addTarget:self action:@selector(segmentAction:) forControlEvents:UIControlEventValueChanged];
for (UIView *oneView in cell.contentView.subviews) {
    if ([oneView isMemberOfClass:[UITextField class]]) {
        [cell.contentView insertSubview:segmentedControl aboveSubview:oneView];
        [oneView removeFromSuperview];
    }
}
[segmentedControl release];

How horrible is that for going about this? Should I be subclassing UITableViewCell 5 times for one complex tableView? Is handling it in edge cases such as the following OK?

Upvotes: 1

Views: 2164

Answers (3)

Dan Keen
Dan Keen

Reputation: 129

I'd actually go for subclassing. Subclassing is cheap. The cells have different types, and what you're doing now is iterating through all the subviews and checking each view for membership of a class - this is slow! A subclass will clean up your code and make it faster at the same time. Don't try to shoe-horn too many things into one container, as it were.

Upvotes: 2

August
August

Reputation: 12187

If this is the only table where these cells will be used, I'd go ahead and configure them on the fly in the tableView:cellForRowAtIndexPath: method. Don't worry so much about subclassing.

And make sure you tag each subview (the labels, for example). That way, you can reference the label by using viewWithTag:

Upvotes: 0

codelogic
codelogic

Reputation: 73692

You could always just add the control to your subclass but have it hidden. Then, depending on the row, set the cell's "mode". The mode setter can hide / unhide the controls that pertain to that row. If performance is an issue, maybe use multiple cell IDs so that the views are cached.

Upvotes: 0

Related Questions