Setting up a UITableView with multiple rows containing different child views - ios

Question

As a small disclaimer, I'm pretty new to iOS Dev and have mainly worked with Appcelerator Titanium in the past, so this may be pretty basic.
Currently I'm in the middle of trying to create a page in an iPhone app that pulls data from an external API. That API returns a JSON array of objects that I'm using to populate a table (pretty standard behavior).
Each hash in the array contains of squares that I need to display in the table view and thy are formatted different based on the number of squares. For example:
If one comes back the table view cell contains a name and a single large square.
If two come back the table view cell contains a name two slightly smaller squares positioned overlapping.
If three come back the table view cell contains a name three slightly smaller squares positioned shaped like a triangle.
If four come back the table view cell contains a name four slightly smaller squares positioned in the shape of a square.
If more than for come back the table view cell contains a name, four slightly smaller squares and the last square has a +x count for how many there are in addition to the first 3.
Note: The name is in the exact same place on each cell.
So the real question is it seems like I'm not sure which of these two options are the best way to go:
Create 5 different SpecificCell.xib files (along with .h and .m files) and in cellForRowAtIndexPath create one of those and return it. This seems like a LOT of duplicate code for name, etc. and in general just a ton of code (15 new files) for something that realistically only changes a part of the cell (Name remains in the exact same spot, only the square images change).
Create a single Cell.xib (along with .h and .m files) and pass the dict to a new function that returns a parent view and the child square views, then add those to the cell in cellForRowAtIndexPath.
My main concern, and I'm curious what actual Objective-C developers tell me here haha, is do I receive memory benefits from using the first approach because the app already knows in memory how to create a cell with those exact views?
Or, is there a third way I don't know yet?

Answer 1

Your analysis of the issue is correct, and if this is as small as you describe there shouldn't be a performance penalty either way. Both of these are correct, but you have more options:
Create a class for each cell (and new xib), but combine them in one file. It's only by convention and Xcode's "new file" windows that each class always gets its own file. TableViewCells.h (TableViewCells.m is optional if you're just adding IB outlets). Then in this file:
#interface OneImageCell : UITableViewCell
#property (weak, nonatomic) IBOutlet UIImageView *firstImage;
#end
#interface TwoImageCell : UITableViewCell
#property (weak, nonatomic) IBOutlet UIImageView *firstImage;
#property (weak, nonatomic) IBOutlet UIImageView *secondImage;
#end
Easy to forget this creates the class, not the file in the list. Probably not necessary in this case, but good to know if you do find yourself needing many tiny subclasses and don't want to clutter the file list. Swift actually does away with the convention of one class means two files, good riddance.
Create new .xibs for each cell, but one combined class file and switch dynamically. Long the trick for combined code used iPhone/iPad apps, I find it it's a bit cumbersome to set up and manage. Useful if you're creating prototype cells in a tableView in IB, since you don't have to write the code, just set the class of the cells to be the same and reuseIdentifiers to be different.
Use the same xib .h and .m, but use different reuse identifiers. The reuse identifier fulfills its purpose here. Regardless of the same class and xib, if using different reuse identifiers then they will go into the same pool, saving setup work when reused. In -cellForRowAtIndexPath setup and use the kind of cell you need, and you could set a flag as a property of the cell to confirm setup work has already been done, saving that work.
Of these, 2 with IB is probably the simplest and most Apple-y, which is usually the way to go. All would be fine, including your two -- save work when you can, but again, even doing light-to-moderate setup in -cellForRowAtIndexPath is usually fine.