3.4 Eine App für alle

Im Springboard, das ist der Home-Screen unter iOS, über den Sie Apps starten, erscheint für Ihre App nur ein weißes, abgerundetes Quadrat mit einem Glanzeffekt und dem Namen AlarmClock. Sie können natürlich auch ein eigenes Icon anzeigen lassen. Das Bild muss im PNG-Format in den folgenden Größen vorliegen:

Wenn Sie die Dateien icon.png und icon@2x.png nennen, brauchen Sie diese einfach nur zu Ihrem Projekt hinzufügen. iOS erkennt diese Dateien automatisch und zeigt sie im Springboard an. Alternativ können Sie die Icons auch über die Target-Einstellungen festlegen. Unter dem Tabulator Summary (siehe Abbildung 3.40) finden Sie dort zwei Platzhalter, über die Sie per Kontextmenü die App-Icons auswählen können. Falls Ihre App iPhones und iPads unterstützt, können Sie dort bis zu vier unterschiedliche Icons angeben, wobei es für das iPad eine eigene Rubrik gibt.

Abbildung 3.40 Einfügen der App-Icons

Um die abgerundeten Ecken und den Glanzeffekt in Ihren Icons brauchen Sie sich nicht zu kümmern. Das macht das Springboard für Sie, wofür Abbildung 3.41 ein Beispiel enthält.

Abbildung 3.41 Das App-Icon als Original (links) und im Springboard (rechts)

3.4.1 Das Retina-Display

Die iPod-touch-Modelle, die 2010 erschienen, das iPhone 4/4S und das iPad der dritten Generation besitzen Retina-Displays, die gegenüber den Vorgängermodellen die doppelte Auflösung bei gleichen Displaymaßen besitzen. Während die Standarddisplays des iPhone 3GS und der ersten beiden iPad-Modelle 320 × 480 beziehungsweise 768 × 1024 Pixel darstellen können, besitzen die Retina-Displays eine Auflösung von 640 × 960 beziehungsweise 1536 × 2048 Pixeln. Auch das iPhone 5 und die gleichzeitig erschienenen iPods besitzen Retina-Displays, die hingegen eine Auflösung von 640 × 1136 Pixeln haben. Die höhere Auflösung ist für eine größere Detailgenauigkeit gedacht. Viele UI-Elemente wie beispielsweise Buttons und Labels passt das iOS automatisch an die Auflösung an.

Bei Bildern geht das natürlich nicht automatisch. Hier müssen Sie eine Version des Bildes für die höhere Auflösung bereitstellen. Dazu brauchen Sie das Bild in der doppelten Breite und Länge. Wenn also ein Bild in der normalen Auflösung beispielsweise die Größe 124 × 93 Pixel hat, hat das entsprechende Bild für das Retina-Display die Größe 228 × 186 Pixel.

Das iOS verwendet die Retina-Version des Bildes automatisch, wenn Sie den gleichen Dateinamen mit dem Zusatz @2x vor der Dateiendung verwenden. Heißt beispielsweise das Bild für die Standardauflösung Bild.png, dann ist der Name für die hohe Auflösung Bild@2x.png. Das gilt für alle Bilder, die Sie über den Interface Builder einem UI-Element zuweisen oder die Sie mit dem Convenience-Konstruktor imageNamed: der Klasse UIImage laden. Wenn Sie dagegen keine Retina-Version bereitstellen, skaliert Cocoa Touch einfach die Bilder für die normale auf die hohe Auflösung.

CGSize theLogicalSize = theImage.size;
CGFloat theScale = theImage.scale;
CGSize thePhysicalSize = CGSizeMake(
    theScale * theLogicalSize.width,
    theScale * theLogicalSize.height);

