Mittlerweile haben über 2000 Studenten eines meiner iOS-Trainings absolviert. Ein großes Anliegen ist mir der Support und die Betreuung. Dabei begegnen mir einige Probleme und Fehler regelmäßig. Die häufigsten habe ich aufgeschrieben, sodass DU sie nicht mehr machen musst. Vielleicht findest Du Dich bei dem ein oder anderen Punkt auch wieder?

1. iOS-Entwicklung ohne die Sprache zu lernen

Die Sprachen Swift und Objective-C sind das Handwerkszeug. Du begegnest ständig den verschiedenen Syntaxelementen. Darum ist das wichtig, dass Du zumindest die Grundlagen kennst. Wenn Du direkt in die App-Entwicklung mit dem CocoaTouch Framework einsteigst, überfordert dies die meisten. Vergleich es mit einer Fremdsprache. Wenn Du ständig überlegen musst wie Du etwas grammatikalisch richtig formulierst, kannst Du Dich nicht gewählt ausdrücken. Genau deshalb können wir uns in der Muttersprache am besten verständigen. Genauso ist es bei der iOS-Entwicklung. Du musst erst Swift oder Objective-C Kenntnisse haben, bevor Du Apps entwickeln kannst.

2. Zu wenig Selbstvertrauen

Es gibt ohne Zweifel viele Informationen. Du kannst Dich vermutlich bis an Dein Lebensende mit neuen Technologien beschäftigen. Trotzdem wirst Du nie alles erfassen. Du spezialisierst Dich darum irgendwann automatisch. Gerade zu Beginn kann das erdrücken oder sogar einschüchtern.

Nach der ersten Begeisterung kommen die Zweifel: Kann ich das überhaupt? Bin ich vielleicht zu alt? Bin ich noch zu jung? Kann ich vielleicht mich beruflich überhaupt noch verändern? Ich habe nicht studiert, finde ich trotzdem einen Job?

Das einzige was zwischen Deinem Erfolg und Dir steht, bist DU. All diese Zweifel basieren nur auf den falschen Glaubenssätzen. Der Arbeitsmarkt sieht aber gerade in der IT-Welt ganz anders aus. Es gibt endlos viele Unternehmen und Startups, bei denen es auf Deine praktischen Fertigkeiten, nicht auf Abschlüsse, Zertifikate und Noten, ankommt. Es gibt zwar große Konzerne und Unternehmen die einfach stumpf auf formale Bildung achten. Aus Erfahrung sage ich Dir hier direkt: bei denen möchtest Du trotz besserem Gehalts in der Regel ohnehin nicht arbeiten. Es gibt viel coolere Arbeitgeber!

Diesen Punkt möchte ich mit einem Zitat schließen:

He who says he can, and he who says he can’t, are both usually right.

Genau das ist der Punkt. Wenn Du Dir auf die Brust trommelst uns sagst: ICH SCHAFFE DAS! oder wenn Du eingeknickt den Kopf hängen lässt und sagst “Ich schaffe es eh nicht…” hast Du in jedem Fall recht. Eine selbsterfüllende Prophezeiung, wenn Du so willst.

3. Outlets umbenennen und die Verbindung nicht anpassen

Gerade Einsteigern passiert es in den ersten Apps sehr häufig. Ein Outlet wird falsch benannt, vielleicht aus Versehen ein Tippfehler eingebaut. Schon wird die Variable (das IBOutlet) einfach umbenannt. Soweit, so gut. Problematisch daran ist, dass im Connections Inspector rechts die alte Referenz noch gespeichert ist.

Schauen wir uns folgenden Code an. In der Klasse ViewController gibt es ein IBOutlet mit dem Namen progressView. Es wurde einem View-Element zugewiesen:

Im Connections Inspector lässt sich diese Referenz nun nachvollziehen:

connections-inspector

Würde progressView nun zum Beispiel als prView abgekürzt, wäre das Referencing Outlet noch genauso hinterlegt. Das führt zu einem Absturz der App. In der Regel wird in der Klasse AppDelegate ein Fehler angezeigt wie “Thread 1: signal SIGABRT”. In der Konsole wird ein Stacktrace und eine Meldung ausgegeben: libc++abi.dylib: terminating with uncaught exception of type NSException. In einem Swift Projekt muss die alte Verbindung im Inspector gelöscht und das Outlet neu verbunden werden. Refactoring und das Umbenennen von Variablen wird von Xcode bisher nur bei Objective-C unterstützt. 

4. Selektoren mit oder Doppelpunkt am Ende?

Selektoren werden genutzt, um einer aufzurufende Methode zu benennen. Dies kann eine Callback-Funktion sein, die in der von Dir gestarteten Methode ausgeführt wird. Ein super Beispiel dafür ist der NSTimer. Bei der Initialisierung wird ein Selektor übergeben:

Die Methode erzeugt einen Timer, der regelmäßig einen Selektor aufruft. Und das ist in diesem Fall die Methode timerUpdate. Verwirrung entsteht vor allem bei der Frage, ob am Ende hinter timerUpdate ein Doppelpunkt stehen muss. Denn es gibt auch folgendes Beispiel:

