You are right, there should have been an explanation of why the protocol declaration had class there. Will fix in the next update. But that’s not a typo. You can easily verify this by removing the class binding for the protocol and see what happens. And yes, you can use AnyObject instead of class too.
But simplifying by not having the delegate be strong is not the way to go unless you absolutely, definitely, with 100% certainty know that it will not lead to retain cycles.
Hi Fahim,
I just finished this wonderful book, it was a great experience.
Two important issues I wanted to ask/note:
Page 841, But with iOS 11, there’s a new way to do things - your old pal Codable.
→ This should actually be Swift 4, shouldn’t it? I can compile the project to iOS 10 (and with small modification even to iOS 9) and it’ll work. So it’s not dependent on iOS version, I believe.
Page 875, However, till iOS 11, and With iOS 11, Apple introduced → This is actually dependent on Xcode version, not on iOS, namely it got introduced with Xcode 9, didn’t it?
You are right on both counts - I have added notes to fix those for the next release. Thanks for taking the time to point out these issues 
hi guys
page 200 Method Signatures
“…like tableView(_:numberOfRowsInSection:) or tableView(_:cellForRowAt:)”
the : after the _ are not in the actual code we are supposed to type in - am i stupid or is this confusing?
thanks
tableView(_:numberOfRowsInSection:)the : after the _ are not in the actual code we are supposed to type in
You don’t type any of it in your program. Rather, that syntax is used when you need to describe a method in some text.
When you need to write about a method in a book or in a post on a forum, you need some way of uniquely identifying the method name. The _: signifies that the method takes an argument without a parameter label. For instance, here are two method definitions:
func go(_ distance: Int, direction d: String) {
....
}
func go(time t: Int, location id: String) {
....
}
If you need to write something describing one of those methods, you refer to the first method as go(_:direction:) and the second method as go(time:location:). When you need to call those methods in your code, you do have to write some colons:
go(12, direction: "West")
go(time: 11, location: "Maple St.")
The colons in the full method name, e.g. go(_:direction:) come from the syntax used in Objective-C, which was the original iOS programming language.
huh thanks
it’s very odd seeing functions have different looking notations depending on where they are in the code - not seen that in any other language i’ve ever worked with before
That is incorrect. Methods always use the same syntax in your code. However, Swift is unique among the languages that I’ve studied in that parameter variables are considered part of the method name.
that’s a better way of putting it thanks, and yes it is odd but i guess it’s sort of a function overloading mechanism so it kinda makes sense
p. 200
“Now that the table view knows it has one row to display, it calls the second method you added – tableView(_:cellForRowA:t) – to obtain a cell for that row.”
Should be: tableView(_:cellForRowAt:)
p. 334 spelling mistake
“andd” should be “and”
p. 336 spelling mistake
“possibble” should be “possible”
p. 353 spelling mistake
“informaiton” should be “information”
Thank you for these I will fix in the next release of the book.
Possible Chapter 25 Typos:
p. 566 “The description cell at the top…” this is not actually shown in the figure.
p.568 The (Message Label) from Ch 23 does not appear in the figure.
p. 569 It might be clearer to say that the Cancel button goes right on top of the “<Back”. I was a bit confused on the “left slot” description.
p. 583 misspelled “knoiw” should be “know”
p. 604 The background color is red, however on p. 606, 607, and 609 it is gone. Either this is intentional so that the HUD is apparent or it was coded out. If the latter, I am not sure where this was done.
The description cell is there but since a text view normally does not show a border (or hint text) you cannot see it as something other than white space in the cell. This is just how iOS works. I believe that we add some text to show the description label and that text is missing here. Is that what you meant?
Page 604 says “Remove the backgroundColor line from the hud(inView:animated:) method.” - that’s where that happened
p. 650 “NSFetchedResulsController” should be “NSFetchedResultsController”
p. 678 “Add a mp view: Learn how…” should be “map”
p. 686 “…would be add below the title” should be “added”
p. 805 After adding constraints to “Artist Name” needs (obvious) extra step: “Click Add 3 Constraints.”
p. 812 “…appear gray as if it were selected.aFor some reason,…” replace “.a” and “. “
p. 846 FYI showNetworkError() needs to be added to SearchViewController.swift (the last file we were on in the progression was SearchResult.swift)
p. 848 “Add the following properties to SearchResult:” should be SearchResult.swift (formatted like a file)
p. 855 “You hedge agains that…” misspelled should be “against”
p. 874 “… don’t worry abobut that yet…” misspelled should be “about”
p. 879 “…class for asynchronouys networking…” misspelled should be “asynchronous”
p. 889 “…parameter and then alls parse(data:)…” misspelled should be “calls”
Hi,
p. 96 “Getting back to your cxode” → xcode
This topic was automatically closed after 166 days. New replies are no longer allowed.