I'm pondering the merits of moving UITableViewDataSource method implementations out from the UIViewController subclass and into its own class to counter the _massive view controller tendency of iOS development.
The thinking is to move logic out of the view controller into an input controller-helper (e.g. UITableViewDelegate implementation class) and an output controller-helper (e.g. UITableViewDataSource implementation class). Then the view controller's responsibility is primarily for object ownership and managing navigation between view controller instances.
In this paradigm UITableViewDataSource implementation class drives the output of the program by vending out UITableViewCell instances. Thus it is supposed to know all there is about the data being displayed and how to display it (like picking the appropriate table view cell class and configuring it).
Furthermore UITableViewDelegate implementation class is more towards managing the input from the user, e.g. didSelectRowAtIndexPath:, etc. All seems to be good so far.
However several methods of UITableViewDelegate seems to be more appropriate to be present in UITableViewDataSource because it relates to view configuration:
... heightForRowAtIndexPath:... indentationLevelForRowAtIndexPath:... willDisplayCell: forRowAtIndexPath:
I'm wondering what's the reasoning between splitting data sources and delegates and how is the best way to split these input/output logic?
Aucun commentaire:
Enregistrer un commentaire