Ray Wenderlich Course Part 15 (up to lesson 154)

Well here is the last part of Ray's course. After this, I'm leaving it for now as I've found it increasingly vague, without clear explanations that were there earlier on. Anyway, by the end of this one, I'll have the 'todo' app done. Here we go!

Delegates

Passing a checklist item between view controllers.

A comment from one of the users - having watched it for the fourth time it still doesn't make sense!

Here is Brian's reply:

Here's the breakdown:

Imagine you have three objects: a writer, a blog, and a story. 

The writer wants to add stories to the blog so it can directly call blog.addStory(). When the blog displays the story, it will inform the writer (that way, the writer can have some wine and cheese in celebration).

The writer object contains a reference to the blog and since the blog needs to notify the writer, it contains a reference to the write  object. This creates dependencies between each other.  

This is bad. If you make unrelated changes to the blog object, you may be forced to make changes to the writer object. 

By using a protocol, you introduce a middle man. For instance, you can create a  BlogProtocol that defines an addStory. Next you create another protocol called the BlogProtocolDelegate. This defines a didFinishAddingStory method. 

Now instead of adding a story using the story methods, you use the protocol methods. 

This means, your writer object doesn't need to know about the blog object. So how does the writer know when a story has been added? 

It implements the BlogProtocolDelegate method. Next, the Blog object has a reference to an object that implements the BlogProtocolDelegate. This is your delegate. When a story is added, the Blog object lets that object know. The Blog object doesn't care what kind of object is the delegate. 

Still clear as mud! One thing I can pick up from this is that protocol is the middle man. Dependencies are not so good. 

protocol AddItemViewControllerDelegate: class {

    

    func addItemViewControllerDidCancel(_ controller: AddItemTableViewController)

    func addItemViewController(_ controller: AddItemTableViewController, didFinishAdding item: ChecklistItem)

    

}

*Well something has come up - my ViewController file will not let me edit. No idea why. Have tried closing and opening again. It means I will just use Brian's file instead....

Looking at the textbook - I promised I would. 

OK, so on page 1051(!) it says about protocols - 

It is basically a GROUP of methods. It doesn't normally implement any of the methods it declares. It says that ANY object that conforms to this protocol must implement certain methods. 

So the delegates are types of protocol. They are also declared as 'weak' and are optional. Weak means they do not carry a reference - I remember that. 

Segues

So this is obviously a transition between scenes. I've followed this along but am not getting much from it. An error was made somewhere so have got Brian's latest file!

*Challenge - didn't really get it so am skimming through. 

Detail Disclosure Indicator

An information icon that appears on the cell. OK - that makes sense!

It's an accessory

OK - quite useful - on the bar at the top, after selecting a class, ALL of the methods come up! Good to see through them all this way. 

*Chalenge for adding second segue - was actually fine except I chose the wrong type of 'show' - accessory was needed. 

Passing Data 

Clear as mud - usual story! So I'm just ploughing through now, trying to keep up and glean anything that I can!

Dismissing the Edit Controller

Challenge - why are the cancel and done buttons doing nothing? No idea!

OK - no delegates apparently....

NS Object

So we want to access some of the features....Still lost. 

Am officially just skipping through the final bits now!

Refactoring - apparently Xcode has some refactoring codes....

Right, so basically it is like a find and replace for renaming methods etc. Could be useful!

Well, what a disappointing series of lessons. When I saw that it would be Brian instead of Ray, I was hopeful initially. However, it soon became clear that the information was so vague and hard to comprehend that I gave up trying to think outside the box or do anything different at all. Just following along, copying blindly is NOT a good way to learn, and I am annoyed that I've spent several hours on this project. Yet I had to do it - after all of that theory I needed to see something practical. Had I known it would be this pointless I wouldn't have bothered! Anyway, I'm going back to Treehouse. I think that it would be healthy to start afresh with the Intermediate section now - hopefully this will be manageable and the keeping track over time will be good for at least a few weeks. Depending on how that's going will affect whether I have another look at Angela's (excellent, much better than Ray's - no offence) one. BEFORE that, I will have another look at Ray's email of challenges/possibly the code wars too!