Menu

Day 6 - Confusion

Sep 03, 2015 at 08:24 am, by Pierre Liard

I must have had a bad night because I had a hard time understanding the today's subject: Table View. A table view is very common on iOS devices, it displays a single column list of multiple rows which the user can scroll. This is easy enough, but things went very confusing for me as soon as the coding in the View Controller started.

The second line of the default code is written as so:

class ViewController: UIViewController { ... }

This means, simply said, that the class ViewController implements an interface UIViewController we don't know anything about. Think of an electrical switch: we don't know what is behind it, but we know certainly that switching it on or off will have for consequence to turn on or off some light or device. In coding parley, it means that the view controller has capabilities we can work with and that these are coming from an interface providing them. It is of course a concept coming from object oriented programing and it is pretty understandable without many explanations. Adding a new interface to work with the table view would seem to be the next logical step. Rob introduced however a new type called UITableViewDelegate.:

class ViewController: UIViewController, UITableViewDelegate { ... }

As the word "Delegate" implies it, this new type must somehow represent something else, in this case UITableView. What a delegate is exactly is nevertheless for now a partial enigma. Apple's developer library states only that the delegate of a UITableView object must adopt the UITableViewDelegate protocol. My assumption is that the table view dragged into the view controller is an object required to use the delegate to work properly. It would make sense, but I can only assume for now. Moreover the difference between an interface and a delegate seems blurred. In C#, delegates and interfaces have about the same functionalities, and a problem solved with a delegate can also be solved with an interface. If Swift and C# are similar on this point, an interface has only a single method, whereas a delegate defines multiple methods.

The latter hypothesis seems plausible because a 386 lines long list of functions and methods is revealed when clicking on it, after holding down command and hovering over UITableViewDelegate. Due to this list's large content, it is not a simple task to find what you are looking for, especially when you don't know exactly what you're searching for. It would be probably harrowing without somebody pointing at the right direction. Rob did just that by choosing two functions, but didn't really justify his selection. It was to me like something falling haphazardly from the sky. Why this one, and not that one? It's where it started to get really confusing. I am personally unable to learn something if I don't understand it. I grasped however that one function returns the number of rows of a table:

func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int { ... }

and that the second function defines the content of each individual cell and makes possible the display of images or of a customized cell layout:

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath)->UITableViewCell {...}

Note that both functions have near the brackets an -> followed by Int and UITableViewCell respectively. This indicates that the function expects a return of the type following the arrow.

The method UITableViewCell in the second function defines obviously a style, but the reuseIdentifier got me definitely bemused:

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
 
   let cell = UITableViewCell(style: UITableViewCellStyle.Default, reuseIdentifier: "Cell")
 
   cell.textLabel?.text = "Test"
 
   return cell
}

To understand what it is, it is necessary to go back a little; when the Table View is dragged from the library into the View Controller, Xcode's right panel shows a field for "Prototype Cells":

Protoype cells

Prototype cells can be used to create either a default or a customized layout of the Table View Cell. By selecting one prototype cell, it adds a cell to the table view and, when clicked, the right panel changes as well:

identifier

By giving a name to this identifier, it is possible to create a custom layout for a series of cells. Other customized layouts can be created by simply adding a new prototype cell. Back to our code, the "reuseIdentifier" named "Cell" will apply the same layout to the rows of the table view.

The next line adds text to the cells. In this case, the same text will be inserted for demonstration purposes, but an individual content can of course be injected in each singe cell. I won't demonstrate it here, but it is a common way to proceed. I couldn't understand nevertheless the necessity of the question mark in cell.textLabel?.text . Rob just said not to worry about it at the moment. It is exactly what turned me off in this tutorial. Coding is a logical process, and therefore each element has a meaning. I was able however to find a pretty limpid explanation of this question in the Apple developer library: You specify optional chaining by placing a question mark (?) after the optional value on which you wish to call a property, method or subscript if the optional is non-nil. This is very similar to placing an exclamation mark (!) after an optional value to force the unwrapping of its value. The main difference is that optional chaining fails gracefully when the optional is nil, whereas forced unwrapping triggers a runtime error when the optional is nil. In other words, if the cell in the Table View has no value, the application doesn't crash because the question mark specifies it is an optional value. Thus, if I am right, the exclamation marks necessary to unwrap variables might be replaced by question marks, avoiding consequently a total crash of the app. Interesting, isn't it?

If I try now to sum up this tutorial, it is a bit more comprehensible. When using a table view, it is necessary at first to inform the View Controller to refer to UItableViewDelegate, then to define how many rows are in a specific section of the table (I have voluntarily overlooked the notion of section for simplicity sake), to add a style and a template for the selected cells, finally to write the text "test" in each cell and to return it to the table view.

When you start learning Swift 2, it is probably acceptable to memorize a few functions and processes, but it is not a good solution in the long run because memorization will never replace comprehension. It's what I tried. I may forget the exact name of the functions I have learned today, but I believe I should be able to keep in mind the logical process and the reasoning, consequently to retrieve those functions more easily than if I had simply memorized them. Rob built another app "Times Table" to exercise this new knowledge, but I won't report here. I was difficult enough for one day, so I will stop here for today.


Leave a comment

Login to comment a post