Separate Your Concerns
Multiple Data Sources!
A UITableView object requires two other objects as its data source and delegate to perform. Data source object, which should conform to UITableViewDataSource protocol, provides data for populating and information about data structure for table view objects. For this matter, there are two methods in UITableViewDataSource protocol,
In addition to data and its structure, configuration of table view objects is also determined by data sources. For example, whether or not table rows can be edited or deleted and if table rows can be reordered (UITableViewDataSource Protocol Reference 2010). A table-view object may need to act or be presented differently under certain circumstances. The argument here is having multiple data source objects which table-view object can switch to in different situations instead of having multiple table-view objects, or one table-view instance having a single data source with complicated controlling structures for various situations.
One situation when a single table view object with multiple data sources can come in handy is showing different data in similar formats. Imagine a twitter app in which tweets are categorized into 3 groups: re-tweets, mentions and home. Every type of tweet can be loaded into one data source and the table view switches among data sources when user wants to. It certainly does not make much sense implementing 3 table views. The reason for this is the fact that, every change, major or minor, in the way tweets are shown, should be applied on 3 table view objects. A multiple data sources design obviously needs less effort in this case. The diagram below shows how this design works in MVC.
Depending on the number of rows, a table-view object might have to present its data in different number of sections. In an application where dataset is to be provided from dynamic external sources like the web, the number of to be populated rows is not predefined. Therefore, the application should be ready to structure its table-view, during the runtime of the application, in ways suitable for the dataset it is encountering. It is simply achievable by having multiple data source objects prepared for different purposes, and defining the appropriate table-view data source as current data source when necessary. This design is also helpful in applications where users have the facility to change the appearance of their application, here particularly table-view objects, regardless of the amount of the data and the source from which the data is provided. In addition, situations when for instance the device rotates can be handled easily and effectively using the same approach. It can be a useful feature that an application represents its data in a table-view object differently depending on the device orientation.
Apart from the appearance of the data, the way in which table-view objects’ data should be treated in different situations is manageable via data sources. Following the design discussed above, there can be multiple data sources to allow users to edit, delete or to move rows of data in certain times; or prevent users from manipulating the data in some other times. This can be for reasons such as the origin of data or the stage at which the application is. For example, an application might provide its users with two states; one with the facility to change the order of the rows of a table-view object and the other where the content of the table-view object is frozen and cannot be changed.
Having a single UITableView object with multiple data sources in the scenarios discussed above, will lead to a smaller application that requires less memory in comparison to a design in which there are more than one UITableView objects, each of which being controlled by a separate data source. Moreover, it leads to having several objects as data sources, each of which simply responsible in one occasion. This is a lot clearer and easier to maintain than when all situations are handled in one data source that results in complicated controlling structure and an unreadable code.
cellForRowAtIndexPathand
numberOfRowsInSection, that data source objects are required to implement. Hence, it is compulsory for every table-view object to have a data source object. However a table-view object might not have a delegate as all the methods in UITableViewDataDelegate protocol are optional (Table View Programming Guide for iOS 2011).
In addition to data and its structure, configuration of table view objects is also determined by data sources. For example, whether or not table rows can be edited or deleted and if table rows can be reordered (UITableViewDataSource Protocol Reference 2010). A table-view object may need to act or be presented differently under certain circumstances. The argument here is having multiple data source objects which table-view object can switch to in different situations instead of having multiple table-view objects, or one table-view instance having a single data source with complicated controlling structures for various situations.
One situation when a single table view object with multiple data sources can come in handy is showing different data in similar formats. Imagine a twitter app in which tweets are categorized into 3 groups: re-tweets, mentions and home. Every type of tweet can be loaded into one data source and the table view switches among data sources when user wants to. It certainly does not make much sense implementing 3 table views. The reason for this is the fact that, every change, major or minor, in the way tweets are shown, should be applied on 3 table view objects. A multiple data sources design obviously needs less effort in this case. The diagram below shows how this design works in MVC.
Depending on the number of rows, a table-view object might have to present its data in different number of sections. In an application where dataset is to be provided from dynamic external sources like the web, the number of to be populated rows is not predefined. Therefore, the application should be ready to structure its table-view, during the runtime of the application, in ways suitable for the dataset it is encountering. It is simply achievable by having multiple data source objects prepared for different purposes, and defining the appropriate table-view data source as current data source when necessary. This design is also helpful in applications where users have the facility to change the appearance of their application, here particularly table-view objects, regardless of the amount of the data and the source from which the data is provided. In addition, situations when for instance the device rotates can be handled easily and effectively using the same approach. It can be a useful feature that an application represents its data in a table-view object differently depending on the device orientation.
Apart from the appearance of the data, the way in which table-view objects’ data should be treated in different situations is manageable via data sources. Following the design discussed above, there can be multiple data sources to allow users to edit, delete or to move rows of data in certain times; or prevent users from manipulating the data in some other times. This can be for reasons such as the origin of data or the stage at which the application is. For example, an application might provide its users with two states; one with the facility to change the order of the rows of a table-view object and the other where the content of the table-view object is frozen and cannot be changed.
Having a single UITableView object with multiple data sources in the scenarios discussed above, will lead to a smaller application that requires less memory in comparison to a design in which there are more than one UITableView objects, each of which being controlled by a separate data source. Moreover, it leads to having several objects as data sources, each of which simply responsible in one occasion. This is a lot clearer and easier to maintain than when all situations are handled in one data source that results in complicated controlling structure and an unreadable code.
References
- Table View Programming Guide for iOS 2011, Apple Inc., viewed 20 September 2011, <http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/TableView_iPhone/AboutTableViewsiPhone/AboutTableViewsiPhone.html#//apple_ref/doc/uid/TP40007451-CH1-SW1>.
- UITableViewDataSource Protocol Reference 2010, Apple Inc., viewed 20 September 2011, <http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UITableViewDataSource_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UITableViewDataSource>.
No comments:
Post a Comment