views:

1696

answers:

3

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?

A: 

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.

codelogic
A: 

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:

August
+1  A: 

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.

Dan Keen