Things are so different today

Pardon me for a moment while I put on my “old fart programmer” hat.

While doing development these days, there’s no question Internet access is critical to success and fast turnaround.

Back in my early days, we had books, user groups (you know, people actually coming together in the same physical and geographical room and talking face to face), and at best there was USENET newsgroups. Once DejaNews came along to archive newsgroups, that was most useful towards finding information because you know someone asked about it before. Then mailing lists started to become more centralized, such as Apple actually hosting a majority of mailing lists dedicated to their topics (developer, administration, etc.). Those lists along with their archives was a growing source of reference. Again, because you know someone asked the question before or encountered the problem before.

Forums have been useful, and then new things like stackoverflow.com and github have proven to be invaluable. I punch into Google a programming question, and SO and GH come up in the top all the time. Someone’s dealt with the same problem, or someone has posted code to it. Heck, I remember WAY back in my Metrowerks days having the PowerPlant Contributed Class Archive, where other PowerPlant developers would contribute C++ classes to Metrowerks to host in the CCA for the convenience and use of other PP developers. I contributed a good bit of code to that. I haven’t done the same with my Cocoa and Cocoa Touch work, but sooner or later that will be remedied.

It’s just wonderful tho how far things have come. It used to be so difficult to find things, and many times you were the one that got to scout out the problem and share the answer. Now, chances are good others have come before you and willing shared their information. The community has grown, both in numbers and in giving spirit.

Such a wonderful time to be a developer. You kids don’t know how good you have it.

Almost there…

It’s gratifying to get to the point in developing an app when you can log into iTunes Connect (the developer “back end” for the iTunes App Store) to get the initial app setup in place.

Yes, new app coming soon. A few more details on my end, waiting for some artwork… so, hopefully soon!

-[UITableView dequeueReusableCellWithIdentifier:], Storyboard, and VoiceOver – doesn’t work

I’m starting to explore the iOS Accessibility support, specifically VoiceOver.

As I was working, it was frustrating to see my app constantly crashing every time a UITableView would try to come up. Not really a crash, but a failed assertion. It’d look something like:

‘UITableView dataSource must return a cell from tableView:cellForRowAtIndexPath:’

Thing is, I was returning a non-nil cell. Or so I thought.

This app is using iOS 5 and Xcode 4.2′s new UI-designer feature, Storyboard. One thing I really like about Storyboard is the built-in support for making UITableView’s right within the .storyboard file. In this particular case, the UITableView was using a single prototype cell. Apple’s “Converting to Storyboard Release Notes” notes a specific change for -tableView:cellForRowAtIndexPath: about how to handle -dequeueReusableCellWithIdentifier:.

The dequeueReusableCellWithIdentifier: method is guaranteed to return a cell (provided that you have defined a cell with the given identifier). Thus there is no need to use the “check the return value of the method” pattern as was the case in the previous typical implementation of tableView:cellForRowAtIndexPath:. Instead of:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];
}
// Configure and return the cell.

you would now write just:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
// Configure and return the cell.


This is a welcome change, and it makes sense. Since you have a storyboard, since you are providing the prototype cell, the table should always get a cell for reuse. The only reason you had to do the nil check was to create the cell in the first place, if there wasn’t one for reuse.

I’m following the new paradigm, I expected to never get nil, but in fact I was.

But I was only getting nil when I was running with VoiceOver.

Turn VoiceOver on, fail. Turn VoiceOver off, no fail.

I can only think VoiceOver is somehow involved.

I have submitted a bug to Apple, rdar://problem/10810435. From searching around, it seems others have experienced and reported this as well. One report I saw reported against an iOS 5.1 beta, which doesn’t make me happy. I’d like to hope this would be fixed in the next iOS update.

But, we can work around it for now.

The UITableView in the .storyboard doesn’t have any cells, static nor prototype. The UITableViewCell resides in a lone .xib file and is loaded on demand. This is the same technique discussed in Apple’s “Table View Programming Guide for iOS” in the section discussing how to customize cells, Loading Custom Table-View Cells From Nib Files, The Technique for Dynamic Row Content. Just do that, seems to be working fine.