CODEWITHSUNDEEP
iphoneiosuitableview
c121hains
c121hains

Reputation: 95

Multiple custom cell types per table UITableView (iPhone)

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?

Upvotes: 4

Views: 4030

Answers (3)

sergio
sergio

Reputation: 69047

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.

Upvotes: 0

deanWombourne
deanWombourne

Reputation: 38485

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.

Upvotes: 2

Jeff Moore
Jeff Moore

Reputation: 444

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.

Upvotes: 4

Related Questions