Das kleine Beispielprojekt Retina auf der beiliegenden DVD soll das Prinzip veranschaulichen. Sie finden es auf der DVD unter Code/iPhone/Apps/Retina und im Git unter der URL https://github.com/Cocoaneheads/iPhone/tree/Auflage_2/Apps/Retina. Es enthält zwei Bilder mit unterschiedlichem Inhalt für die beiden Auflösungen, um den Mechanismus zu verdeutlichen. Es gibt jeweils zwei Dateien pro Bild, sodass es insgesamt vier Dateien (both.png, both@2x.png, normal.png und retina@2x.png) gibt. Dabei sollen die beiden letzten Dateien das Verhalten von Cocoa Touch illustrieren, wenn Bildvarianten fehlen. Im Interface Builder oder im Programmcode verwendet es hingegen immer nur die Dateinamen ohne den Zusatz @2x. Die Ausgabe des Beispielprogramms für das Standard- und das Retina-Display können Sie in Abbildung 3.42 sehen.

Bei dem Bild both.png verhält sich die App wie beschrieben. Sie verwendet die Datei both.png für die Standardauflösung und both@2x.png für die Retina-Auflösung. Liegt das Bild hingegen nur in der normalen Auflösung vor, verwendet die App für beide Display-Typen das gleiche Bild (also normal.png). Das gilt analog für Bilder, die nur in der Retina-Auflösung vorhanden sind (Bild retina.png).

Wenn Sie die Display-Auflösung im Programmcode unterscheiden wollen, sollten Sie das hingegen nicht anhand der Display-Größen machen, da ja Apple iPhones mit anderen Auflösungen aufwarten. Die Anzahl und die Größe der Pixel eines Displays sind ja schließlich zwei vollkommen voneinander unabhängige Werte. Wenn Sie die Display-Auflösung ermitteln wollen, können Sie dazu die Methode scale der Klasse UIScreen verwenden. Das Screenobjekt zum Display erhalten Sie über die Klassenmethode mainScreen, sodass Sie den Skalierungsfaktor über [[UIScreen mainScreen] scale] bestimmen können. Auf Standarddisplays hat der Skalierungsfaktor den Wert 1 und auf Retina-Displays den Wert 2. Das Beispielprogramm zeigt diesen Wert ebenfalls an.

Abbildung 3.42 Ausgabe der App »Retina« für die Standard- und die Retina-Auflösung

3.4.2 Sprachkursus für die App

Wenn Sie Ihre App in mehreren Ländern vertreiben möchten, sollte sie neben deutschen zumindest auch englische Texte anzeigen können. Sie sollten also Ihre App lokalisieren. Im Wesentlichen müssen Sie dazu die enthaltenen Texte übersetzen und so in Ihr Programm einbauen, dass die App in Abhängigkeit von der gewählten Sprache des Nutzers die richtige Variante anzeigt. Das ist unter iOS nicht so aufwendig, wie es sich vielleicht anhört. Cocoa Touch unterstützt die Lokalisierung bereits – allerdings nur für unterschiedliche Sprachen. Sie können nicht nach Ländern oder Regionen lokalisieren. Damit sind also beispielsweise keine getrennten Varianten für Hochdeutsch, österreichisches oder schweizerisches Deutsch möglich.

In der Wecker-Applikation gibt es drei Stellen, an denen Texte vorkommen können:

1. in der XIB-Datei
2. im Programmtext
3. im Programmnamen

Bei größeren Projekten müssen Sie häufig auch noch Programmressourcen wie Bilder, Töne oder andere Dokumente lokalisieren. Beispielsweise könnten Sie in der englischen Version der App das Läuten von Big Ben verwenden.

Der Lokalisierungsmechanismus unter Cocoa Touch ist relativ einfach. Für jede Sprache enthält die App einen eigenen Ordner, in dem die Ressourcendateien für die entsprechende Sprache liegen. Sie müssen jedoch nicht unbedingt alle Ressourcen lokalisieren und auch nicht für jede Sprache eine lokalisierte Variante anlegen. Wenn iOS zu einer Sprache eine Ressource nicht findet, nimmt es die entsprechende Ressource der Standardsprache. Die Standardsprache ist in der Regel Englisch.

