Overall this is a great article. It does a good job outlining what UITableView does and why it's built the way it is. If you're new to iOS and wondering why UITableView's delegate and dataSource protocols are structured the way they are, it's a good idea to take a deep dive and understand them better. As others have mentioned, data sources and delegates aren't unusual in Objective-C. They're everywhere, and they enforce a separation of view logic and data that is at the heart of MVC.<p>This is a great exercise, but please, please don't use your hand-rolled UITableView in your apps.<p>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.
Is it just me, or does it seem like UITableView is a combination of controller and view? The delegate has both controller functionality (selection) and view functionality (cell height). I keep trying to use it as one or the other and you just can't do it.<p>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.
Nice job creating your own implementation of UITableView. Although, if you find delegates and datasources unusual then its best for you to spend more time getting familiar with them rather than trying to work around them.
"It relies on a relatively unusual API design – delegates..."<p>Nothing unusual about delegates, the entire iOS codebase is littered with them.<p>But kudos on doing what we all eventually think about doing, the longer we work with UITableView
Funny, this was actually really helpful for me as I'm building a dynamic list (or "table" in iOS parlance) for HTML5 in Ionic Framework. Gave me a few ideas on how we could structure the API to handle tons of items efficiently. Great write up!
Mike Ash did something similar on his Friday Q&A posts: <a href="http://www.mikeash.com/pyblog/friday-qa-2013-02-22-lets-build-uitableview.html" rel="nofollow">http://www.mikeash.com/pyblog/friday-qa-2013-02-22-lets-buil...</a>