Zwei Bugs haben sich in den Workshop eingeschlichen, die ich nicht so stehen lassen kann:
1.-[USVDetailViewController setNewEntry:]
wird nicht benutzt. (Ende von Video 11)
Danke für’s Aufspüren an Tobias Müller a.k.a @twam bei App Dot Net
Wir haben eine Methode -[USVDetailViewController setNewEntry:]
geschrieben, die ruft [self configureView]
auf und diese Methode lädt den Link des Entrys. -[USVDetailViewController setNewEntry:]
wird aber nie benutzt. Die Methode -[USVDetailViewController viewDidLoad]
ruft ebenfalls [self configureView]
auf, insofern wird beim Laden des Views auch der Link geladen. Beides ist ziemlich unschön:
-[USVDetailViewController setNewEntry:]
brauchen wir eigentlich nicht, weil wir den Link nicht ändern, während der WebView angezeigt wird. Also löschen wir die Methode, getreu nach dem Motto „less code is better code“.- Dass
[self configureView]
in-[USVDetailViewController viewDidLoad]
aufgerufen wird, ist aber auch nicht korrekt, weil der User ja zurück zur EntriesTableView gehen und ein anderes Entry auswählen könnte, ohne dass der WebView abgebaut wird. Momentan wird er abgebaut, aber verlassen kann man sich darauf nicht. Wer weiß, was Apple in iOS 7 tun wird. Der korrekte Ort für den Aufruf von[self configureView]
ist also-[USVDetailViewController viewWillAppear:]
. Das wird immer dann aufgerufen, wenn der WebView erscheint.
Die Änderungen:
[self configureView]
aus viewDidLoad rausnehmen:
- (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view, typically from a nib. self.webView.delegate = self; }
viewWillAppear:
hinzufügen:
- (void) viewWillAppear:(BOOL)animated { [self configureView]; }
-[USVDetailViewController setNewEntry:]
kann ganz weg.
2. Im WebView wird der falsches Detail-Link angezeigt (Ende von Video 14)
Danke für’s Aufspüren an Michael Schulz a.k.a @michas auf App Dot Net
In -[USVEntriesTableViewController prepareForSeque:sender:]
wird für das Anzeigen der Details das falsche Entry ausgewählt. Das kommt daher, dass -[UITableView indexPathForSelectedRow]
verwendet wird um die Row zu ermitteln. Wir haben aber gar keine Row ausgewählt, sondern den Detail Button getappt. Daher liefert der Aufruf von -[UITableView indexPathForSelectedRow]
nichts (nil
) zurück. Man kann bei Objectve C aber auf einem nil
-Pointer Methoden aufrufen ohne einen Crash zu bekommen. Diese Methodenaufrufe liefern dann immer nil
bzw. 0
zurück. Das heißt, dass aus dem entries.row
in der nächsten Zeile immer 0
herauskommt, und wir somit als Entry immer self.entries[0]
benutzen.
Wenn man einen Breakpoint an der Stelle setzt und es laufen lässt, sieht man recht schnell indexPath
ist 0
. Man sieht aber auch, dass sender
eine USVEntryCell
ist.
Die richtige Methode ist also -[UITableView indexPathForCell:]
, die wir mit sender
als Argument aufrufen, dann bekommen wir auch den korrekten NSIndexPath
.
Die korrigierte Methode lautet also:
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { if ([segue.identifier isEqualToString:@"PushToDetail"]) { NSIndexPath *indexPath = [self.tableView indexPathForCell:sender]; USVEntry *entry = self.entries[indexPath.row]; ((USVDetailViewController*)segue.destinationViewController).entry = entry; } else if ([segue.identifier isEqualToString:@"PushToMedia"]) { NSIndexPath *indexPath = [self.tableView indexPathForSelectedRow]; USVEntry *entry = self.entries[indexPath.row]; ((USVMediaViewController*)segue.destinationViewController).enclosureURL = entry.enclosureURL; } }
Sorry für die Fehler. Wer weitere findet, immer her damit!
Vielen Dank für die Klarstellungen. Meine zweiten Bug (https://alpha.app.net/twam/post/4103791) habt ihr aber vergessen 🙂
Der müsste an sich schon in den Errata sein, weil er mir noch vor der Veröffentlichung aufgefallen war.