Über den Dateiinspektor ( + + ) in Xcode können Sie sehen, für welche Sprachen es Varianten der Datei gibt. Wenn Sie eine Datei noch nicht für die Lokalisierung freigegeben haben, erscheint hier nur der Button Make localized..., mit dem Sie das nachholen können.

Abbildung 3.43 Lokalisierung im Dateiinspektor

Seit Xcode 4.4 verwalten Sie die Lokalisierungen zentral über das Projekt; das heißt, Sie legen in den Projekteinstellungen fest, welche Sprachen Ihre App unterstützt (siehe Abbildung 3.44).

Abbildung 3.44 Sprachvarianten der App festlegen

Wenn Sie über den Plusbutton eine neue Sprache auswählen, fragt Xcode Sie in einem Dialog, von welchen Dateien es Varianten für die ausgewählte Sprache anlegen soll (siehe Abbildung 3.45). Sie können diese Auswahl jedoch nachträglich jederzeit über die Checkboxen (siehe Abbildung 3.43) im Dateiinspektor wieder ändern.

Abbildung 3.45 Dateien für eine Sprachvariante auswählen

Sobald Sie eine Datei lokalisiert haben, erscheint vor dem Namen der Datei in der linken Seitenleiste ein Dreieck, mit dem Sie die Ressource aufklappen können. Dort finden Sie dann deren unterschiedliche Sprachvarianten. Sie können die Varianten öffnen und die darin enthaltenen Texte entsprechend anpassen.

Die Texte im Programmcode können Sie auf eine ähnliche Weise anpassen, wobei Sie natürlich keine Varianten der Objective-C-Dateien anlegen. Sie müssen vielmehr Ihren Quelltext geringfügig ändern, sodass die App die Texte auch aus einer speziellen Textdatei lädt. Dazu schreiben Sie um Ihre Zeichenketten den Makroaufruf NS-LocalizedString. Beispielsweise können Sie in Listing 3.43 die Zuweisung für den Nachrichtentext durch folgende Zeile ersetzen:

theNotification.alertBody = 
    NSLocalizedString(@"Wake up", @"Alarm message");

Listing 3.51 Lokalisierung eines Textes im Programm

Der erste Parameter enthält den Text, den Sie lokalisieren möchten. Mit dem zweiten Parameter können Sie einen Kommentar angeben, der den Text beschreibt. Der Inhalt des zweiten Parameters hat keine sichtbare Auswirkung auf Ihr Programm. Wenn jetzt eine Benachrichtigung erscheint, zeigt sie allerdings die Meldung »Wake up« an.

Durch die Verwendung des Makros können Sie jetzt den Text aus einer Textdatei laden. Die lokalisierbaren Texte bringen Sie in der Datei Localizable.strings unter. Sie können sich diese Datei über das Kommandozeilenprogramm genstrings automatisch erzeugen lassen. Wechseln Sie dazu im Terminalprogramm in den Projektunterordner Ihrer App, wo die Klassendateien liegen. Dort geben Sie den Befehl

genstrings -o en.lproj *.m

ein. Dieser Aufruf erzeugt die Datei Localizable.strings in dem Unterordner en.lproj, die Sie danach über einen Rechtsklick auf Supporting Files und den Aufruf von Add Files to "AlarmClock"... zu Ihrem Projekt hinzufügen. Achten Sie dabei im folgenden Dialog darauf, dass Sie das Häkchen vor AlarmClock unter Add to target setzen. Die Datei sollte die Kodierung Unicode (UTF-16) besitzen. Das können Sie im Dateiinspektor unter der Rubrik Text Settings in der Einstellung Text Encoding überprüfen.

Wenn Sie die Datei in Xcode öffnen, sieht sie ungefähr so aus:

/* Dismiss alert */
"OK" = "OK";
/* Alarm message */
"Wake up" = "Wake up";

