I'm following a UITableView tutorial and I've learned that the UITableView is a view object which doesn't handle the logic or data, it primarily the view or user interface. As I continued reading it says that the UITableView requires a "datasource". My question is this, is the datasource the program's logic?
IOS app development widely use Delegate design pattern. Almost all UIView have their own Delegate Protocol. Before understand UITableViewDelegate and UITableViewDatasource Protocol try to learn about Delegate design pattern.
If you work with UITableView you have to implement atleast 2 protocol in your ViewController.
1. UITableViewDelegate : The delegate of a UITableView object must adopt the UITableViewDelegate protocol. Optional methods of the protocol allow the delegate to manage selections, configure section headings and footers, help to delete and reorder cells, and perform other actions.
2. UITableViewDataSource: The UITableViewDataSource protocol is adopted by an object that mediates the application’s data model for a UITableView object. The data source provides the table-view object with the information it needs to construct and modify a table view.
Related
How to enable data prefetching when using the new Compositional Layout & DiffableDataSource?
Before, we can achieve this by conforming a custom data source object, like,
class CustomDataSource: NSObject, UICollectionViewDataSource, UICollectionViewDataSourcePrefetching
Now, the data source is the UICollectionViewDiffableDataSource, which only conforms to UICollectionViewDataSource.
One way is to extend it to conform to the prefetching protocol. However, due to the fact that it encapsulates protocol implementations of the DataSource into its higher level methods like snapshots and apply. I can't figure out how to extend it to conforms to the prefetching protocol.
Your implementation of UICollectionViewDataSourcePrefetching is set on a separate property of UICollectionView called prefetchDataSource. So you should not need to subclass UICollectionViewDiffableDataSource
https://developer.apple.com/documentation/uikit/uicollectionview/1771768-prefetchdatasource
I can confirm that prefetching works when using a UICollectionViewDiffableDataSource. You will need to cache your prefetched data somewhere, and then access it from your cellProvider (or UICollectionView.CellRegistration)
For example, if your view controller implements UICollectionViewDataSourcePrefetching then you may have a line where you assign it as the prefetchDataSource:
myCollectionView.prefetchDataSource = self
I have a UIViewController in my application that contains a UITableView. This tableView has a few different states for section 2. The rows in this section can vary by height, cell type and number of cells.
The way I used to handle this was one UIViewController with lots of different if-statements in the UITableViewDelegate and UITableViewDataSource. Now, after a while, this has given me quite a lengthy and complicated controller.
I thought about two possible routes to fix this. The first one would be different UITableViewDelegate and UITableViewDataSource classes, based on an if-statement. The other would be to load in a different UITableViewController for each of the possible states.
What do you guys think would be the cleanest solution? Or are there any other cleaner solutions?
Firstly create an extension for viewcontroller which confirms to tableView dataSource and delegate protocols.
To achieve this we can create a custom method in presenter class to handle all this code and call this method whenever required.
I found a question in a quiz is "Which UIKit protocol contains the method –tableView:heightForRowAtIndexPath:?"
without taking any load the protocol comes in my mind was UITableViewDataSource. But when I checked apple developer documentation, I found I was wrong. UITableViewDelegate is the protocol who contain that method.
Before that I understood was that these height methods are part of Datasource protocol.
Is there any specific reason of placing them in UITableViewDelegate instead of UITableViewDataSource ?
Why following function are placed in UITableViewDelegate
heightForRowAt indexPath
heightForHeaderInSection
heightForFooterInSection
and Why following function are placed in UITableViewDataSource
numberOfSectionsInTableView
numberOfRowsInSection
Before now I thought these are similar type of function so these methods must be placed in same protocol.
Please make this clear to me.
Thanks in advance
UITableViewDelegate means you provide answers to requests about the layout of the table and about actions the user performs on the tableview.
UITableViewDatasource means you provide data for the sections and rows of a table and you act on messages that change a table's data.
For more in details, Check DataSource and Delegate
numberOfSectionsInTableView and numberOfRowsInSection are functions that answer questions about the data to be displayed which is why they are to be found in the DataSource protocol.
The heightFor... functions don’t answer anything about the underlying data but only on the way the data is displayed. This is why they are part of the Delegate protocol.
Does that make sense to you?
The datasource supplies the data, the delegate supplies the behavior.
In MVC, datasource is in the model layer and the delegate is in the control layer.
Actually, on second thought, the datasource is usually controller that is lower down, closer to the model. I don't think I've ever used a model object as my datasource.
The UI prospects of the UITableView are provided by the UITableViewDelgate methods and the data (we are not talking about the data to be used inside the cell, just the information about UI (section, row, etc.) repetitions) needed to construct the UI is provided by UITableViewDataSource methods.
Why is tableView:canMoveRowAtIndexPath: is UITableViewDataSource protocol and not in UITableViewDelegate protocol?
Similar methods (e.g. tableView:canFocusRowAtIndexPath:) are in Delegate protocol. I don't think it's a mistake, so can anyone explain why such method is part of the data source and not the delegate?
A general explanation of which methods belong to data source protocols and which belong to delegate protocols is also appreciated.
The delegate methods generally have to do with the appearance of the table view.
The data source methods generally have to do with the content of the table view. It's often the case that the displayed content's order is fixed. Say the table view was displaying stops on a bus line, or the chapter headings of a book. You can't let the user reorder those: it isn't something that the content itself supports.
Notice that both delegate and data source are actually involved in the decision as to whether a row can move. The data source gets the method you named, but the delegate gets asked tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath: at the same time.
The UITableViewDatasource protocol documentation:
The UITableViewDataSource protocol is adopted by an object that
mediates the application’s data model for a UITableView object. The
data source provides the table-view object with the information it
needs to construct and modify a table view.
As a representative of the data model, the data source supplies
minimal information about the table view’s appearance. The table-view
object’s delegate—an object adopting the UITableViewDelegate
protocol—provides that information.
The required methods of the protocol provide the cells to be displayed
by the table-view as well as inform the UITableView object about the
number of sections and the number of rows in each section. The data
source may implement optional methods to configure various aspects of
the table view and to insert, delete, and reorder rows.
Hope, that clears things out.
EDIT: With my own words (but repeating the docs): Datasource declares methods those somehow directly or indirectly affect/reflect the data model, whereas the method tableView:canFocusRowAtIndexPath: can't be said similar to tableView:canMoveRowAtIndexPath: because it has nothing to do with the data. That said, datasource carries constructive character, delegate - informative.
In my iOS app I have a view controller and a UITableView subclass on one of my views. Currently the UITableView manages it's own data (creating connections, and being the delegate which handles the callbacks).
I was wondering if this is best practice? Is it better to run this on the view controller and then pass the data into the table? Does this not matter at all?
Please explain the reasons in addition to answering my question.
Thanks!
It would be more standard to implement the delegate and dataSource methods in the ViewController.
It is quite unusual to subclass the UI*View classes, except to customise drawing. UITableViewCell is a bit of an exception to this rule.
If you find your ViewController getting a bit big you might think about implementing the delegate and dataSource in a separate class.
In addition to mcfedr's answer, views are things that interact with user and it is generally good to separate concepts (unless unavoidable). Also note that historic versions of ios (iirc) view controllers may load/unload views on demand, so any application logic in there may cease to exist.
In this scenario, I generally have only one class... The UIViewController instance that contains the following view hierarchy:
view -> myTableView
With this approach, my UIViewController will:
Have an IBOutlet to a UITableView (myTableView)
Implement methods of UITableViewDelegate
Implement methods of UITableViewDatasource
Set myTableVIew.delegate to self
Set myTableView.datasource to self
When the host UIViewController is the delegate and datasource of your UIViewContoller, all code can exist in one class. This keeps the code of your project tighter but does tightly couple your logic.
The alternative approach would be to subclass UITableView and implement UITableViewDelegate and UITableViewDatasource. This will be a desirable approach if:
You wanted to reuse the UITableView in multiple UIViewController
You wanted to encapsulate the UITableView logic from the UIViewController
Here is the thought process I use:
Am I going to reuse this UITableView and its logic?
Yes -> UIViewController class and UITableView subclass
No -> UIViewController class only
The best practice would depend on the number of programmers involved, the repeatability of the UITableView, coding patterns already established. This is often a matter of preference and I hope my answer shed some light on why you would go either way,