Dealing with different kinds of cells in Swift — Part 1 of 3

Every iOS developer in the world has had to deal with collections of data. Whether you choose to use a UITableView or a UICollectionView, the same problem arises when you have to use different kinds of cells at the same time. If you follow Apple’s code examples, you might end up with something like this:

That is already messy and hard to read with just three types of cells and cell-related code only, also notice the same ‘if’ statement in several places.

Add additional View Controller code and more table view delegate or data source methods and you will end up with a very hard to maintain class. Also, this approach doesn’t scale well, because the moment we need to add more types of cells, the methods will keep growing, making it even harder to read and follow.

Cell Controllers to the rescue!

So what is a Cell Controller? It is an abstraction that will help us encapsulate everything related with the particulars of any given cell, i.e., its configuration and handling of events related to it.

And how do we encapsulate such things? Easy! Let’s start with a protocol:

This protocol covers all interactions used in the previous example. As you can imagine, we can do something similar for a UICollectionView as well. It would look like this:

These protocols will allow us to create an effective abstraction. Let’s see it with an example. If we want to implement it for the photo cell, the code would be something like this:

As you can see, we have moved all the code related with the photo cell, and only the photo cell, to this entity. Sweet!

Once we have an implementation of our Cell Controllers for each cell, we need to start using it in our View Controller. So let’s get on with it!

The Factory pattern

The most effective way to incorporate the Cell Controllers in the View Controller is using the Factory pattern.

This pattern will help us encapsulate the specifics of creating and registering Cell Controllers so that the View Controller is isolated from them. Here is a possible implementation of this pattern for our case:

In this very simple way we will be able to move the ‘if’ statement inside the factory, removing it from the View Controller and avoiding repeating it.

The View Controller

And how does our View Controller look like now? You will see that now is very simple and concise:

Have you noticed? There is no specific code for any cell, no ‘if’s, no mess. Everything is handled inside the Cell Controllers so the View Controller doesn’t even need to know what is going on.

This has an additional benefit. If we need to add a new cell, we just need to implement its Cell Controller and add it to the Factory, without touching a single line of code of the View Controller (following the Open-Closed principle of SOLID).

This example is a very simple implementation of the Cell Controllers. We can expand it by adding more cell-related methods to the protocol to cover other UITableViewDelegate or UITableViewDataSource methods.

As you can see, using Cell Controllers save us lots of lines in our View Controllers, improving the readability, scalability and maintainability of our projects.

Now that you know this simple technique, you can start using it right away! In the following posts we will see how to write less and less code using some cool Swift features. Stay tuned!

I hope you enjoyed the post! And if this sounds great, you’d like to progress in your tech career, and you’ve got a love for learning languages (tech or otherwise!), we’ve got lots of open roles in our Tech team!