Listing 3.52 Inhalt einer »Localizable.strings«-Datei

genstrings erzeugt die Kommentare in der ersten und dritten Zeile aus den Kommentarparametern der Makroaufrufe. Die zweite und vierte Zeile enthalten Textzuweisungen, wobei die linke Seite der Schlüssel und die rechte der Wert ist. Sie sollten also die linke Seite möglichst nicht verändern, da sie genau dem betreffenden Text im Makroaufruf entsprechen muss. Auf der rechten Seite können Sie einen beliebigen Text in die doppelten Hochkommata schreiben. Hier dürfen Sie die übliche Maskierung mit einem vorangestellten Backslash für Sonderzeichen (beispielsweise \" für " oder \u20AC für €) verwenden (Escape-Sequenzen).

Im Programmtext sollten Sie wie im Beispielprogramm lieber englische Texte verwenden, da sowohl der Objective-C-Compiler als auch das Programm genstrings Probleme mit Umlauten haben kann.

Den Namen der App können Sie an verschiedene Sprachen anpassen. Dazu verwenden Sie die Ressource InfoPlist.strings, die Xcode 4 schon bei der Projekterzeugung angelegt hat. Diese Datei dient zur Lokalisierung der Datei Info.plist, auf die wir später noch eingehen. Von dieser Strings-Datei können Sie natürlich auch für jede Sprache eine eigene Variante anlegen. In die deutsche Variante schreiben Sie Folgendes:

"CFBundleDisplayName" = "Wecker";

Dadurch stellen Sie den deutschen Namen Ihrer App auf »Wecker« um. Analog können Sie natürlich auch den englischen Namen anpassen.

3.4.3 Es funktioniert nicht

Sie haben alle Anweisungen befolgt und alles noch mal überprüft, und trotzdem zeigt der Simulator nur eine Sprachvariante Ihrer App an. Keine Sorge, Sie haben keinen Fehler gemacht. Dieses Problem entsteht dadurch, dass Ihre App noch die alten Dateien findet. Um dieses Problem zu beheben, müssen Sie alle Reste der Vorversionen Ihrer App löschen. Entfernen Sie dazu die App aus dem Simulator, und öffnen Sie den Organizer in Xcode über den Menüpunkt Organizer unter Window. Dort finden Sie unter Projects auch Ihr Projekt. Löschen Sie dort über den Button Delete die generierten Daten (Derived Data) des Projekts. Falls Sie damit keinen Erfolg haben, müssen Sie die Daten über den Finder löschen. Sie finden sie im Pfad Library/Developer/Xcode/DerivedData/ unterhalb Ihres Homeverzeichnisses. Löschen Sie dort alle Ordner, die mit dem Namen Ihrer App beginnen.

Unter OS X 10.7 (Lion) ist der Library-Ordner versteckt. Sie können sich den Pfad im Finder über Gehe zu • Gehe zum Ordner... (oder mit + + ) anzeigen lassen, wenn Sie im Dialog ~/ Library/Developer/Xcode/DerivedData eingeben. Achten Sie bei der Eingabe auf die Tilde (~) am Anfang – sie steht für Ihr Homeverzeichnis.

Sie sollten außerdem die Target-Zugehörigkeiten der Dateien im Dateiinspektor unter der Rubrik Target Membership überprüfen. Dort sollte jeweils das Häkchen vor AlarmClock für alle Localizable.strings-, InfoPlist.strings- und XIB-Dateien gesetzt sein.

Abbildung 3.46 Überprüfung der Target-Zugehörigkeit

Kapitel 5, »Daten, Tabellen und Controller«, behandelt noch eine Variante für die Lokalisierung, mit der Sie auf Varianten der XIB-Dateien verzichten können.

3.4.4 Launch-Images und iPhone 5

Wenn Sie den Wecker im Simulator oder auf einem iPhone starten, sehen Sie zunächst einen schwarzen Startbildschirm, bevor das Ziffernblatt erscheint. Diese Zeit, in der Sie schwarzsehen, braucht das iOS, um Ihre App zu laden und zu initialisieren.

