You’ll Never Believe What UICollectionView Can Teach Us About Code Design
By: Avi Tsadok
Tags: Computer Science, Uicollectionview, iOS, Xcode, Swift

You’ll Never Believe What UICollectionView Can Teach Us About Code Design

UICollectionView and UIViewControllerTransitionDelegate can teach us a lot on how to design a significant separation in our code Avi Tsadok Follow Dec 18, 2020 · 3 min read

Introduction

UICollectionView and UIViewControllerTransitionDelegate are with us for a long time already. Both of them solved some critical issues iOS development had with flexibility and customization of user experience.

What’s more interesting is that both of them provide a great example of how to create a flexible design pattern that lets us do almost anything we can imagine

To understand that, we need to go back many years in history.

How many years? Well, we’re talking about the year 2012. In terms of mobile development, it means ancient history.

The only collection UI element we, iOS developers, had, is UITableView.

UITableView is an excellent component that helps us display a list of items. But one of the most requested components developers wanted is the ability to display a grid of items, or at least show them vertically.

But instead of providing an option for the UITableView to be vertical, Apple gave us UICollectionView, which delegates the layout logic to the developer and let him choose what to do with it.

And why is that impressive or “dramatic”? Let’s see.

Separation of Concern

We all know the SOC (Separation of Concern) principal. We always talk about it when discussing design patterns (especially in job interviews  ).

However, we don’t always follow this principle and deeply understand what it means and why it is essential.

Let’s see the list of responsibilities a component such as UICollectionView has:

- The mechanism of adding and removing cells as part of recycling them.

- Providing cells.

- Providing decoration views.

- Handling touches and other user events.

- Handling layout (any kind of layout) calculations.

Wow, that’s a lot of responsibilities for the little component that could!

If you look closely, you could see that any one of these responsibilities belongs to a different object/part.

Adding and removing cells is the collection view responsibility.

Providing cells is part of its data source.

The decoration is set from outside, touches and other user events are part of the collection view delegate.

And the layout is part of its UICollectionViewLayout (Most of the time, flow layout).

And the last one is the key.

In UITableView, the layout responsibility was part of the table view itself.

Taking it out in UICollectionView was a dramatic move by Apple that gave us, the developers, an opportunity to create whatever layout we want.

They also did it in UIViewControllerTransitionDelegate

Indeed.

We all know UIViewController is a weird creature. Its role in MVC is awkward, and over the years, all of us became masters with finding ways to reduce its bloated size (MVC — “Monster” View Controller).

The problem is on the wall — UIViewController contains lots of different responsibilities, some of them are not related to each other at all in any way.

So, it’s not a coincidence Apple decided at one point to remove the presentation transition logic outside the view controller and to give us the option to customize it the way we want.

And that leads us to another thing we can learn from SOC (Again, “Separation of Concern”, you should remember that already) –

When we separate our concerns into different components, it gives us the option to create an interface for other developers to take our great code and adapt it quickly to their needs.

It is true when creating a library or SDK, but it also true for our own project when we want to modify it later to our needs.

Let’s Summarize

SOC (look above what it means, I’m not going to tell you) is important, but to truly understand why I gave UICollectionView as a good example.

I think UICollectionView is a remarkable piece of design. It really pronounces what a good API should look like, and personally, I have learned a lot from it over the years.

Separation of concerns helps us maintain our different components easily, delegate behaviors to other objects, and provides flexibility and robust code.

It is an excellent way to test our code easily when we can test each component differently.

Also, SOC creates smaller pieces of code and, by that, helps us debug our code easily.

It’s not that anything Apple does in their SDK’s is amazingly designed (I mentioned UIViewController earlier), but if we can learn from the good parts, why not?