Kategorie: APT – App Programming Tipps

Time Machine ist schon ein geniales Programm mit einer Tollen, intuitiven Oberfläche. Auf dem Foto sieht man sie.

ich habe normalerweise sehr viel Freude an Time Machine, aber manchmal ärgert es mich. So geschehen im Oktober 2010, und so schon öfter mal geschehen, wenn es rumnörgelte – zum letzten mal gestern. Doch der Reihe nach.

Der Grund, warum auf dem Foto Oben nur Oktober 2010 als ältestes Backup steht und nicht etwa August 2009, wie es eigentlich davor war, lag daran, dass Time Machine überhaupt nicht damit klar kam, dass ich eine neue Festplatte im Rechner hatte – die alte Festplatte war schlicht voll geworden. Ich hätte mich erinnern müssen, dass Time machine das nicht mag – entweder, weil mein neues Dateisystem diesmal groß-Kleinschreibung unterschied, oder generell, weil Time Machine die Backups unter einer Platten-ID speichert. Ob es auch einen Weg um diese Probleme herum gibt, weiss ich nicht, ich hatte jedenfalls nicht danach gesucht und war daher in die Falle getappt.

ein Umzug auf eine neue Festplatte (mein dritter Umzug) ist ja unter MAC OS X sehr einfach. Kaum war er erledigt, legte Time Machine los. Leider ohne, dass ich mitbekam, was ablief: Denn Time Machine wollte ein Full Backup machen und Die Backup-Festplatte hatte nicht mehr genug freien Speicher. Daher löschte Time Machine erst mal alle alten Backups, in der Hoffnung, genug platz zu finden. Das tat es dann auch schließlich – als nur noch wenige Tage Backup übrig waren.

Zwischendurch fragte es mich um Erlaubnis – und ich sagte dummerweise auch noch ja… Als ich merkte, was vor sich ging, da waren die alten Backups schon weg. Blöd gelaufen. Gut dass ich noch andere Backups an einer anderen Stelle mache. Also: Backup komplett löschen (der eine Tag kostet auch nur Platz) und neu angefangen.

Seitdem lief es aber rund. Gestern stellte ich fest, dass ein anderer Rechner Probleme mit Backup hatte – immer wieder brach das backup mit dem fehler: Backup failed with error 11 (oder so ähnlich) ab. Und das seit Tagen.

Time machine empfahl die Überprüfung des Backup-Laufwerks auf Fehler. Gute Idee, brachte aber nichts, Time Machine scheiterte wieder. Was tun?

Backup Fehler werden in der System-Konsole gespeichert. Also
Programme-> Dienstprogramme.-> Konsole.app
geladen. Dann Ablage-> Systemprotokoll öffnen ausgewählt und nach dem Fehler geguckt. Da wurde was von Probleme mit einer Datei unter /shared …. erzählt. Immer wieder. Also da mal hin und die Eigenschaften der Datei überprüft. Nichts besonderes. Ausser: Da waren Zwei Einträge in den Zugriffseigenschaften, die sahen komisch aus. „_spotlight: Special“ oder so. Ich erinnerte mich, dass ich den ganzen Dateibaum vor Wochen unter shared dahin kopiert hatte – von meinem Rechner aus.

Offensichtlich waren dabei komische Datei-Zugriffs-Rechte in den Eigenschaften entstanden und die jetzt vielleicht teil des Problems. Einfach mal alle komischen Eigenschaften im ganzen Dateibaum Löschen, brauchen tut sie eh keiner, es sind noch genügend gute Zugriffsrechte da. Backup neu angestossen. Problem gelöst.

Wie zum Teufel soll da einer drauf kommen, der nicht mindestens IT-Erfahrung oder gar ein Informatik-Studium hat.

Danke Apple, dass ich nie Arbeitslos werde. 😉

Viel Spaß bei der ZEitreise! Gruß, Thomas

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.