Sie können diese Ladezeit jedoch für den Nutzer auch etwas angenehmer gestalten, indem Sie ihm ein schönes Bild zeigen. Dabei ist »ein Bild« gelinde gesagt eine Untertreibung, da Sie für die Unterstützung aller Gerätefamilien insgesamt sieben Bilder in unterschiedlichen Formaten erstellen müssen. Tabelle 3.4 enthält die Bildgrößen und die Dateinamen für diese Launch-Images.

Die Bilddateien fügen Sie über die Target-Einstellungen zu Ihrer App hinzu, die Sie öffnen, indem Sie im Dateinavigator das Projekt und in der Spalte daneben unter Targets den Punkt AlarmClock auswählen. Dort finden Sie zu jeder Gerätefamilie unter der Rubrik Launch Images mehrere Felder, auf die Sie Ihre Bilder für den Startbildschirm ziehen können. Xcode zeigt in diesen Feldern auch eine Vorschau der vorhandenen Launch-Images an (siehe Abbildung 3.47).

Abbildung 3.47 Lauch Images in den Target-Einstellungen

Bis iOS 5 war die Angabe von Launch-Images optional. Das hat Apple mit iOS 6 und dem iPhone 5 geändert, da das Betriebssystem anhand des Launch-Images erkennt, ob die App die Auflösung des iPhone 5 unterstützt. Wenn kein Launch-Image für diesen Gerätetyp vorhanden ist, geht das iOS davon aus, dass die App die entsprechende Screenauflösung nicht unterstützt. Sie zeigt dann im Hochformat [Im Querformat zeigt sie entsprechend schwarze Ränder auf der rechten und linken Seite an.] am oberen und unteren Rand einen schwarzen Balken an, sodass die App in einer Bildschirmauflösung von 640 × 960 Pixeln beziehungsweise 320 × 480 Punkten läuft. Dadurch stellt Apple sicher, dass das iPhone 5 auch ältere Apps ohne Verzerrungen oder falsch angeordnete Views ausführen kann.

Falls Sie eine ältere App auf die Auflösung des iPhone 5 migrieren möchten, müssen Sie also dafür zunächst ein Launch-Image bereitstellen, damit die App auch den kompletten Bildschirm ausnutzt. Wenn Sie ein neues iPhone-Projekt mit Xcode 4.5 anlegen, enthält es bereits drei schwarze Launch-Images für die jeweiligen Auflösungen. Dadurch haben Sie zwar einen schwarzen Startbildschirm wie bisher, dafür unterstützt die App jedoch direkt auch das 4-Zoll-Display des iPhone 5.

Das Launch-Image für das iPhone 5 schaltet allerdings nur den vollen Bildschirm für die App frei. Die App passt daraufhin jedoch noch lange nicht die Inhalte richtig an diese neue Größe an, wie Sie am Beispielprojekt AlarmClock sehen können: Das Ziffernblatt ist oval verzerrt (siehe Abbildung 3.48).

Abbildung 3.48 Verzerrtes Ziffernblatt auf dem iPhone 5

Diese Verzerrung können Sie verhindern, indem Sie in der Methode viewWillAppear: der Klasse AlarmClockViewController die Höhe des Views korrigieren. Dazu fügen Sie die drei hervorgehobenen Zeilen aus Listing 3.53 in die Methode ein.

- (void)viewWillAppear:(BOOL)inAnimated {
    [super viewWillAppear:inAnimated];
    CGRect theFrame = self.clockView.frame;

    theFrame.size.height = theFrame.size.width;
    self.clockView.frame = theFrame;
    [self updateViews];
}

Listing 3.53 Korrektur der Viewhöhe für das iPhone 5

3.4.5 Universelle Apps

