

Building an Open, Drop-in Replacement for UITableView - wastedbrains
https://techblog.livingsocial.com/blog/2013/12/02/lsctableview-building-an-open/

======
bengotow
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.

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.

------
prewett
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.

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.

~~~
joshavant
In iOS, sometimes the line between view and controller gets blurred.

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.

------
brendanlim
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.

~~~
joshavant
Hi! Post author here.

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.

~~~
vonseel
I am an iOS beginner.

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.

~~~
girvo
The OP didn't reimplement it to use it, it was done to explain. that's what I
got out of it anyway.

------
kurtle
"It relies on a relatively unusual API design – delegates..."

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

~~~
markrickert
Correct - UICollectionView also uses delegates, dataSources, and reusable
cells.

------
yesimahuman
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!

~~~
joshavant
Thanks! Very glad to hear that!

I suspected most of the concepts could be pretty easily applied to other
languages, so I'm especially glad to hear this feedback.

------
perishabledave
Mike Ash did something similar on his Friday Q&A posts:
[http://www.mikeash.com/pyblog/friday-qa-2013-02-22-lets-
buil...](http://www.mikeash.com/pyblog/friday-qa-2013-02-22-lets-build-
uitableview.html)

~~~
ocrickard
Yeah, I was thinking the same thing. Loved that blog post, and certainly
enjoyed looking at R. Nystrom's implementation too:
[https://github.com/rnystrom/RNTableView](https://github.com/rnystrom/RNTableView).

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.

