Blog

Ein Xcode Projekt unter GIT-Versions-Verwaltung stellen:

Geht am einfachsten natürlich indem man beim erzeugen mit Xcode Version 4.x schon angibt, mit Git verwalten zu wollen. Wenn man das vergessen hat, oder noch mit Xcode 3.x arbeitet kann man es mit diesen Kommandos machen:
$ cd project
$ git init
$ git add .
$ git commit [-m commit-message-text]

Nun ist alles unter Versions-Kontrolle – in der lokalen Directory !
TiPP: Damit man nicht den voreingestellten Editor bei Commit aufgerufen bekommt (bei mir ist es vi) kann man -m und die Message sagen. Vi TiPP: MitZZ (zweimal groß Z) kommt man aus dem vi wieder raus.

Das Beste ist jetzt: Wenn man das Projekt jetzt unter Xcode-4 öffnet, dann merkt Xcode gleich, dass das Projekt unter GIt-Versionsverwaltung ist.

Wie bekommt man das Projekt auf bitbucket hochgeladen?

$ git remote add origin https://<user>@bitbucket.org/<user>/<repository.git>
$ git push -u origin –all
$ git push -u origin –tags        # nur, wenn man auch tags hatte

also z.B.:
$  git remote add origin https://Small_Apps@bitbucket.org/Small_Apps/blabla.git

Wie bekommt man das Projekt auf einen lokalen Server hochgeladen?
1.) alle eigenen Änderungen speichern, testen, mit commit im Projekt abspeichern, noch mal übersetzten und noch mal testen
2.) eine Lokale Kopie des Projektes anlegen, allerdings als Server-Version:
$ # wir sind im Projekt-Directory mit Namen proj
$ cd ..
$ git clone –bare proj proj.git

Damit legen wir eine Kopie an, allerdings nur die Versionsbaum-Variante, ohne die Working-Versionen der Dateien (daher „–bare“). Es hat sichals server-name eingebürgert, daher bitte auch bei uns einhalten.

Nun kann man die Directory proj.git auf den Server verschieben oder kopieren (lassen). Etwa mit

$ mv proj.git /Volumes/Backup/Git/proj.git

Fertig!

Natürlich kann man das auch mit

$ git clone –bare proj /Volumes/Backup/Git/proj.git

sofort erledigen, aber das war jetzt sowieso allen klar.

Eine lokale Kopie des Projektes vom Server anlegen geht so:

In Xcode (Version 4.x) den Organizer aufrufen, in der Mitte oben auf den Reiter „Repositories“ gehen und dann links unten auf den Plus-Button und dann auf „Checkout or Clone Repository…“ klicken. Bei dem dann erscheinenden Dialog gibt man den Pfadnamen des Servers ein – bei uns also das bekannte

/Volumes/Backup/Git/proj.git

…und schon kann man mit den Sourcen arbeiten.

Die Änderungen auch auf den Server „hoch“-spielen:

$ cd proj
$ git push /Volumes/Backup/Git/proj.git

Die Änderungen vom Server herunter-Kopieren geht dementsprechend mit:

$ cd proj
$ git pull /Volumes/Backup/Git/proj.git

ich hoffe, ich habe nichts vergessen.

Damit meinen Kunden klar ist, dass die Applikation, die angeblich von mir ist, auch wirklich von mir ist, sind sie alle von mir zertifiziert. Das ist nichts au?ergewöhnliches: Jede Applikation, die für das iPhone entwickelt wird, hat ein Zertifikat.

Während der Entwicklung ist es einfach: Man holt sich ein „Team development certificate“ in dem „iOS provisioning portal“, kombiniert das mit den Namen der erlaubten Geräte und Leute und schon kann man loslegen. Das war nicht immer so, aber seit einiger Zeit gibt es ein Development auto provisioning, will sagen: Wenn man eine App geschrieben hat und die auf einem als Develpment Device identifiziertem Gerät laufen lassen will, dann macht Xcode das inzwischen automatisch für einen.

Problematisch ist nur, wenn man den Typen am anderen Ende der Welt die Software testen lassen will: Apple nennt diese art von App Verteilung „Ad hoc“ distribution und man muss extra dafür ein zweites Provisioning Profile erstellen und installieren. Dann kann man dem Tester mit der Applikation zusammen dieses Provisioning Profile schicken und er kann es ein Paar Monate lang testen. Das ist das Interessante daran: Nach ein paar Monaten läuft so ein Profil aus.

