Multiple custom cell types per UITableView table (iPhone)

Question

I searched everywhere on Apple.Developer and Stackflow and did not come up with a clear, standard, and proper way to handle this. Basically what I want to do is to present in the table more than one configured cell type. In addition, the application has other tables that can potentially reuse some configured cells.

In most cases, the tables will be repeated over and over. But in some cases, I have a table with several types of complex user cells.

Listed below are the various ways in which I learned that you can do this. I tried each of them, and they all work, but I'm not sure of the right way and the way that Apple won't fail.

1) software - ultimately, this is the best choice for performance. But if there is a way that I can draw complex custom cells in Interface Builder, that would be a better choice. This is what I am trying to avoid.

2) a custom cell class with a separate XIB . Each custom cell has its own header / implementation / XIB and is a subclass of UITableViewCell. One cell in the XIB has a file owner set for a specific UITableViewController class. The view is also deleted.

3) a configured cell in the same XIB as the XIB view controller . I read that this is bad. A controller must be associated with only one view in a hierarchy. I turned on the configured cell in the XIB at the same level as the view, and then just tied it to the IBOutlet controller.

4) a separate common XIB is, in fact, a dump for configured cells. The view here is also deleted. The XIB contains several cells, and each cell is associated with a specific subclass of UITableViewCell. The header and implementation file contains a definition and implementation for each cell that is subclassed from UITableViewCell. In the controller that the table shows, the cellForRowAtIndexPath method passes through the NSBundle for this common XIB and finds the cell associated with a particular type of subclass of UITableViewCell. Then he returns it. This works great for reuse throughout the application, but something tells me bad about it.

What would be the appropriate way for different types of cells in the same table?

Answer 1

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

Personally, I would follow them in this order: 2, 1, 4, 3. Although these are only my personal preferences.

PS None of these ideas are going to reject your Apple application.

Answer 2

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

Creating everything in code will work faster, but when I develop, it takes more time / effort to get into the stream of code changes. After all, ease of maintenance is more important than a minor hit on performance.

Answer 3

I see no flaws for your method 4, which is a variant of method 2 (using only one xib for all cells instead of one for each of them).

I don’t see the need for cell programming or xib bloating associated with your main view controller, with all custom cells (which you could reuse elsewhere).

Option 2 or 4 does not make a big difference. With option 2, you load the tips one by one, with option 4 you load a unique nib, and then control the array of objects (views / cells in your case) that you get.