Best layout for detail views with heterogeneous rows

Question

I've never seen a perfect layout strategy for detail views containing several heterogeneous rows, e.g., one row for name, one for address, one for email, one for age ..., just like the name editing view of Contacts, but more complex.

Obviously, it is a perfect "table" thing, and UITableView's group style is preferable to plain listing of rows (refer to the name editing view of Contacts).

However, UITableView is not flexible enough to handle the heterogeneity: the tableView:cellForRowAtIndexPath: method will be messed up with complex branches for different kinds of rows, like this:

switch (row) { 
    case kNameRowIndex: 
        nameField.text = name;
        break; 
    case kaddressRowIndex: 
        addressField.text = address;
        break; 
    case kEmailRowIndex: 
        emailField.text = email;
        break; 
    case kAgeRowIndex: 
        ageField.text = age;
        break;
    ...
    default:
}

This problem can be perfectly resolved if UITableView can be populated with static UITableViewCells in Interface Builder, which seems impossible, isn't it?

So what's best layout strategy for such detail views?

Answer 1

Make custom UITableViewCells for reusable sections of your layout and dequeue those when needed in tableView:cellForRowAtIndexPath:. If you don't want to use UITableView, use custom UIViews for each group of data you may need collecting, naming and organizing them appropriately: eg. UIAddressDetailsView - country, area, city, street, number, etc, UINameDetailsView - first name, last name, initials, addressing formula, etc, UIPasswordAndEMailView...

Answer 2

It's not at all impossible to layout static UITableViewCells in interface builder.

In your view controller you can set IBOutlets for the different cells you want to use. In the XIB file for your view controller, define UITableView cells that are not held in the main view and wire them to those outlets. When the view loads you will have custom UITableViewCells you can return.

The only tricky part is that if they are of varying heights make sure to implement heightForRowAtIndexPath: so that you can return the frame heights for the static cells.