Table Views in iOS — A beginner’s guide (Part One)
Fear me not!
I once thought that creating a simple to do list app wouldn’t be too difficult, I mean it is just a mere table that stores data, right? I turned open a beginner’s guide book and I got a big slap in the face, coding a to do list app is an art of its own, and requires a deep understanding of how objects communicate with each other (protocols, delegates, etc).
If you ever own an iPhone, table views are pretty much everywhere, they are in your contacts, music selection menu, photo albums, you name it. Therefore, it is important for beginners to master this skill and all the knowledge gained from it will be transferable to other types of app developments
In this guide I will talk about UITableView at a very top level and work our way down to the code. I believe you need to understand the overall picture first in order to tame this beast.
Oh man! not another article on MVC again! But bear with me guys, you need to need how the model, view and the controller layers communicate with each other before you can truly grasp this beast.
You see, the reason why MVC is such a prominent software architectural pattern is because it promotes code re-usability and a concept of separation of concern.
Think of it like this, the controller is the middle man between the model and the view. Your goal as a controller is to map or represent the model visually in the view layer without the view layer acknowledging the model layer. The important take away from this section is the controller directly communicates between the view and the model, you can learn more on MVC from my other blog here.
UITableViewDatasource and UITableViewDelegate
As I was a beginner starting out, I have always wondered what the heck are those in the class declaration line, but what ARE they and why we need it and what is it doing.
Well in order to explain this, I want to tell you a story first, a story that will tie everything together and trust me it will make things a lot more clearer. At this point let’s just ignore the code for now and I’ll bring it all back in the final section.
Think of the
UITableView is a person who is called “Tim”. Now, Tim is a very lazy person and he doesn’t like to do any work whatsoever and he needs to have everything handed to him to do his job, and that job is to display data in a list, a table view. Thankfully, Tim has special helps that goes out to the world (you controller) and get the data Tim needs to get the job done (conforming to the
The Data source and delegate specializes in different things and their roles is what gives Tim its functionalities and to display data and interact with the end user.
Before we continue, let discuss more about Tim’s helpers, Data source is responsible for reporting information about the data to Tim, such information would be how many items need to be displayed? how should the items be displayed? how many section should there be? just everything about the data and nothing else. Therefore, you don’t really need delegate because the data source is all you need if you just want to display information on the table view.
But, what about the delegate? remember that data source is responsible for the data side? Well, the delegate is responsible for managing user’s actions and the “feel” of the table view. The delegate answers the question: “What should happen if a user touches a row?”, “What should once the data is displayed?” it is a helper a signals to you what the user is doing to the table view and act accordingly using the methods defined in the protocol.
Bringing it back!
This delegate helper thing really ties back to the fundamental MVC structure gives the delegate its purpose in life. You see, views in iOS (a table view is a subclass of
UIView) should and only should display data, nothing else, period.
However, what if the views want to communicate back to the controller? why do views want to do that you might ask? Well, take the setting menu on your iPhone for example, that is made possible with a
UITableView and each row is properly populated (tongue twister there) thanks to our helper
UITableViewDatasource. As you tap the rows, it segues into another
UITableView, thanks to the
UITableViewDelegate by letting you know “Hey, the user has tapped on one of the row, what do you want to do?”
One very important thing to keep in mind is that you know all those methods in the protocols? you do not call them yourself, you simple conform to it and the system will call them when the time is right, like for example the method
func tableView(UITableView, didSelectRowAt: IndexPath) will be called when the user tapped on a row in the table view. Again, you do not call the protocol methods, the system does.
Thanks for reading I hope you can take something away from this. Stay tuned to my part two as I dive deeper in this topic and demonstrate the concepts in Xcode!
Leave a comment if you are confused and follow me to get notified of upcoming swift related blogs!