Logischerweise will man nicht, dass die App im App Store auch unter so einer Zeitbegrenzung leidet, daher gibt es auch unbegrenzte „distribution“ profiles. Hat man seine App fertig, kann man sie abschicken – zum Beispiel indem man sie in Xcode archiviert und dann von dort aus verschicken lässt. Soweit so gut.

Dabei kann man sich natürlich selber reinlegen. Wenn man die Apple Hinweise nicht Punkt für Punkt einhält, kann es schon mal sein, dass man mit „illegal Binary“ abgewiesen wird. Bei mir war der Fall einfach: Hoppla, hatte aus Versehen das adhoc profil ausgewählt. Korrigiert, erneut abgeschickt und schon war das Binary akzeptiert und bei Apple zum Review.

Wenn ich eine Zahl in einem Dialogfenster darstellen will, ist es oft eine gute Idee, die Zahl schon in die Default Einstellungen des Dialogs (in den .nib bzw. .xib Files) vorzunehmen. Aber was, wenn ich Komma-Zahlen habe? Dann muss ich je nach Landeseinstellungen etwas anderes ausgeben.

Nun darf man die Entscheidung Komma oder Punkt leider nicht von der Sprache abhängig machen, denn die Spanier schreiben mit Komma, die Mexikaner aber mit Punkt. Daher unterscheidet iOS ja auch zwischen der Sprach-Einstellungen und Einstellung der Region.

Und damit das alles gut geht, dafür gibt es in iOS Funktionen. Statt initwithformat: Gibt es auch Initwithformat:locale:, eine Funktion, die netterweise das Komma oder den Punkt richtig setzt.

Damit sind Kommazahlen aber nicht mehr für .xib Files geeignet, denn die will man ja nur sprachspezifisch machen, um Ihre Anzahl nicht zu groß werden zu lassen. Daher behilft man sich, indem man die Zahl in den Xib Files leer lässt und dann beim Laden des Xib-files in viewdidload die Zahl korrekt formatieren.

 

„APT“ soll für „App programmier Tipps“ stehen. Damit sollen diese Artikel leichter von den anderen Beiträgen in diesem Blog unterscheidbar sein. Für den Fall, dass man sie mal alle nacheinander ansehen will.

Nehmen wir mal an, Du hast eine Applikation im Apple Store, die nur in einer Sprache erhältlich ist. Nun steht eine neue Version an und Du freust Dich, dass Du eine feine Übersetzung für Deine Texte hast. Mit wenigen Klicks und Stundenlangem tippen ist es so weit:

und….

Die alten Texte erscheinen immer noch – egal, auf welche Sprache DU umschaltest. Das liegt daran, dass Du den Namen Deiner Ressourcen gleich gelassen hast und in der Bundle Direktory noch die alte, nicht lokalisierte Version rumliegt – und die wird dummerweise zuerst gefunden!
Jetzt gibt es zwei Möglichkeiten:
1.) Die Installation auf Deinem iPhone oder Simulator zu löschen – dann sind die alten Versionen weg.
2.) Wenn löschen keine Lösung ist, weil dann Daten weg sind: Die Resource-Dateien umbenennen. Aber Vorsicht – keine nicht-lokalisierte Version der Datei mit dem neuen Namen ausprobieren, sonst hat man die auch auf dem Gerät.
3.) Als Dritte von zwei Lösungen kann man auch noch dem schönen InitWithNibName die richtige Datei geben. Die bekommt man mit Hilfe des Arrays „PreferredLocalizations“ aus dem Bundle.

NSBundle* bundle = [NSBundle mainBundle];
NSString *nibname =
[NSString stringWithFormat:@“%@.lproj/FlipsideView“, [[bundle preferredLocalizations]objectAtIndex:0]];

Nun ja, da direkt in den Index 0 zu gehen ist nicht die 100% Feine Art, aber da man ja den Pointer den man vom InitwithNibName bekommt überprüft (das macht Ihr doch alle, oder?) kann man das so lassen und im Falle, dass die Datei nicht da ist, noch mal ohne Lokalisation nachfragen.

Laut Dokumentation ist garantiert: Dass Deine Kunden die alte Datei auch gelöscht bekommen. Allerdings: Es gab Leute im Internet, die behaupten, sie hätten dieses Problem nach dem Installieren der neuen Version. Leider kann ich nicht nachprüfen, ob die ein anderes, oder genau dieses Problem haben – Vorsicht ist aber besser als die App zweimal einreichen müssen habe ich mir gedacht und mal eben die dritte Methode implementiert.

Kommentare willkommen!
Gruß, Thomas

P.s.: Nein, von der App aus löschen kann man die Datei nicht – die BUNDLE-Directory ist aus der Sicht der App schreibgeschützt.