Entwicklertagebuch iPhone: GUI

Im heutigen Eintrag geht es um die Entwicklung des User Interfaces. Dabei soll keine Schritt-für-Schritt-Anleitung entstehen; vielmehr sollen die Arbeitsabläufe und Stolpersteine aufgezeigt werden. Ohne  Erfahrung mit der Thematik iPhone sollten als Einstiegspunkt die Human Interface Guidelines durchgearbeitet und erlernt werden, damit ein Verständnis für die Ansichten von Apple über die Nutzerführung, das Anordnen und Aussehen von Elementen und das generelle Design der verschiedenen Applikationstypen entsteht.

Werden die Konventionen eingehalten, wird sichergestellt, dass jeder iPhone-Besitzer ohne Einarbeitung mit jeder entwickelten App zurechtkommt. Einerseits ist dies ein schöner Effekt, andererseits sind genau aus diesem Grund viele Applikationen gleichgeschaltet und sehen sich ähnlich, d.h. die Individualität bleibt ein wenig auf der Strecke.

Aufgrund der erstellten Mockups hatte ich schon einen guten Überblick über die einzelnen Seiten der Anwendung und konnte direkt mit dem Design im InterfaceBuilder - dem grafischen View-Erstellungstool von Apple - beginnen. Dies klappte anfangs auch ohne Schwierigkeiten: Die Elemente ließen sich per Drag&Drop auf den einzelnen Views anordnen und mit Eigenschaften versehen.

Das initiale Design sah daher schon sehr ansehnlich aus und konnte direkt im Simulator ausprobiert werden. Das Look and Feel der Applikation stand also sehr schnell zur Verfügung.

Nachdem die einzelnen Seiten fertig und mit dem dazugehörigen NavigationController verlinkt waren, ging es darum, abhängig von einer Eingabe eine Tabelle mit bestimmten Werten zu füllen. 

Problem 1: Das Keyboard klappt nicht wieder von alleine zu. Einfache Lösung: Es muss eine Methode implementiert werden (searchBarTextDidEndEditing), in der die Kontrolle über die Tastatur wieder an den übergeordneten Controller zurückgegeben wird. 

Problem 2: Die Tabelle wurde nicht aktualisiert, sprich sie blieb immer leer.

Nach Überprüfung sämtlicher Verbindungen im InterfaceBuilder, dem Debuggen der Tabellenmethoden und der Gewissheit, dass der Wert auch in das Array geschrieben wird, welches mit Hilfe der Tabelle dargestellt werden sollte  war klar, dass ein nicht so einfach zu lösendes Problem besteht.

Meiner Meinung nach war der Code korrekt, der Fehler musste also im InterfaceBuilder oder in meiner Benutzung desselbigen zu finden sein. Nach dem erneuten Überprüfen der von mir getätigten Einstellungen blieb ich erst einmal ratlos zurück. Nach diversen Google-Sitzungen war ich auch nicht schlauer, so dass ich angefangen habe, ein paar InterfaceBuilder-Einstellungen zu ändern. Ergebnis: Das Projekt lief gar nicht mehr. Der absolute Schocker war allerdings, dass das Projekt immer noch nicht lief, nachdem ich alle Änderungen rückgängig gemacht hatte. Selbst als ich alte Versionen der Quelldateien wiederhergestellt hatte, lief das Projekt nicht. Irgendwie hatte mir das Herumspielen mit dem  InterfaceBuilder das gesamte Projekt zerschossen. Also alles noch einmal von vorne.

Nachdem sich auch bei dieser Iteration nichts gebessert hatte, sprich, die Daten wurden immer noch nicht in der Tabelle angezeigt, habe ich die Notbremse gezogen, den InterfaceBuilder in die Ecke gestellt und den betreffenden View programmatisch erstellt. Dies war natürlich aufwändiger als sich das UI zusammenzuklicken, zum Glück wurde ich direkt mit einer lauffähigen Variante der App belohnt. Unbefriedigend, da ich nicht herausbekommen habe, was im InterfaceBuilder falsch gelaufen ist, aber insgesamt war ich doch froh, dass es weiter vorwärts gehen konnte. Das gleiche Spiel hat sich auch noch einmal mit der Detailseite wiederholt, nur dass ich da beim ersten Fehlversuch direkt auf die programmatische Variante umgeschwenkt bin.

Bei der Tabellendarstellung kam es auch noch zu anderen, kleinen Problemen:

1. Das Editieren der einzelnen Zeilen: Hierfür müssen drei weitere Methoden implementiert werden, mit deren Hilfe die Tabelle auf editierbar, bzw. nicht editierbar gesetzt wird. Des Weiteren muss noch eine Methode implementiert werden, in der sich um das Löschen selbst gekümmert wird.
2. Das Aussehen der einzelnen Tabellenzellen: Per Default besteht eine Tabellenzelle aus drei Attributen: Links: Bild, Mitte: einzeiliger Text, Rechts: Zähler plus Icon für die weitere Navigation. Ich brauchte allerdings zwei Zeilen Text. Hierfür muss das generelle Aussehen der Zellen in der Methode cellForRowAtIndexPath programmatisch angepasst werden.
3. Anzeige der Zellenauswahl: Standardmäßig wird an der ausgewählten Tabellenzelle eine Farbe hinterlegt, diese Hinterlegung wird aber nicht wieder automatisch entfernt, was in meinem Prototyp dazu führte, dass die ausgewählte Zelle die ganze Zeit ausgewählt blieb. Für dieses Problem gibt es natürlich auch eine Methode: deselectRowAtIndexPath .

Insgesamt ging das initiale Erstellen des UI leicht und schnell von der Hand, leider kam es direkt bei den Inhalten, die ein wenig von der Norm abwichen zu Schwierigkeiten, so dass ich viel Zeit mit der programmatischen Umsetzung der Elemente verbraucht habe. Auch war ich bisher von grafischen Editoren gewohnt, dass Quellcode und Variablen zu den grafisch erzeugten Elementen erstellt werden. Dies ist in XCode nicht so. Die Variablen und die Verbindung mit den grafischen Elementen sind manuell vorzunehmen. 

Die Erstellung des UI hat Spaß gemacht und mit ein wenig Übung und Erfahrung lassen sich mit Hilfe von XCode und dem Interface Builder leicht Apps entwickeln.