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.
Wer mit git und github arbeitet, kennt die Möglichkeit, vom git branch „master“ abzuweichen und zum Experimentieren einen eigenen git branch <git_branch_name> aufzumachen. Ich wusste aber nicht, wie ich den lokal angelegten branch an github sende. Dabei ist es ganz einfach, wenn man weiß, wie es geht.
Die App wächst und gedeiht, aber nun kommt der Augenblick, in dem man eine große Änderung in die App einbauen will und nicht möchte, dass der bereits erreichte Stand der Entwicklung davon beeinträchtigt wird. Wer als Versionskontrollsystem git einsetzt, kann nun mit dem Befehl „git branch experiment“ eine Verweigung namens „experiment“ vom Hauptentwicklungsweg namens „master“ anlegen.
Das Vorgehen ist relativ klar:
1. Einen branch anlegen: git branch experiment
2. Zum neuen branch wechseln, denn auch wenn „experiment“ angelegt ist, befindet man sich weiterhin im branch „master“: git checkout experiment
3. Nun arbeitet man im branch „experiment“, macht schließlich ein add sowie ein commit: git commit -a -m "Meine kluge Commit-Nachricht"
4. Nun möchte man explizit die Arbeit im branch „experiment“ an github senden. Das geht über: git push origin experiment
Jetzt liegen die Daten bei github. Auf github gibt es links einen Menüpunkt „branch“, worunter man die einzelnen branches sehen und zu ihnen umschalten kann.
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
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.
