CODEWITHSUNDEEP
objective-ccocoa-touch
Piotr Czapla
Piotr Czapla

Reputation: 26542

Rationale for design of UITableViewDataSource

I'm designing an API interface for a magazine viewer. Something like iGizmo (for iPad). The view that displays a magazine is very similar to a TableView. As one can think about articles as sections and pages as cells.

Because of that I'd like to expose DataSource & Delegate in the same manner as UITableView does. However I'm not entirely sure why apple designed TableView delegate/DataSource in that way it always provide the TableView as parameter in each method.

I've tried to rationalize it and I didn't find any good excuse for such api design. I'm thinking about leaving out the tableView/magazineView parameter in my API.

Do you see any good reasons behind such API design?

Wouldn't it be easier and clearer to write methods like the one below?

– cellForRowAtIndexPath: 
– numberOfSections
– numberOfRowsInSection:
– sectionIndexTitles
– sectionForSectionIndexTitle:atIndex:
– titleForHeaderInSection:
– titleForFooterInSection:

Upvotes: 0

Views: 162

Answers (1)

John Parker
John Parker

Reputation: 54445

Interesting question. Whilst this is a guess, I suspect it's there so a single data source class can be the delegate for multiple table views with differing requirements. (i.e.: It can check the tableView that's provided and respond accordingly.)

As such, if you don't ever anticipate this requirement, you could most likely omit the equivalent parameter from your method signatures.

Then again, if it's at all possible that you might want to access the "calling" magazineView, you could just leave the parameter in there - it's not as if passing a pointer around is incredibly resource inefficient.

Upvotes: 2

Related Questions