Why use UITableViewHeaderFooterView or tableHeaderView instead of multiple UITableViewCell? - ios

Question

Question
What is the benefit of using either tableHeaderView, tableFooterView or UITableViewHeaderFooterView as opposed to just using multiple UITableViewCell, and customising it to look like a header or footer?
Example
A static banner image
A static part with input fields that all look the same:
First name
Last name
Age
Height
Weight
A static part "Appointments", which can be expanded
A dynamic list of doctor's appointments
A static part "Images", which can be expanded
A dynamic list of images
A static part with a "Save" button
My gut reaction was making the top two static parts (1, 2) the tableHeaderView, the other static parts (3, 4) a section header, the dynamic lists (under 3,4) to becells inside sections, and the Save button the tableFooterView.
But then the input fields (under 2) look similar, so they could also be cells.
But then I need to treat sections in a special way, because the first section does not have a header view.
And then, 2 months later, the requirements change and 5 other special parts are added.
So all in all, I'm wondering, why not just implement everything as a UITableViewCell, and have a CellType enum that can easily be extended?
Then you have a flat array cells: [CellType] which is the single source of truth for the table view, and a single method func buildCells() where you populate this array.
So far, this is the only article I've found that talks about this, and I'm kind of agreeing with it.

Answer 1

This approach (just tableview cells, no header/footer views) works fine. In your example, I would have made all of these cells, too.
What is the benefit of using either tableHeaderView, tableFooterView or UITableViewHeaderFooterView as opposed to just using multiple UITableViewCell, and customising it to look like a header or footer?
While a series of cells might make sense in your particular example, I wouldn’t generalize that conclusion and, therefore, categorically dismiss the idea of header/footer views. There are many cases where the header/footer view approach is most logical and intuitive:
in many cases, the section headers don’t have any model data associated with them, but are just for organizational purposes ... in this case (e.g. grouping a list of contacts by the first letter), the header view approach makes a lot of sense;
in other cases, we’re dealing with arrays of arrays of homogenous items ... again, the header view approach makes lot of sense; it has the benefit that the index path section and row now map very nicely to the model;
sometimes we want a header to persist as it scrolls out of view (so the user can see what section they are in even though the header would have otherwise have scrolled out of view);
sometimes we want a footer that shows some derived, calculated value (e.g. when listing items on an invoice, perhaps the “total” should be shown in a footer).
Your scenario feels more like a heterogenous list of model objects. In that case, I think using cells for this model data is perfectly reasonable. But obviously header and footer views still have utility and, in many cases are simpler and more intuitive.