Live data from Hacker News

Building an Open, Drop-in Replacement for UITableView

techblog.livingsocial.com

11–18 of 18 posts

Re: Building an Open, Drop-in Replacement for UITableView

#11

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.

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, befo…

Here's to demystifying the internals of UITableView! Your tone seemed fine to me. Glad you geared it towards newer folks to iOS. I remember when I was first starting with iOS, one of the biggest questions I had on these things was "Why?". Luckily posts like this, and the treasure trove of Mike Ash's blog provide a clear understanding of both how the components in Cocoa work, and why they work that way.

Re: Building an Open, Drop-in Replacement for UITableView

#12

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!

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.

Re: Building an Open, Drop-in Replacement for UITableView

#13
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.

Re: Building an Open, Drop-in Replacement for UITableView

#14
post #8

Earlier quoted context omitted.

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, befo…

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…

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

Re: Building an Open, Drop-in Replacement for UITableView

#15

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!

Also check out how Android handles adapters for list views while you are at it - for both iOS and Android, you can efficiently recycle tagged views, so that if your table view has mixed types of data, you get the right recycled view.

Re: Building an Open, Drop-in Replacement for UITableView

#16
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.

Re: Building an Open, Drop-in Replacement for UITableView

#17
post #16

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 co…

[deleted]

Re: Building an Open, Drop-in Replacement for UITableView

#18
post #16

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 co…

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.

Post reply on HN