Versions – Versionskontrolle mit Subversion

Versions-Icon
Versions-Icon

Veränderungen im Leben bringen mich nun dazu, nicht mehr Git als Versionskontrolle einzusetzen, sondern auf Subversion umzusteigen. Während ich Git komplett aus dem Terminal bedient habe, verwende ich bei Subversion nun eine Mac-App namens Versions.

Anfangs war ich skeptisch, denn bei vielen derartigen Produkten verbirgt das GUI mehr von der Funktionalität als sie ermöglicht, aber die etwas geringere Kontrolle mache ich nun mit einer deutlich schnelleren Übersicht der Änderungen wieder wett. Ja, man kann sich an Versions gewöhnen.

Auch wenn ich ein Fan von Git bin, komme ich mit Subversion gut klar – trotz der unterschiedlichen Philosophien der beiden Versionskontroll-Systeme. Wer sich in beide mal einlesen möchte, kann bei der Wikipedia beginnen:
Deutsche Git-Wikipedia-Seite
Deutsche Subversion-Wikipedia-Seite

Xcode beschleunigen (update)

Xcode beschleunigen
Skript im Terminal

Mit der Zahl der Projekte in Xcode hat Apples IDE immer mehr Verwaltungsaufwand, was die Anwendung nach einer Weile träger werden lässt. Diese Trägheit lässt sich aber recht einfach beseitigen. Der Entwickler Mugunth Kumar stellt in seinem Blog eine pfiffige Möglichkeit vor, Xcode wieder zu beschleunigen.

Kumar schlägt vor den App-Ordner des iOS-Simulators zu leeren und auch das Verzeichnis „DerivedData“ von Xcode zu putzen. Da es recht mühsam ist, die beiden Verzeichnisse regelmäßig händisch zu pflegen, erweist sich hierzu ein kleines Skript als nützlich:

In einer reinen Textdatei namens „xcode-cleanup.sh“ speichern wir die Zeilen:
rm -r ~/Library/Application Support/iPhone Simulator/5.1/Applications
mkdir ~/Library/Application Support/iPhone Simulator/5.1/Applications
rm -r ~/Library/Developer/Xcode/DerivedData
mkdir ~/Library/Developer/Xcode/DerivedData

Anschließend öffnen wir das Terminal und machen das Skript ausführbar, indem wir im Terminal zum Ort des Skripts navigieren und folgenden Befehl ausführen:
chmod +x xcode-cleanup.sh

Ausführen lässt sich die Datei mithilfe des Terminals. Darin muss man sich ins Verzeichnis, in dem das ausführbare Skript liegt, bewegen. Dort tippt man
./xcode-cleanup.sh
und Xcode ist läuft nun wieder schneller und stabiler.

Update
Wie man an dem Bereich „Simulator/5.1“ erkennen kann, gilt dieses Skript nur für die iOS-Version 5.1 im Simulator.
Für 6.0 habe ich es entsprechend ergänzt:

rm -r ~/Library/Application Support/iPhone Simulator/5.1/Applications
mkdir ~/Library/Application Support/iPhone Simulator/5.1/Applications
rm -r ~/Library/Application Support/iPhone Simulator/6.0/Applications
mkdir ~/Library/Application Support/iPhone Simulator/6.0/Applications
rm -r ~/Library/Developer/Xcode/DerivedData
mkdir ~/Library/Developer/Xcode/DerivedData

CPU, Mac-Modell, RAM und mehr auslesen

CocoaDev

Der Mac weiß, welche aus welchen Bestandteilen er besteht: Falls man also wissen möchte, auf welchem Mac-Modell das eigene Programm läuft oder welcher Prozessor seinen Dienst verrichtet oder wie viel RAM eingebaut sind, lässt sich der Befehl sysctl hervorragend einsetzen.

Die Seite CocoaDev hat eine derzeit nicht ganz aktuelle Übersicht aller Intel-Macs im NSDictionary-Format. Außerdem gibt es verschiedene Code-Beispiele, wie sich sysctl produktiv einsetzen lässt.

Ich hätte mich gerne hingesetzt und die Liste der Macs aktualisiert, aber CocoaDev setzt eine vorhergehende Registrierung voraus und das hat mich abgeschreckt.

Seiten wie everymac.com oder die hervorragende App MacTracker bieten eine gute Übersicht aller Macs. Insofern wäre es nicht schwierig, das NSDictionary auf der Seite zu ergänzen.

NSLog gibt den Namen der aktuellen Methode aus

NSLog-Ausgabe

NSLog ist die Allzweckwaffe, wenn es darum geht, während des Ablaufs des Programms Meldungen über Zustände auszugeben. Methodenaufrufe, Variablen-Werte und einiges mehr lassen sich ausgeben.

Eine schöne Möglichkeit, durch einen Aufruf von NSLog einfach den Namen der aktuellen Methode in der Konsole ausgeben zu lassen, ist folgende:

NSLog(@"<<< BIN IN %s >>>", __PRETTY_FUNCTION__);

