This is a great exercise, but please, please don't use your hand-rolled UITableView in your apps.
If UITableView doesn't do what you need, create a UICollectionView. If you find the data source protocol frustrating to use, create a provider object that maps your (array/dictionary/weird-ass data structure) onto the dataSource protocol. (In desktop Mac programming, NSArrayControllers serve this purpose.) Don't re-implement UITableView. The things you could potentially screw up are many, and when some other developer inherits your code and tries to add editing, multiple selection, re-ordering, etc..., they're going to be pissed.
Although, my view of MVC is that the model is just the data (pretty lightweight), the view just draws the things, and the controller handles user actions. So you could remove the view and do testing on the controller. This doesn't seem to be Apple's perspective, so maybe I just haven't figured out their perspective yet.
UIViewController is part of UIKit. UIKit is a framework developed specifically for iOS as a high-level wrapper over OpenGL, for performance reasons as well as making touch screen based interfaces easier to implement.
This is why UIViewController has many view-related hooks in it. For example, the native view lifecycle flow includes a call to the method `viewDidLoad` on UIViewController - a controller method dedicated to view functionality and customization.
That said, the UITableViewDelegate seems to have the standard amount of view and controller commingling that's found throughout the common iOS frameworks, IMO.
Totally agree with that last statement.
That said, I tried to write the post to be geared towards the beginner audience. And I remember when I first started iOS development, UITableView seemed weird.
It comes with two delegate objects with separate responsibilities (delegate and dataSource) and is pretty ubiquitous, so you may interact with it right away when first starting iOS development, before interacting with the many other classes that use delegates (and the, what, 3 others that use dataSources).
To a beginner, that tends to make UITableView stand out as an unusual thing.
I'm hoping pulling UITableView apart, and explaining the machinery can help make those design decisions more clear.
I have not read your post in-depth, I will, but I think it's probably wise to stick to learning UITableView well -- and understanding why I would want to implement something custom -- before avoiding the classes Apple provides.
That being said, I understood delegates, categories, and other Objective-C features much better after coding several applications first, reading a ton of open source code, and then reading relevant parts of Programming in Objective-C (Kochan). I first purchased his book before attempting to code for iOS, and found the pace too slow or concepts too unfamiliar, but after some practice and finding what I did not understand, it is much easier to look to documentation and textbooks for appropriate reference.
Nothing unusual about delegates, the entire iOS codebase is littered with them.
But kudos on doing what we all eventually think about doing, the longer we work with UITableView
I suspected most of the concepts could be pretty easily applied to other languages, so I'm especially glad to hear this feedback.
UITableView is one of those components that we all spend so much time with that everyone has little tweaks they want to make. Implementations like these at least give us options to extend/tweak low level behavior should we need to. I also love it when they write thorough blog posts like these explaining explicitly their rationale and structure of the component.
