It’s hard to imagine even one iOS application that doesn’t use a UITableView or UICollectionView. Therefore, quite often it becomes necessary to implement dataSource. This article will introduce the idea of dataSource modeling to simplify handling table or collection events and improve code readability.
Let me leave a little digression. As an example, a profile screen of the following type will be developed.
And the source code of the project can be found at
Contribute to AceRodstin/EditTableView development by creating an account on GitHub.
Let’s imagine that a section is some entity that contains information about the kinds and number of cells. At the same time, the sections differ from each other and there may be a different number of them, so it would be convenient to store information about the section kind in the same entity. Therefore, an object with the following API will be needed.
Pay attention to the implementation of the SectionProtocol and Hashable protocols.
First, the information about the sections will be stored in the [Section] array of either the UIViewController or the class that implements the dataSource. And since cells can change their order, be deleted, added, etc., it would be convenient to have methods that simplify access to a specific section, knowing its kind. And to a specific cell, also knowing its kind.
Secondly, at this point in time, there are two approaches to implementing the dataSource — the UITableViewDataSource protocol and the UITableViewDiffableDataSource object. To be able to use the second, it is necessary that both the Section model and the Row model implement the Hashable protocol. Thus, the developer operates with a fairly readable syntax.
Creating (dequeue) cells
Perhaps the most convenient thing with this approach is creating cells. Knowing the kind of each cell as a case of the Row.Kind enumeration, you can use the switch statement.
The code is similar for UITableViewDataSource.
It is also worth paying attention to the use of section type information. For example, when creating headers, knowing what kind of section, you can also run the switch over the values of interest.
The rest of the delegate methods are similar. Knowing which section and cell kinds are being worked with, the developer programs the appropriate logic.
Adding or removing cells
Do not forget that the table can be dynamic and the number of cells in any of the sections can change. This situation in the given example is implemented in the form of adding and removing profile contacts.
For UITableViewDataSource, the code is almost the same, with the only difference that the performBatchUpdates method is used.
And then the minus of using this approach comes up. It is imperative to update the data model (profile) along with the dataSource model, otherwise errors are inevitable when working with the table.
In all other respects, the approach is the same. The developer also has the ability to implement a cell delegate in the same class and pass self as the delegate.
I am glad to present to the public a fresh idea for dataSource modeling. Let me wish you a good day, and that’s it.