4

I've been searching everywhere on Apple.Developer and Stackflow and haven't come to a clear, standard and proper way of handling this. Basically what I'm looking to do is how to represent more than one customized cell type in a table. Also, there are other tables in the app that will potentially reuse some customized cells.

Most of the time, tables will have the same cell type repeated over and over. But in a few cases, I have a table with a couple types of complex custom cells.

Listed below are the different ways I've learned you can do this. I've tried each one and they all work but I'm unsure of the "proper" way and a way that Apple won't reject.

1) programatically - ultimately, this is the best choice for performance. But if there's a way that I can draw complex customized cells in Interface Builder, it would be the better choice. This is what I'm trying to avoid.

2) a customized cell class with a separate XIB - each customized cell has its own header/implementation/XIB and is a subclass of UITableViewCell. A single cell in a XIB has its file owner set to a specific UITableViewController class. The View here has also been removed.

3) a customized cell in the same XIB as the view controller's XIB - I read that this is bad. A controller should only be associated with a single view in the hierarchy. I included a customized cell in the XIB at the same level as the view and then just linked it up to the controller's IBOutlet.

4) a separate common XIB - this is essentially a dumping ground for customized cells. The view here has also been removed. The XIB contains multiple cells and each cell is associated with a specific subclass of UITableViewCell. A header and implementation file contain the definition and implementation for each cell that is subclassed from UITableViewCell. In the controller that is showing the table, the method cellForRowAtIndexPath, loops through the NSBundle for this common XIB and finds the cell associated with a specific subclass type of UITableViewCell. Then it returns that. This works beautifully for reuse throughout the app but something is telling me it's bad.

What would be the proper way for different cell types in a single table?

c121hains
  • 95
  • 1
  • 6
  • If you want to reuse a customized table cell with multiple view controllers, check out [this answer](http://stackoverflow.com/questions/540345/how-do-you-load-custom-uitableviewcells-from-xib-files/1939305#1939305). The two methods described there let you load table cells from nib files without having to set the File's Owner to a specific controller. – albertamg Jul 07 '11 at 17:14
  • Thank you all! All comments were helpful. With my project, I tend to develop all cells programatically unless they are really complex. – c121hains Aug 12 '11 at 18:44

3 Answers3

4

I have found that option #2, a custom cell class with a separate XIB, is the easiest to maintain.

Creating everything in the code will run faster, but when I'm developing, it takes more time/effort to get into the flow of modifying the code. In the end, ease of maintenance is more important than a minor hit in performance.

Jeff Moore
  • 444
  • 2
  • 10
  • I don't see any downside to this approach. Visually it is nice having the cells in XIBs if they have any complexity in their layout. I agree with the OPs assessment that #4 smells like a hack. – Stephen Petschulat Jul 07 '11 at 18:33
2

Simply, if it works for you then go for it. All of these ideas are viable solutions.

Personally, I'd go for them in this order : 2, 1, 4, 3. Though that's just my personal preference.

PS None of these ideas are going to get your app rejected by Apple.

deanWombourne
  • 38,189
  • 13
  • 98
  • 110
0

I don't see any drawbacks for your method 4, which is a variant of method 2 (using just one xib for all cells instead of one for each of them).

I don't see any need for defining the cell programmatically, nor to bloat the xib associated to your main view controller with all the custom cells (that you could reuse elsewhere).

Implementing option 2 or 4 does not entail a big difference. With option 2 you load the nibs one by one, with option 4 you load the unique nib, then manage the array of objects (views/cells in your case) that you get.

sergio
  • 68,819
  • 11
  • 102
  • 123