[dep_b]

I call this "expert band-aid applying skills". I think UITableViewController is one of the worst designed parts of UIKit and it's always a way to gauge how good a developer's OO skills are if they can point out the problems with it or if they're just okay with it.

If you put the delegate and datasource in a separate file at least makes your controller look a lot cleaner but still there's still so much stuff going on in them that doesn't separate well. If you feel the need to add #pragma, categories and that kind of things to make your code more manageable the underlying code violates the single responsibility principle.

I tend to not use UITableView unless I need either the performance or I am using a lot of built in stuff and there's no fancy stuff going on. Having to know up front what the height will be of a yet to be rendered cell really leads to a lot of ugly code quickly. I will not use it if I simply want to repeat some items vertically.

[mariodiana]

So, when you do use a UITableViewController or a UITableView with a UIViewController, how do you partition the code?

[dep_b]

I try to refactor out as much code as possible. Ofcourse the protocols should be implemented separate from the Controller, that's the first step but the implemented methods themselves can be made as thin as possible as well.

For instance the height could be calculated a static function on the UITableViewCell implementation as I think that's the object that should deal with layout.

The headers and footers should be separate UIView implementations not something you build there. Methods that are associated with them then can use methods on those classes instead of inline code.

I think if the delegate / datasource classes implement a lot of methods you want to reduce them to 1-3 lines of code between the braces each so you get a complete overview of what each does within 1-2 screens of information.

You can also often reduce some plumbing code with: https://developer.apple.com/library/ios/documentation/CoreDa...