WebService, TableView, Segue & co. – Einstieg in iOS Apps mit Swift Teil 2

Im vorherigen Teil haben wir das User Interface zusammen gebaut. In diesem Teil kommen wir nun endlich zum Code schreiben.

Genauer gesagt behandeln wir:

Das übergeben von Werten zwischen zwei Views
Die Kommunikation mit dem Webservice (für die unterschiedlichen Arten und Unterstützung in iOS erscheint noch ein gesonderter Artikel)
Die Daten vom Webservice im TableView darstellen

 

Kommunikation zwischen zwei Views

In unserem DetailView würden wir gerne den vollständigen Eintrag einer TableView zelle sehen. Dazu müssen wir die Klasse DetailViewController wie folgt ändern (das bestehende Boilerplate kann ruhig gelöscht werden):

Das war es auch schon für den DetailViewController. Wir wechseln jetzt in den MainTableViewController und fügen folgendes hinzu (auch hier kann der Boilerplate code gelöscht werden):

Und fertig ist die Kommunikation zwischen den beiden. Aber was passiert hier eigentlich genau?

prepareForSegue wird aufgerufen, sobald das aktuelle View zu View B wechseln will. Wir geben dem DetailViewController dabei den vom User angeklickten Inhalt mit und setzen ihn in seiner viewDidLoad Methode als Inhalt für das TextView.

 

Das TableView mit Leben füllen

Damit der User auch was zum klicken hat müssen wir die Daten vom WebService bekommen. Um uns die Anfragen an den WebService zu vereinfachen hab ich bereits eine Klasse NetworkConnection vorbereitet; für das parsen des JSON benutzen wir SwiftyJSON von Denis Lebedev. Über das plus Symbol unten also wieder zwei neue Dateien erstellen, aber statt Cocoa Touch Class wählen wir dies mal Swift File aus und vergeben die jeweiligen Namen NetworkConnection und SwiftyJSON. In die Dateien könnt ihr folgende Codeausschnitte per copy&paste einfügen.

Für NetworkConnection:

Für SwiftyJSON:

 

Habt ihr das erledigt können wir im MainTableViewController fortfahren. Für die maximale Anzahl der Einträge des Webservices erstellen wir uns eine Variable rowCount – genauer gesagt eine computed property. Eine computed property ist im Grunde die Kurzform für eine Variable mit dazugehörigem Getter und Setter. Da wir den Setter in diesem Fall nicht brauchen implementieren wir nur einen Getter. Dies geht folgendermaßen:

Greift der Programmcode also auf die Variable rowCount zu, wird eine Anfrage an den Webservice unter der URL “http://api.icndb.com/jokes/count” gestartet und insofern ein Ergebniss vorhanden ist dieses zurückgegeben. Eine mögliche Ausgabe des Webservice sieht so aus:

Fehlt noch eine Funktion um einen bestimmten Artikel vom Webservice zu bekommen (Anmerkung: Dies geschieht im jetzigen Beispiel über eine synchrone Anfrage um das Projekt möglichst einfach zu halten; in der Praxis holt man sich natürlich alle Daten asynchron und cached sie lokal in einer Variable oder speichert sie sogar auf dem Gerät). Dies geschieht über folgenden Codesnippet:

Die auskommentierte Variable plainText sorgt dafür, sofern ihr HTML encodierte Zeichen vom Webservice bekommt, dass diese normal dargestellt werden. Dies ist bei unserem Webservice nicht der Fall. Eine mögliche Ausgabe sieht so aus:

Jetzt müssen wir der TableView nur noch mitteilen, dass sie ihre Daten von unserer gerade erstellten Funktion beziehen soll. Dazu müssen wir das UITableViewDataSource Protokoll implementieren.

Ihr fügt also ans Ende der Klasse (nach der schließenden Klammer) folgenden Code ein:

Man hätte dies auch direkt in die Klasse schreiben können. Mit Swifts extensions ist es aber möglich bereits auf Programmcodebene eine strikte Trennung zwischen implementierten Protokollen und Klasseneigenen Methoden zu ermöglichen.

Was tut der Code eigentlich?

numberOfSectionsInTableView gibt zurück das wir nur eine einzige Sektion haben, in der die Zellen liegen. Habt ihr mehrere verschiedene Kategorien, müsst ihr hier natürlich unterscheiden.

numberOfRowsInSection gibt die maximale Anzahl der Tabellenzellen wieder (oben haben wir in der computed property rowCount dafür den Webservice gefragt, wie viele Inhalte er zurückliefert).

tableView:cellForRowAtIndexPath gibt wie der Name bereits vermuten lässt, die Zelle für einen gewissen Index in der Tabelle zurück. Dabei werden auch wirklich nur die Zellen geladen die im ViewPort des Users liegen.

Hier wird für die aktuelle Zelle unsere Funktion gefragt, was der Webservice für den momentanen Index anbietet, und auch gleich dem textLabel zugewiesen.

Bleibt noch tableView:didSelectRowAtIndexPath übrig. Die Methode wird aufgerufen, sobald ein User eine Zelle in der TableView ausgewählt hat. Wir setzen unsere lokale Variable currentJoke auf den Inhalt der geklickten Zelle

und rufen mit

schließlich unsere am Anfang im Storyboard erstellte Segue auf – zeigen also das DetailView an.

 

Die App ist fertig

Damit ist unsere App auch schon fertig. Über einen Klick auf den Start Button (oder alternativ cmd + r) könnt ihr diese im Simulator ausführen. In der TableView werden alle Weisheiten über Chuck Norris, die der Webservice liefert, in Kurzform angezeigt und mit einem Klick auf eine Zelle im DetailView in der vollständigen Form.

ICDNB 16 ICDNB 17

 

Hier gibt es noch das komplette Projekt als Download:

Chuck Norris Database

 

 

No Comment

You can post first response comment.

Leave A Comment

Please enter your name. Please enter an valid email address. Please enter a message.