cellForRowAtIndexPath Not Called


#1

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
is not being called.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
is being called (and returns 5).

Here is my project on github: github.com/RhysLindmark/Homepwner

In addition to fixing my actual bug, I’d like to fix my process. When you fix my problem, can you tell me your process for fixing the bug so that I can use it in the future?

Thanks!


#2

Looks like your BNRItemsViewController.m is missing the following (from page 170 of the book)

- (NSInteger) tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return [[[BNRItemStore sharedStore] allItems] count]; }

As for the process, I’m an aging developer :confused: but a noob with Objective-C and iOS. However, my understanding of the TableViewController is the following. When drawing a table the delegate is asked:

[ul]How many sections do I need - via numberOfSectionsInTableView:
How many rows in each section - via tableView: numberOfRowsInSection:
What data do I need in the cell - via tableView: cellForRowAtIndexPath: (called once for each row)[/ul]

The fact that the final method wasn’t called suggested the possibility that:

a) the wrong method had been implemented (which seems to be easily done in Xcode with so many methods with similar names)
b) the right method wasn’t being called (Captain Obvious, but bear with me here!)

I checked a) first in your code and it looked fine, so the question for b) then became

What could cause the method to not be called? You don’t have much control over the sequence of calls between iOS and your Table methods, so the next thing that came to mind was, maybe it is being called, but called zero times (if you follow me).

What could cause it to be called zero times? My next thought was that numberOfRowsInSection: contained an error that was causing nil (or zero) to be returned.

So, I dug into the code to see how that method had been implemented, and look for logic errors, typos etc. that might cause that. When I looked for the method, I couldn’t find it, so that would also explain a zero value.

Now, if you read this and point out you did, in fact, implement the method and I failed to see it, I will shuffle off quietly mumbling to myself about “too late in the evening, lack of caffeine ingestion” etc. etc.!! However, the debugging approach still holds true.


#3

codeartisan – I read and greatly enjoyed your process. Thanks for taking the time to lay it out for me (and for finding my stupid bug).

I think the higher-level process for me next time should be:

  1. Damn! Why isn’t my code working? This is so simple?
  2. Sleep on it. Come back in the morning and check out my code again. (Almost certainly I’ll find that I typed the wrong method and fix the bug right here.)
  3. Post on the internet for help.

#4

You are very welcome.

When I was a Computer Science undergrad back in the mid-80s I took a Software Engineering course. One of the little things I remember from the professor was him saying:

Good programming comes from experience. Experience comes from bad programming.

One of the (few) downsides of the way this book is written is that it is easy to miss a few lines of code as you work through a chapter. I know, because I am on Chapter 16 currently, and have already made that mistake twice! So I’m slowly getting that experience to make a me a good iOS programmer.

Definitely not a stupid mistake. It’s very easy to get too close a piece of code and not see what a fresh pair of eyes can pick out. One of the most valuable lessons I learned when I first started programming professionally was to have everything I wrote peer reviewed. It’s a great way to catch mistakes early, and it’s also a great way to learn from other developers. In this case, debugging your code helped to verify my understanding of TableViews and their Controllers and was actually a good learning experience for me too.