Welche Antwort ist nun richtig? Beide! Der Unterschied ist die Anzahl der Parameter. Die Methode timerUpdate() nimmt keine an, der Methode newLongPress wird ein Parameter übergeben, ein UIGestureRecognizer Objekt. Die Erklärung dafür liegt in der Vergangenheit, die Objective-C Syntax macht es deutlich:

Der Parameter hinter “newLocation” wird mit einem Doppelpunkt vom Methodennamen getrennt.

Das codingtutor.de Swift-Labor Extra

Lad Dir das eBook ‘Die 6 häufigsten Fehler von iOS-Entwicklern’ im Swift-Labor herunter.

Noch kein Mitglied?

Mehr Informationen

5. Forced unwrapping von Optionals auf ungeprüften Variablen

Es gibt ein Syntaxelement um auf nil hinzuweisen. Einfach ausgedrückt hat ein Optional möglicherweise keinen Wert. Greift ein Entwickler auf die Variable zu, muss er den Wert erst aus dem Optional holen. Und dafür gibt es verschiedene Wege. Einer davon ist das Forced Unwrapping:

Genau so könnte es laufen. Es gibt wie gesagt noch weitere Wege, mir ist es aber wichtig diesen Weg zu zeigen. Unten wird print() aufgerufen und über Interpolation fehlerCode ausgegeben. Hier steht das Ausrufezeichen dahinter, um eben genau das Unwrapping zu forcieren. Das ist auch kein Problem, da wir vorab fehlerCode geprüft haben. Durch die if-Bedingung kann der Code nicht ausgeführt werden, wenn der Wert in fehlerCode nil ist.

Das Forced Unwrapping kann aber ebenso zu Problemen führen. Ist der Wert im Optional nil, gibt es sogar einen schweren Fehler. Der folgende Code zeigt, wie es NICHT geht:

Es ist nicht sicher, ob fehlerCode ggf. nil ist. Das Beispiel ist zwar (bewusst) sehr offensichtlich, in der Praxis gibt es aber immer wieder genau diesen Fehler.

6. Den Delegate/Datasource einer Tabelle nicht setzen

Wird eine UITableView verwendet, braucht sie mindestens eine Datenquelle. Dafür gibt es das spezielle Outlet datasource. Zudem gibt es auch die Möglichkeit über das Delegate Pattern die Interaktion mit der Tabelle zu steuern. Festgelegt wird der Delegate über das delegate Outlet. Gerade Einsteiger vergessen bei der Entwicklung häufig dies in der Tabelle zu konfigurieren. Schon stellt sich die Frage, weshalb keine Daten in der Tabelle angezeigt werden. Die Antwort ist im Connections-Inspector versteckt. So sollte es aussehen:

datasource delegate tableview outlet

Ist dies nicht der Fall, klickst Du einfach den leeren Kreis rechts an und ziehst die Verbindung zum entsprechenden ViewController im Storyboard.

7. Langsame Aufgaben im Mainthread erledigen

Ein weiterer Fehler ist die synchrone Verarbeitung von zeitintensiven Aufgaben. Dazu gehört die Verarbeitung größerer Datenmengen genauso wie der Zugriff auf das unzuverlässige Medium Internet. Im besten Fall sind die Netzwerkverbindungen und Anfragen in wenigen Millisekunden erledigt. Wenn die Verbindung nicht aufgebaut wird, ein Timeout nach 60 Sekunden kommt oder die Daten nur langsam heruntergeladen werden, blockiert das die gesamte App.

Im schlimmsten Fall beendet iOS eine solche App sogar, da sie nicht mehr reagiert. Folgende Code ist nur ein Beispiel von vielen, dass unbedingt im Hintergrund ausgeführt werden muss:

Hier wird der Inhalt einer URL heruntergeladen und in jsonData gespeichert. Im Frontend wird die weitere Ausführung der App unterbrochen, bis ein Ergebnis vorliegt. Dabei ist es egal ob es positiv oder negativ ist.

Die Lösung ist bspw. GCD, Grand Central Dispatch. Damit wird Dein problematischer Code im Hintergrund ausgeführt. Der Mainthread mit dem Interface ist weiterhin voll nutzbar, Eingaben werden verarbeitet und das Interface “friert nicht ein”. Weitere Beispiele zu diesem Thema findest Du auch in meinem iOS Training: iOS9 mit Swift2 am Beispiel von 15 Apps.

Foto: slip? by Pery Hall, used under CC BY / Original used as background

Kommentare (2)

  • Patrick

    2 Jahren ago

    Hey Jan,

    ich hab mir die DVD gekauft und bin jetzt bei der TodoListe (Kapitel 6.4). Beim ausführen der App bekomme ich leider ein Fehler.

    Thread 1: signal SIGABRT

    in der Class AppDelegate

    Hoffe das du mir weiter helfen kannst.

    Gruß

    Patrick

    • Jan Brinkmann

      2 Jahren ago

      Klar, gern. Vielleicht kannst Du mir eine E-Mail schicken? Im besten Fall den Quellcode mal als ZIP-Archiv anhängen. Einfach an mail@janbrinkmann.de

Leave a Comment to Jan Brinkmann Cancel reply

Your email address will not be published.