Effective way to design and manage iPhone application similar to settings

Question

I would just like to clarify that by 'design', I mean software design, not UI design.

I have an application similar to the native settings app. The problem I have with it is it doesn't follow the same clear-cut MVC style. Other apps tend to focus around displaying one kind of thing. In the case of a periodic table app for example, it's elements. The elements clearly comprise the model, and they share similar properties and behaviours, meaning they can be displayed and interacted with identically. An app like this almost designs itself!

My app, like the settings apps, consists of an arbitrary selection of rows displaying dissimilar data in dissimilar ways. One row might contain a switch, the other might modally present a very specific view when tapped. They're all very different.

How do you design something like this?

At the moment, I'm doing it all in the view controller, and the relevant rows are being tracked via an enum:

enum {
    kNameRow,
    kGenderRow,
    kJobTypeRow,
    kLevelOfExerciseRow,
    kEmailAddressRow,
    kTelephoneNumberRow
};

As I described, these cells are all very different, so displaying cells is handled like this:

// - tableView:cellForRowAtIndexPath pseudocode.

switch (indexPath.row) {
    case kNameRow: // create name cell.
    case kGenderRow: // create gender cell.
    case kJobTypeRow: // create job type cell.
    case kLevelOfExerciseRow: // create level of exercise cell.
    case kEmailAddressRow: // create email address cell.
    case kTelephoneNumberRow: // create telephone number cell.
}

And interacting with cells is handled similarly:

// - tableView:didSelectRowAtIndexPath pseudocode.

switch (indexPath.row) {
    case kNameRow: // do name-specific stuff.
    case kGenderRow: // do gender-specific stuff.
    case kJobTypeRow: // do job type-specific stuff.
    case kLevelOfExerciseRow: // do level of exercise-specific stuff.
    case kEmailAddressRow: // do email address-specific stuff.
    case kTelephoneNumberRow: // do telephone number-specific stuff.
}

This seems hugely unwieldy, and has the added of problem of not working when the table is broken down into multiple sections.

Is there a better way to do this? Are there any design patterns I would benefit from using when working with big tables of largely unrelated data?

Any tips at all are hugely appreciated.

Answer 1

I've become fond of implementing section controllers that pull the logic out of you UITableViewController subclass (or other hosting controller) and move them into self-contained classes.

I ended up implementing a base protocol that defines what a section controller needs to do - for me, that includes the number of rows in a section and a cell for the row (don't need the whole index path since the controller deals with a single section). I've got optional method for returning a section name and row height. That's all I've implemented so far since that's all I've actually needed.

It works for me because my individual sections tend to be homogeneous, but you could easily use the idea to return heterogeneous cells within the same section or refactor the idea to have cell type controllers instead of section controllers. In the end, my UITableViewDelegate and UITableViewDataSource methods just need to figure out which section controller to call instead of embedded all the logic within the UITableViewController subclass.

I think I got the idea from this article, but I also saw a more recent article that describes the same idea.