In diesem Beispiel schreibt NSLog zuerst „<<< BIN IN“ hin, wechselt in eine neue Zeile, schreibt den Namen der aktuellen Methode und schließt mit „>>>“. Die Kleiner-Größer-Zeichen sind nur dazu da, um in den ganzen Ausgaben auf der Konsole diese NSLog-Ausgaben auffälliger zu gestalten.

In-App-Purchase Tutorials, Hinweise und der wichtigste Tipp überhaupt

In-App-Purchase
In-App-Purchase

Es gibt viele gute Tutorials, wie man die In-App-Purchase-Funktionalität in die eigene iPhone- oder iPad-App einbindet. Entgegen einiger kursierender Mythen ist es nicht notwendig, die Product IDs der In-App-Purchases so ähnlich wie die der Haupt-App zu setzen. Außerdem lässt sich die Funktionalität der In-App-Purchases auch im Simulator testen, es ist also nicht zwingend notwendig, die App auf ein Gerät zu laden.

Ich möchte hier drei Anleitungen besonders hervorheben, die mir bei der Implementierung hilfreich waren:
1. Troy Brant mit In App Purchases: A Full Walkthrough

2. Mugunth Kumar mit iPhone Tutorial – In-App Purchases

3. Ray Wenderlich mit Introduction to In-App Purchases

Der allerwichtigste Tipp aber ist: WARTEN!
Hat man die App eingerichtet und eingereicht, sind die In-App-Purchses angelegt und bereit und dennoch funktioniert es nicht, könnte es sehr wahrscheinlich daran liegen, dass die Apple-Server noch nicht soweit sind. Nach meiner Erfahrung dauert es etwa 10 h, bis die Apple-Server vollständige Kenntnis über die angelegten In-App-Purchases haben.

BOOL gut lesbar in NSLog ausgeben

SchalterFür die Lesbarkeit wäre es ein großer Vorteil, wenn man BOOL-Werte in Objective-C auch als „YES“ oder „NO“ ausgeben könnte. Von Haus aus zeigt NSLog die Werte als Integer.

Mit einer einfachen Abfage innerhalb von NSLog lassen sich Boolsche Werte aber tatsächlich als solche in der Konsole ausgeben. Die Abfage prüft den Zustand von „meinBool“ und gibt auf Basis dessen dann entweder den String „YES“ oder „NO“ aus.

Zur besseren Auffindbarkeit sind Doppelkreuze vor und hinter dem Gesamtstring eingefügt:

NSLog (@"##### Wert von meinBool = %@ #####", meinBool ? @"YES" : @"NO");

Interface Builder oder lieber doch nicht

Xcode-Interface-Builder-Kombi in Xcode 4

Als ich meine ersten Schritte mit der Kombination Xcode und Interface Builder machte, fiel mir die Verwendung von Interface Builder sehr schwer. Ich habe einfach nicht verstanden, was da passiert, wenn ich einen UIButton respektive einen NSButton auf das mir angebotene Fenster gezogen habe. Was „IBAction“ oder „IBOutlet“ sind, blieb mir auch einfach ein Rätsel. Ich war so froh, als ich sah, dass man das UI auch programmatisch erstellen kann.

Mit meinem Problem war ich aber nicht allein. Entwickler Ben Teese leitet seinen Blog-Post mit diesen Worten ein: „I don’t understand why you’d use Interface Builder to create a UI for an iPhone application.“
Auch Entwickler Shaun Ervine schreibt: „If you’re new to iOS development, don’t touch Interface Builder until you are capable of building UIs programatically.“

Immer wenn ich erfahrene Entwickler traf, fragte ich sie, wie sie es mit dem Interface Builder hielten und die Antwort war fast immer: „Natürlich arbeite ich mit dem Interface Builder. Ohne ist das Erstellen des UI viel zu mühsam und dauert viel zu lange.“ Hmm, am Interface Builder musste echt etwas dran sein … Ich nahm mir vor, es nochmals zu versuchen.

Apple kam mir mit Xcode 4 entgegen, denn nun hatten sie den Interface Builder in Xcode integriert und der Arbeitsfluss zwischen Code und UI kommt mir deutlich beschleunigt vor.

Nach mehreren Projekten, bei denen ich die gesamte Oberfläche programmatisch erstellt hatte, stellte ich mir so langsam die Frage, ob das zumindest bei Oberflächen-Standards nicht schneller und einfacher gehen könnte. Glücklicherweise hatte ich eine Vermutung, dass es nun anscheinend Zeit für den Interface Builder sei.

Tatsächlich bin ich nun inzwischen soweit, dass ich bei Standards schnell die Oberfläche in Interface Builder anlege, meine IBOutlets in Xcode erstelle und fix die Verbindungen ziehe. Bei etwas komplizierteren Oberflächen bin ich aber ganz froh, dass ich das UI weiterhin auch programmatisch erstellen kann. Vielleicht bin ich auch bei den Sachen bald beim Interface Builder.

Mein Tipp an Xcode-Neulinge ist dann tatsächlich ebenfalls: Wenn euch der Interface Builder anfangs verwirrt, dann lasst ihn weg und baut euer UI programmatisch. Vermutlich werdet ihr selbst merken, wann es Zeit ist, den Interface Builder einzusetzen.