Sie haben eine App für das iPhone entwickelt, die Sie auch im iPad Simulator ausführen können. Um das auszuprobieren, müssen Sie nur vor dem Start der App im Dropdown-Menü oben links in Xcode den Punkt iPad Simulator (in der jeweils installierten Version) auswählen. Allerdings zeigt der Simulator Ihre App nicht über die komplette Bildschirmfläche, sondern nur in einem Fenster. Der iPad Simulator hat die App in seinem internen iPhone Simulator gestartet.

Um Ihr Programm auch auf dem Tablet als echte iPad-App starten zu können, müssen Sie die Konfiguration der App verändern. Dazu öffnen Sie das Target Ihrer Applikation (siehe Abbildung 3.40) und wählen in dem Dropdown-Menü Devices den Punkt Universal aus. Im Gegensatz zu älteren Projekten nimmt Xcode seit Version 4.2 bis auf die grundsätzliche iPad-Unterstützung dabei keine weiteren Programmänderungen vor.

Wenn Sie Ihre App jetzt im iPad Simulator starten, belegt sie den kompletten Bildschirm. Allerdings ist das Ziffernblatt ein Oval, und nicht alle Elemente befinden sich an der gewünschten Position. Das liegt am Autosizing der Elemente, das das Verhalten ihres Views bei Größenveränderung festlegt. In Kapitel 5 gehen wir darauf genauer ein.

Der View für das Ziffernblatt sollte quadratisch sein, damit das Ziffernblatt ein Kreis und keine Ellipse ist. Dazu legen Sie für das iPad eine eigene XIB-Datei mit den richtigen Größen an. Fügen Sie zunächst über den Menüpunkt New File... eine neue XIB-Datei hinzu. Sie finden die richtige Vorlage mit dem Namen View im Dialog unter iOS • User Interface. Achten Sie beim Anlegen darauf, dass Sie den View für das iPad anlegen, und nennen Sie die neue Datei AlarmClockViewController-iPad.xib.

In der neuen Datei legen Sie die gleichen Views wie in den XIB-Dateien für das iPhone an. Die Datei im Beispielprojekt enthält hingegen größere Labels, und das Ziffernblatt hat eine für das iPad-Display angepasste Größe. Sie können die View-Hierarchie auch einfach aus der XIB-Datei für das iPhone kopieren.

Damit das iPad die neue XIB-Datei auch findet, müssen Sie den Code in der Methode application:didFinishLaunchingWithOptions: anpassen. Je nach Gerätetyp müssen Sie dort eine andere NIB-Datei laden. Die Unterscheidung können Sie anhand der Property userInterfaceIdiom der Klasse UIDevice treffen. Cocoa Touch kennt dafür zurzeit nur die Werte UIUserInterfaceIdiomPhone und UIUserInterfaceIdiomPad.

if([[UIDevice currentDevice] userInterfaceIdiom] == 
    UIUserInterfaceIdiomPad) {
    self.viewController = [[[AlarmClockViewController alloc]
        initWithNibName:@"AlarmClockViewController-iPad"
        bundle:nil] autorelease];
}
else {
   self.viewController = [[[AlarmClockViewController alloc]
        initWithNibName:@"AlarmClockViewController"
        bundle:nil] autorelease];
}

Listing 3.54 Laden einer NIB-Datei in einer universellen App

Durch diese Änderung lädt Ihre App beim nächsten Start auf dem iPad den dafür angepassten View. Im Gegensatz zu den XIB-Dateien können Sie jedoch die gleiche Viewcontroller-Klasse auch für das iPad verwenden.

Abbildung 3.49 Darstellung des Weckers auf dem iPad

Um die Anpassungen für das iPad noch abzurunden, sollten Sie die neue XIB-Datei auch lokalisieren und ein Icon für die iPad-Auflösung (siehe Tabelle 3.3) bereitstellen. Xcode hat für das Target der App einen neuen Bereich, iPad Deployment Info, angelegt. Dort finden Sie ein Feld, über das Sie das Icon für das iPad festlegen können.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.