UITableViewDataSource protocol


#1

I’d just like to verify an assumption I’m making. I’ve scoured through the chapter, and checked the developer docs. Generically speaking, is it accurate to say that a protocol’s required methods will be automatically executed upon instantiation of the object?

Specifically, I’m in chapter 10, on page 150, and there is no place in the code where I explicitly call the 2 required methods of UITableViewDataSource, yet they are magically being executed. Seems obvious, but I just want to someone to confirm that is what is really happening. So that in the future, if I look up a different class object and it conforms to a different protocol, I will know that if it lists methods as “required” that also implies they will be auto executed upon instantiation.

Are these “required” methods executed as a result of (or following) the init method?

So, essentially, what the protocol does, without direction from me, is execute 1 time the method tableView: numberOfRowsInSection. Uses that (integer) return value to loop thru the execution of tableView: cellForRowAtIndexPath, and by the way, converts the integer value into an NSIndexPath object while doing so. The tableView argument for both methods is available as a property from the class object.

That sound about right?


#2

The only assumption you can make about a protocol’s required methods is that they will be called. When they are called is specific to that class.

In the case of a UITableView, most of its required delegate/datasource methods are invoked when it is sent the message reloadData. It just so happens that shortly after the instantiation of a UITableView (in this app) the table view is added to the window’s view hierarchy, which in turn triggers the message reloadData being sent.

reloadData is sent to a table view more than once during its lifetime, usually when you have changed the data that the table view displays.

Another example is the NSCoding protocol which you will cover shortly. The two methods initWithCoder: and encodeWithCoder: are both required and are sent when the object is being loaded from disk or saved to disk, respectively.


#3

Thanks Joe. Great job on the book, btw. It’s well written and immensely helpful. Also, I’m sure you have a lot going on so I do appreciate that you still take the time to keep up with this forum.

My frustration so far with table views is that the developer docs just really aren’t that helpful. I finally accidentally strayed into a link to “Table View Programming Guide for iPhone OS”. Even that’s a bit obtuse but I did discover the relationship you mention with reloadData. There are so many things happening automatically, and there doesn’t seem to be a concise reference that makes it easy to understand. Your book is great, but I’m trying to learn how to be more self sufficient, and I just wish there was better reference material than the dev docs.

I’m so new to OOP and most everything until now has involved objects that sit idly by until they are messaged. Table views are the first place where so many things are happening behind the scenes. I’m making a painful effort to understand every single line of code I type and try not to gloss over it and assume I understand it, my chapter 11 forum post on headerView being a prime example.

Thanks for your help.


#4

The Apple docs are pretty ugly sometimes. They usually have all the information, but are more or less just a “mind dump” without any real emphasis or organization. (This is fine with me, as it keeps me employed. :slight_smile:

One thing I’ve found is that after reading the programming guide for a given concept and rummaging through the API reference, sometimes I just need to play with the code a bit.

There is the “get it done” approach: start off with something small you want to do that isn’t straightforward. This forces you to try out different things which will eventually give you insight to how the whole thing comes together. (As an example/challenge, try and get a table view to display a few sections that each contain one row. When that row is selected, display 3 more rows underneath it with some options. When an option is chosen, revert back to the one row per section view.)

Then there is the academic approach: implement every delegate/data source method and put an NSLog in there (you can print out the name of a method from within that method by using NSLog(@"%@", NSStringFromSelector(_cmd));). Send the table view different messages and watch what happens.

I prefer the “get it done” approach, but that is just me. At the end of the day, the more time you spend with it, the more time you spend barreling through problems to get the desired effect, the more the pieces will fall together.


#5

I started out thinking, “boy these Apple docs are great! They cover everything!” And they do… but they make more sense to me after having learned enough to use them first. It’s top quality docs and technical writing, compared to many other languages and products. But it’s a lot to get your mind around.

I’d like to mention another resource, if I may: the Stanford iPhone development class available through iTunes U. I have been working this in tandem with Joe’s book. Lecture 8 covers table views. If you’re new to OO, you might find it helpful to start at the beginning, as Objective-C is introduced and MVC concepts are covered as it goes along. (I think Lecture 7 goes into MVC.) The programming assignments provide a nice complement to those in Joe’s book: the “get to it” approach, I guess. You might try Lecture 8 in any case because it walks through the elements that make up a table view. The slides are also available if you want to preview it that way.

And another kudos to Joe. I haven’t thanked you yet for your time, but let me add to Ken’s appreciation. I also like the high physical quality of the book. Good paper and nice clean design. Although I tend to leave it home due to its size – hence the handy portability of videos on my iPhone. :wink: