NSIndexPath for iPhone SDK: .row and .section

May 4, 2009 at 1:01 pm (iPhone development) (, , , , , , )

God, I really love/hate it when Apple, or any other framework & API developer, does shit like this.

Love it, because they do exactly what I want them to, they modify an old existing API with an arcane interface (NSIndexPath in this case) to provide convenient, direct access to what we really need as developers (in this case, the row and section of the UITableView).

Hate it, because they don’t document the new API in a reasonable way. Yes, it turns out that there is at least documentation in this case, but it wasn’t accessible in XCode, the way everything else is…I had to google the problem, and find someone else’s nice reference to the NSIndexPath UIKit Additions documentation. Now that I know it is there, I go back to XCode, and yup, I can find it. And it’s not totally un-obvious, but it’s just that one extra click away for me to have missed it the first time.

The API I’m very happy to have just learned about here, is 2 new accessors added to NSIndexPath by the iPhone SDK, .row and .section, which provide convenient access to the relevant information about a multi-section UITableView. If you do any development on the iPhone, you will at some point very quickly want to use a UITableView, and likely a multi-section variety. The plain one works fine for many cases, but sometimes a multi-section table provides a better or more natural organization.

The normal API for NSIndexPath is really lame, it’s basically an array of numbers, which are themselves indices into a tree of nested arrays. You can read all about it on your own time in XCode, have a blast. The row/section API, makes all the sense in the world, and it’s great to have it.

But please, oh god please, API and framework developers across the lands, make your documentation just as orthogonal as your API (or preferably, even more orthogonal). A poorly documented API is sometimes worse than no API at all (take, well, any API that Microsoft has written since the original win32 api. MFC will suffice. Had microsoft never bothered to release that abomination, no one would have been under the false impression that they could actually *use* the API to do something useful or efficiently, and would have just stuck to the ugly, but reliable, for windows anyway, win32 api) Apple’s API documentation is historically pretty questionable, and their API implementations are also similarly pretty questionable. As much as I love application development compared to web development, comparing the NS* API, on which most of the iPhone SDK is based, to something like Rails…the degree to which the iPhone API falls short is just sad. A part of me deep inside cries whenever I think about it.

But still, at the end of the day, I love to write iPhone applications, and I hope that business continues to allow me to fill my time with client work for iPhone apps. If you or anyone you know needs iPhone work, http://www.rcloudconsulting.com ftw.*

Thanks
R.

*ftw = for the win, meaning if you want the best iPhone developer in the world, that’s where you find him. Any resemblance to the author is strictly intentional.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: