Mit der neuen Version iOS 4.3 geht auch eine neue Version der Apple Entwicklungsumgebung XCode einher. Diese ist nun in der Version 4 verfügbar. War allerdings bisher XCode 3 kostenlos verfügbar, sofern man sich kostenlos bei Apple registriert hatte, so können nun nur noch Entwickler XCode kostenlos herunterladen, die im kostenpflichtigen Developer Programm teilnehmen (und damit auch Apps einreichen und veröffentlichen können).

Alle anderen Entwickler, die vielleicht erstmal schauen wollen, was den so möglich ist oder den iPhone Simulator, der mit XCode mitkommt, dazu nutzen wollen, um ihre Webseiten iOS fähig zu machen, müssen ab sofort XCode 4 im App-Spore kaufen. Es kostet dort allerdings nur 3,99 Euro.

Auf der anderen Seiten liest man zur Zeit in den Bewertungen dort sehr häufig von Problemen bei der Installation. Diese scheint wohl regelmäßig abzubrechen. Und das wirft doch ein unschönes Bild auf Apple.

Es bleibt abzuwarten, in welche Richtung sich Apple hier bewegen wird.

Schön finde ich den Kommentar von David Lockwood

Yes, you still needed to pay $99 to be part of the developers program. However, it used to be free if you registered a free account on the website. So now you have to pay for the IDE? What the hell, Apple? I think you need to watch the your old “1984″ style commericals because this is getting to be a bit much.

In einer Freitags-Sitzung des iPhone-Programmierkurses der Stanford Univerity wird sehr anschaulich dargestellt, wie sich ein iPhone Programm mit XCode debuggen lässt. Schritt für Schritt werden die einzelnen Teile des Debuggers erklärt und auch auf typische aber schwer zu findende Fehler hingewiesen. Das sollte man sich wirklich mal anschauen.

Starte ich den Debugger in Xcode 3.1.4, so passiert es immer wieder, dass ich die Fehlermeldung
Undefined command: "". Try "help"  erhalte. Starte ich das Programm ganz normal, läuft es durch. Auch wenn im Debug Modus keine Breakpoints definiert sind, tritt dieser Effekt auf.

Der Witz ist, dass ich es mir schwer fällt, eine Ursache fest zu stellen. Auch bei komplett neu generierten Projekten tritt das Problem auf. Manchmal hilft es, unter  Build ein Clean all Targets auszuführen. Auch ein Neustarten des Debuggers hilft gelegentlich weiter.

Nun fiel mir noch eine Ursache auf: Wenn ich Xcode über das Dock starte, tritt der Fehler nicht auf. Starte ich Xcode aber per open meinProgramm.xcodeproj/ von der Kommandozeile aus, habe ich wieder diesen Fehler.

Ich habe das Projekt "US-Tastatur Layout" zunächst beendet. Daher hatte ich sofort wieder das Problem, dass ich in Xcode keine automatisch schließenden geschweiften Klammern hatte, obwohl ich die Option automatic insert closing "}" ausgewählt hatte.

Doch auch dafür gibt's eine Lösung: Man wähle unter Preferences -> Key Bindings -> Text Key Bindings -> Insert Open Brace  aus und gebe statt } nun alt-8 ein.

Schön wäre nun, wenn das auch für die runden und eckigen Klammer funktionieren würde.

Man steht mit der Shell im Projekt-Verzeichnis, hat vielleicht gerade git- oder subversion-Aktionen vorgenommen und möchte nun das Projekt in xcode bearbeiten. Da wäre es doch nun schön, wenn man dies einfach von der Shell aus machen könnte. Und siehe da, es gibt sogar eine ganz einfach Lösung:

Per

open foo.xcodeproj/

startet man foo.xcodeproj so als hätte man im Finder einen Doppelklick darauf gemacht.

Seit einiger Zeit versuche ich, hinter die Geheimnisse der iPhone Programmierung zu gelangen. Dazu habe ich mir das Buch von Markus Stäuble "Programmieren fürs iPhone" besorgt. Zu diesem Buch ist aus meiner Sicht zu sagen, dass es recht schön in die Programmierumgebung Xcode einführt.

Die im Buch angegeben Beispiele meint man auch nachvollziehen zu können. Versucht man sich dann allerdings in daran, die Beispiele abzuändern, so merkt man sehr schnell, dass es mit dem Verstehen doch nicht so weit her ist.

Außerdem habe ich das Gefühl, dass die Beispiele (hier vorallem die Anwendung iRSS) nicht sonderlich sauber programmiert sind. Mir scheinen da ein paar Memory-Leaks vorhanden zu sein. Da ich allerdings vorher weder mit Objective-C geschweige denn mit Cocoa in Kontakt gekommen bin, wäre der direkte Kontakt zum Autor nicht verkehrt. Leider verlief eine Kontakt-Anfrage über die auf obige Homepage angegebene Seite bei Twitter bisher im Sande.

Die Memory-Leaks meine ich mittlerweile per Instruments nachgewiesen zu haben. Das ist dann bitter, wenn man solche Fehler in einem Lehrbuch findet.

Hat man jahrelang mit Script-Sprachen gearbeitet, so ist die Umstellung auf Objective-C wegen der Pflicht, sich selbst um das Speichermanagement zu kümmern, doch nicht ganz unerheblich.

Glücklicherweise unterstützt Xcode bzw. das integrierte Instruments die Suche nach Memory-Leaks. Ein sehr schöne Anleitung findet man unter http://www.cimgf.com/2008/04/02/cocoa-tutorial-fixing-memory-leaks-with-instruments/

© 2012 JerryWho Suffusion theme by Sayontan Sinha