Monat: Montag, der 21. Februar 2011

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.