Unter iOS einen UIAlertView zeigen

UIAlertView schnell erstellen
Beispiel für ein UIAlertView
Immer mal wieder kommt man in die Verlegenheit, beim Basteln mit Xcode und iOS schnell mal einen UIAlertView auf dem iPhone-Simulator anzeigen zu wollen. Und immer dann hat man gerade vergessen, wie das denn noch ging. Daher hierzu ein paar Code-Schnipsel, die einen UIAlertView darstellen.

Möchte man den Anwender nur kurz auf einen Knopf drücken lassen oder – beispielsweise bei der Fehlersuche – ausprobieren, ob das Implementierte tatsächlich funktioniert, so hilft dieses kurze Beispiel weiter:

UIAlertView *av = [[UIAlertView alloc] initWithTitle: @"Achtung" message: @"Hier ist dein Knopf." delegate: nil cancelButtonTitle:@"OK" otherButtonTitles:nil];
[av show];
[av release];

Mehr Knöpfe
Etwas aufwändiger wird es, wenn man mehr als nur einen Knopf im UIAlertView zeigen möchte.

Einen schönen Ansatz zu UIAlertViews verfolgt der Entwickler Jiva DeVoe mit seinem auf GitHub gehosteten Projekt UIAlertView-Blocks.
Geht man den von Jiva beschriebenen Weg, erspart man sich das Implementieren eines Delegates. Jiva stellt in einem Beispiel vor, wie man die UIAlertView-Blocks einsetzt.

App-Verkaufszahlen iOS vs Android vs Windows Phone 7

Unter iOS sind die Verkäufe deutlich höher
App-Verkaufszahlen iOS vs Android vs Windows Phone 7

Immer wieder taucht die Frage auf, warum man nicht alle Apps nicht nur für Apples iOS, sondern auch für Googles Android publizizieren sollte. Schließlich habe oder werde die Zahl der mobilen Geräte unter Android die der iPods touch, iPhones und iPads überholen. Was auf dem ersten Blick wie eine klare Sache aussieht, dass es nämlich eine Dummheit ist, einen solch gigantischen Markt nicht zu bedienen, erscheint bei weiterer Betrachtung als trügerisch.

Die Zahl der eingesetzten Geräte ist keineswegs gleichzusetzen mit der Zahl verkaufter Apps. Der Entwickler lesmond zeigt in seinem Blog-Eintrag anhand von Zahlen für kaufpflichtige Apps die jeweiligen Umsätze über drei Monate auf den drei Plattformen iOS, Android und Windows Phone 7. Hier zeigt sich, dass die Umsätze unter iOS drei- bis fünfmal über denen von Android liegen, wobei Android deutlich über Windows Phone 7 liegt.

Ich finde das wenig überraschend, denn nicht repräsentative Erhebung in meinem Umfeld zeigt, dass Android-Anwender entweder Apple-Hasser sind oder sich das iPhone nicht leisten möchten. Vor allem der zweite Grund zeigt, dass es sich bei den mir bekannten Android-Anwendern nicht um Leute handelt, von denen sich App-Entwickler große Umsätze erhoffen können. So prahlte ein Bekannter kürzlich damit, dass er auf seinem sieben Monate alten, schicken Android-HTC keine einzige App hat, für die er Geld bezahlt hat.

Es kann sich in Zukunft ändern, aber im Moment denke ich ganz klar, dass sich die Arbeit einer Entwicklung oder Portierung für Android nicht lohnt.

Weitere Problemfelder wie beispielsweise die vorauszusetzende Android-OS-Version im Allgemeinen oder die Vielzahl der verfügbaren Bildschirmdiagonalen der Geräte mal außen vor.

Über 300.000 Apps: Apple-App-Store in Zahlen

Infografik zum App Store
Infografik zum App Store

Apple selbst liefert keine Statisktiken zu den Zahlen des App Store, so ist es dann doch eine große Freude von kompetenter Stelle ein paar aktuelle Werte zum App Store zu erhalten: Die Seite App of the Day hat sich die Mühe gemacht und eine übersichtliche Infografik erstellt:

Demnach sind derzeit über 300.000 Apps im App Store für iPhone, iPad und iPod touch verfügbar. Von denen sind ein Drittel kostenlos, zwei Drittel müssen bezahlt werden. Etwa 85 Prozent der verfügbaren Apps richten sich an iPhone und iPod touch, nur 7 Prozent sind ausschließlich für das iPad erstellt. Die zur 100 fehlenden 8 Prozent sind für alle derzeit verfügbaren iOS-Geräte vorgesehen.

Erstaunlicherweise beheimatet die Kategorie „Bücher“ die meisten Apps, erst an zweiter Stelle folgen „Spiele“ – vom Gefühl her, hätte ich die „Spiele“ sofort an prominentester Stelle gesehen. Auf Platz drei und vier liegen „Unterhaltung“ und „Lernen“.

Der Durchschnittspreis über alle Apps hinweg liegt bei 2,43 US-Dollar; die Durchschnittsbewertung bei drei Sternen.

Über 62.000 einzelne Entwickler arbeiten an der Plattform mit.