Die Zahl der Anwender, die sich als iPhone-Anwender registrieren lassen, wächst und wächst. Viele, die sich enthusiastisch ans Programmieren machen, geben jedoch bald entnervt und enttäuscht wieder auf. Damit Ihnen das nicht passiert, haben wir einen erfahrenen Programmierer gebeten, die wichtigsten Regeln zum Entwickeln von iPhone-Software zu formulieren.
Es ist einfacher, als man denkt
Gerade die Syntax der Sprache Objective-C erscheint vielen Anfängern gewöhnungsbedürftig. Aber genau wie das Cocoa-Touch-Framework hat die Sprache klare Konzepte und lässt sich leicht erlernen. Wer C kann und eine objektorientierte Programmiersprache wie C++ oder Java wird in Objective-C gar keine Probleme haben.
Erste Erfolge lassen sich mit wenig Code schnell erzielen, was zusätzlich motiviert.
Apple bietet im iPhone Developer Center unter http://developer.apple.com/iphone/ hervorragende Videos und Anleitungen zum Einstieg an.
Es ist schwerer, als man denkt
Das iPhone-Interface überzeugt auch durch spielerische Leichtigkeit. Aber nicht alles ist auch so leicht in Code umzusetzen. Sobald das Interface etwas über den Standard hinausgeht, können grafische Effekte und Funktionen wie das Rotieren des iPhone schon einiges an Arbeit erfordern.
Erfahrene Mac-OS-X-Entwickler werden feststellen, dass das iPhone “Mac-OS X auf Diät” ist, und es einige Frameworks, die sie vom Mac kennen, nicht auf das iPhone geschafft haben. So fehlt zum Beispiel die Klasse NSXMLDocument. Dieser DOM-basierende XML-Parser muss daher durch den SAX-basierenden Parser NSXMLParser ersetzt werden.
Auch die Publikation im App Store oder das Versenden von Beta-Versionen mit einem “Ad-Hoc Certificate” kann sehr viel aufwendiger sei, als man sich das vielleicht vorstellt.
Nicht unterkriegen lassen!
Controller, Controller, Controller
Ein Teil des iPhone SDKs verdient besondere Erwähnung, auch wenn es schon im letzten Segment anklang: Eine besondere Stellung hat die Klasse UIViewController, und ihre Unterklassen UINavigationViewController, UITabViewController und UITableViewController.
Fast nichts im iPhone User Interface funktioniert ohne diese Klassen, die so kaum eine direkte Entsprechung in anderen Klassenbibliotheken haben. CocoaTouch folgt hier ganz deutlich dem Model-View-Controller Entwurfsmuster, dennoch können die vielen Controller an allen möglichen Stellen für Anfänger verwirrend sein.
Auch hier gilt: Nicht unterkriegen lassen, aber auf jeden Fall die Beispiele bei http://developer.apple.com/iphone ansehen.
Erkenne die Unmöglichkeiten
Das iPhone kann viele Dinge, es ist aber an manchen Stellen auch eingeschränkt. Bevor man also seinen Job kündigt und schon die erträumten Einnahmen aus dem App Store zählt ist es wichtig, sich kurz über die technischen Beschränkungen, und die Bedingungen die Apple App Stores zu informieren.
So ist es unwahrscheinlich, dass Apple mit der aktuellen Hardware ein SDK zum Aufnehmen von Videos veröffentlicht, entsprechende Hacks werden vom App Store auch nicht aufgenommenen.
Auch das Abspielen von Videos außerhalb des von Apple zur Verfügung gestellten Multimedia-SDKs dürfte einen unrentablen Aufwand darstellen. Somit scheiden Real-Time-Streaming Video Inhalte aus.
Der Simulator ist Dein Feind
Der im SDK enthaltene iPhone-Simulator ist eine gute Möglichkeit, um Programme schnell zu testen. Abgesehen davon, dass Frameworks wie CoreLocation oder Accelerometer gar nicht unterstützt werden, hält er aber ein paar weitere Fallen bereit:
Der Simulator akzeptiert teilweise Code, der zwar auf dem Mac funktioniert, auf einem echten iPhone aber nicht (Populärstes Beispiel: NSXMLDocument). Auch ist das Verhalten bei bestimmten Klassen leicht, aber entscheidend unterschiedlich zum echten Gerät.
Und bei Video- und Musikdateien wird der Simulator zu stark durch das beeinflusst, was auf dem Mac installiert ist. Als Resultat werden im Simulator Dateien abgespielt, die auf dem iPhone nicht funktionieren, oder sogar umgekehrt Dateien nicht abgespielt, die auf dem iPhone problemlos funkionieren. Auch treten manche Fehler, etwa Speicherlecks, nur im Simultor auf. Insgesamt ist der Simulator zu nah an den Mac, auf dem er läuft, gekoppelt.
Darum: Software mindestens einmal am Tag auf dem echten Gerät laufen lassen.
Design mit Gefühl
iPhone Nutzer haben eine hohe Erwartung an das Design von Anwendungen, und es lohnt sich, das Design sorgfältig zu planen und zu gestalten. Dazu sollte man immer die Human Interface Guidelines von Apple beherzigen.
Das wichtigste ist aber vielleicht: Ein Finger ist keine Maus! Daher muss man Interface-Elemente immer großzügig auslegen.
Werde Memory Manager
Das iPhone hat im Gegensatz zur neuesten Version des Mac-OS keinen Garbage Collector, es verfügt also nicht über eine automatische Speicherverwaltung. Das ist nachvollziehbar, da die Cocoa Garbage Collection am besten auf Systemen mit mehr als einem Prozessor(Kern) läuft – und das iPhone hat nur einen.
Gleichzeitig ist der Speicher des iPhones mit 128 MB nicht gerade großzügig bemessen, und hat zu allem Überfluss auch keinen virtuellen Speicher! Daher ist es wichtig, die Speicherverwaltung von Cocoa genau zu kennen.
Das ist glücklicherweise gar nicht so schwer, wenn man einige Regeln beachtet. Da sich das Memory Management des iPhones nicht von dem des Mac-OS unterscheidet, lassen sich Artikel in Büchern oder aus dem Web problemlos übertragen. Zusätzlich können (und sollten) View Controller Objekte auf die Nachricht “didReceiveMemoryWarning” reagieren, um Speicher freizugeben. Dieser Aufruf lässt sich mit dem Simulator hervorragend simulieren.
Wichtigster Merksatz: Zu jedem Aufruf von “alloc”, “new”, “retain”, oder einer Methode die “copy” oder “create” enthält gehört ein Aufruf von “retain”.
Nutze die Werkzeugkiste
Apples Entwicklungsumgebung kommt mit dem von vielen Anfängern nicht beachteten Werkzeug “Instruments”. Dieses Werkzeug ist extrem vielfältig, und in seiner Vollständigkeit sicher keine leichte Kost. Aber die Bedienung zum Überprüfen des Speicherverbrauchs, der Leistung des Programms, oder zum Finden von Speicherlecks ist auch für Anfänger einfach genug.
Bei modernen Betriebssystemen, zu denen das iPhone OS ohne Frage gehört, gilt die Regel, dass frühe Optimierung die Wurzel allen Übels ist: Die heutigen Compiler und Systeme sind so gut, dass eine händische Optimierung fast aussichtslos ist. Da hilft ein Werkzeug wie Instruments, um Optimierungspotentiale zu finden. Besonders gut ist Instruments aber darin, durch Aufzeichnen der Durchläufe die Überprüfung von Änderungen zu ermöglichen. So lässt sich leicht feststellen, ob der gewünschte Erfolg auch eingetreten ist.
Die Überprüfung eines Programms mit Instruments sollte absoluter Standard bei jeder Entwicklung sein und ist nicht schwer. Einfach mal eine Anwenden mit “Run With Performace Tool: Leaks” aus dem Run Menü starten.
Alleine entwickeln ist doof
Bücher und Webseiten sind hilfreich, und führen vielleicht auch zum Erfolg. Mehr Spaß macht es aber, wenn man – virtuell oder tatsächlich – andere findet, die mitentwickeln. Auch werden mit Sicherheit Fragen auftreten, die sich allein auch nicht durch scharfes Nachdenken lösen lassen.
Jedes größere deutsche Mac-Forum hat eine Sektion für “Entwickler / Programmierer”, und unter http://www.osxentwicklerforum.de gibt es das einzige, reine Entwicklerforum in deutscher Sprache.
Verwende ein Source Code Management System
Jede Zeile Code, die es wert ist, für mehr als 24 Stunden gespeichert zu werden, ist es wert, in einem Source Code Management System (SCM) verwaltet zu werden. Die Vorteile solcher Systeme sind vielfältig, und eine Entwicklung im Team ohne SCM erregt bei erfahrenen Entwicklern ungläubiges Kopfschütteln.
Auch für einzelne Entwickler überwiegen die Vorteile klar den Aufwand: Ein SCM ermöglicht es, den Stand des Projekts zu bestimmten Punkten abzusichern, und verschiedene Stände zu vergleichen. Die Funktionen sind dabei deutlich stärker auf Entwickler zugeschnitten als beispielsweise Time Machine oder die Snapshot-Funktion von Xcode.
Das Open-Source-System “Subversion” (auch als svn bekannt) eignet sich besonders gut für die nahtlose Integration mit Xcode, es lassen sich aber natürlich auch andere Systeme mehr (wie Perforce) oder weniger gut (wie git) mit Xcode verwenden.