Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
Vorwort
1 Hello iPhone
2 Die Reise nach iOS
3 Sehen und anfassen
4 Alles unter Kontrolle
5 Daten, Tabellen und Controller
6 Models, Layer, Animationen
7 Programmieren, aber sicher
8 Datenserialisierung und Internetzugriff
9 Multimedia
10 Jahrmarkt der Nützlichkeiten
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Apps programmieren für iPhone und iPad von Klaus M. Rodewig, Clemens Wagner
Das umfassende Handbuch
Buch: Apps programmieren für iPhone und iPad

Apps programmieren für iPhone und iPad
Rheinwerk Computing
1172 S., geb., mit DVD
49,90 Euro, ISBN 978-3-8362-2734-6
Pfeil 3 Sehen und anfassen
Pfeil 3.1 Eigene Viewklassen in Cocoa Touch
Pfeil 3.1.1 Zeichnen in Cocoa Touch
Pfeil 3.1.2 Zeitberechnung
Pfeil 3.1.3 View-Erzeugung über Storyboards
Pfeil 3.1.4 Aktualisierung der Zeitanzeige
Pfeil 3.1.5 Wiederverwendbarkeit von Views
Pfeil 3.1.6 Zeichenfarbe festlegen
Pfeil 3.2 Views und Viewcontroller
Pfeil 3.2.1 Outlets
Pfeil 3.2.2 Outlet-Collections
Pfeil 3.2.3 Containerviews
Pfeil 3.2.4 View-Hierarchien
Pfeil 3.2.5 Actions
Pfeil 3.2.6 Ereignisse
Pfeil 3.2.7 Controlzustände und Buttons
Pfeil 3.2.8 Touch-A, Touch-A, Touch Me
Pfeil 3.2.9 Übergänge
Pfeil 3.2.10 Ein kleines Intermezzo über Labels
Pfeil 3.2.11 Beliebige Objekte im Storyboard
Pfeil 3.2.12 Der Lebenszyklus eines Viewcontrollers
Pfeil 3.2.13 Speicher- und Ressourcenverwaltung des Viewcontrollers
Pfeil 3.3 Lokale Benachrichtigungen
Pfeil 3.3.1 Benachrichtigungen versenden
Pfeil 3.3.2 Benachrichtigungen verarbeiten
Pfeil 3.4 Eine App für alle
Pfeil 3.4.1 Das Retina-Display
Pfeil 3.4.2 Launch-Images
Pfeil 3.4.3 Sprachkursus für die App
Pfeil 3.4.4 Es funktioniert nicht
Pfeil 3.4.5 Unterstützung älterer iOS-Versionen
Pfeil 3.4.6 Base-Internationalisierung ausschalten
Pfeil 3.4.7 Universelle Apps
Pfeil 3.5 Geräteausrichtungen, Autosizing und Autolayout
Pfeil 3.5.1 Flexible Views dank Autosizing
Pfeil 3.5.2 Autolayout
Pfeil 3.5.3 Restriktionen im Interface-Builder festlegen
Pfeil 3.5.4 Autolayout und Lokalisierung
Pfeil 3.6 Fehlersuche
Pfeil 3.6.1 Logging
Pfeil 3.6.2 Der Debugger
Pfeil 3.6.3 Breakpoints verwalten
Pfeil 3.6.4 Die Debugger-Konsole

Rheinwerk Computing - Zum Seitenanfang

3.4Eine App für alleZur nächsten Überschrift

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 ein paar Linien darauf und dem Namen AlarmClock. Die Suche und eventuell die Einstellungen zeigen kleinere Versionen davon an. Sie können dafür natürlich auch ein eigenes Icon verwenden. Dabei hängt die Pixelgröße des Bildes sowohl vom Displaytyp als auch von der iOS-Version und der Verwendung ab.

Tabelle 3.3 Formate für das App-Icon

Displaytyp Version Verwendung Größe

iPhone, iPod touch

bis iOS 6.1

Springboard-Icon

57 × 57

Icon für Einstellungen und Suche

29 × 29

iPhone (Retina), iPod touch (Retina)

bis iOS 6.1

Springboard-Icon

114 × 114

alle

Icon für Einstellungen und Suche

58 × 58

ab iOS 7

Springboard-Icon

120 × 120

iPad

bis iOS 6.1

Springboard-Icon

72 × 72

ab iOS 7

76 × 76

alle

Icon für Suche

40 × 40

Icon für Einstellungen

29 × 29

iPad (Retina)

bis iOS 6.1

Springboard-Icon

144 × 144

ab iOS 7

152 × 152

alle

Icon für Suche

80 × 80

Icon für Einstellungen

58 × 58

Für ein eigenes App-Icon brauchen Sie allerdings nicht alle Formate bereitzustellen; es reicht in der Regel aus, die Springboard-Icons anzulegen, da iOS daraus auch die restlichen Icons erstellen kann. Mit iOS 7 hat Apple indes nicht nur die Icon-Formate geändert, sondern auch das Ablagesystem für die zugehörigen Bilder. Unter Xcode 4 erfolgte die Verwaltung der Bilder über die Target-Einstellungen. Seit iOS 7 gibt es Asset-Kataloge, die verschiedene Bildmengen enthalten können. Dabei enthält jede Bildmenge jeweils Bilder für die gleiche Aufgabe in den unterstützten Displayauflösungen und Betriebssystemversionen.

Ihr Projekt enthält bereits einen Asset-Katalog, den Sie in der Navigatorspalte des Projekts in der Gruppe AlarmClock unter dem Namen Images.xcassets finden (siehe Abbildung 3.50). Dieser Katalog enthält zwei Bildmengen: jeweils eine für das App-Icon und eine für das Launch-Image. Wenn Sie die Bildmenge für das App-Icon öffnen, können Sie im Attributinspektor die iOS-Versionen einstellen, für die Sie angepasste Bilder bereitstellen möchten. Dafür zeigt Xcode im Hauptbereich jeweils einen Platzhalter an, auf den Sie ein PNG-Bild aus dem Finder ziehen können. Jedes Bild muss dabei jedoch schon die richtigen Abmessungen haben, damit iOS es als Icon verwendet. Allerdings brauchen Sie nicht unbedingt alle Icons bereitzustellen. Wenn Sie nur ein Springboard-Icon bereitstellen, berechnet iOS daraus die Icons für die Einstellungen, die Suche und sogar das Springboard-Icon für den anderen Displaytyp.

Abhängig von der Betriebssystemversion passt iOS das Icon bei der Anzeige an: Bis iOS 6.1 rundet das Springboard die Ecken ab und fügt einen Glanzeffekt hinzu. iOS 7 verzichtet auf den Glanzeffekt und rundet nur noch die Ecken ab. Ein Beispiel dafür sehen Sie in Abbildung 3.51.

Abbildung

Abbildung 3.50 Einfügen der App-Icons

Abbildung

Abbildung 3.51 Originalbild und Icons unter iOS 6.1 und 7.0

Tipp

Vermeiden Sie möglichst Texte in den Icons für Ihre App, da Sie die Icons nicht lokalisieren können (siehe dazu Abschnitt 3.4.3, »Sprachkursus für die App«).


Rheinwerk Computing - Zum Seitenanfang

3.4.1Das Retina-DisplayZur nächsten ÜberschriftZur vorigen Überschrift

Mit Retina-Display bezeichnet Apple einen Displaytyp, der gegenüber gleich großen Standarddisplays die doppelte Auflösung besitzt. Während beispielsweise das Standarddisplay des iPhones 3GS 320 × 480 Pixel darstellen kann, besitzt das gleichgroße Retina-Display des iPhones 4S eine Auflösung von 640 × 960 Pixeln. Die höhere Auflösung ist dabei für eine größere Detailgenauigkeit und nicht für die Darstellung von mehr Inhalt gedacht. Cocoa Touch passt viele UI-Elemente wie beispielsweise Buttons und Labels automatisch an die höhere Auflösung an, so dass Sie bei der Programmierung in der Regel nicht den Displaytyp beachten müssen.

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.

Sie können für die unterschiedlichen Displaytypen jeweils ein eigenes Bild bereitstellen. Sie können dazu die Bilder jeweils mit unterschiedlichen Namenszusätzen der Form

<Bildname><Zusatz>.<Dateiendung>

versehen, wobei der Bildname sowie die Dateiendung bei allen Bildern gleich sind und der Zusatz vom Displaytyp abhängt. Eine Auflistung aller möglichen Zusätze finden Sie in Tabelle 3.4.

Tabelle 3.4 Dateinamenszusätze für unterschiedliche Displaytypen

Displaytyp Auflösung Zusatz

iPhone

320 × 480

kein Zusatz oder -phone

iPad

768 × 1024

-ipad

iPhone-Retina

640 × 960

@2x oder @2x-iphone

iPad-Retina

1536 × 2048

@2x-ipad

iPhone 5

640 × 1136

–568h@2x oder –568h@2x-iphone

Wenn Sie ein Bild für das iPhone mit dem Namen Bild.png auch für die Retina- und die iPhone-5-Auflösung bereitstellen möchten, sollten diese Bilder also die Namen Bild@2x.png beziehungsweise Bild-568h@2x.png haben. Cocoa Touch verwendet dann jeweils die richtige Bildvariante abhängig vom Displaytyp; 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. Dabei verwenden Sie immer den Dateinamen ohne Zusatz. Die Anweisung

UIImage *theImage = [UIImage imageNamed:@"Bild.png"];

lädt also auf einem iPhone 5S das Bild aus der Datei Bild-568h@2x.png.

Wenn Sie übrigens keine Retina-Version bereitstellen, skaliert Cocoa Touch in der Regel die Bilder für die normale auf die hohe Auflösung, und umgekehrt auch von der Retina- auf die Standardauflösung.

Die logische und die physikalische Bildgröße

Das Bild für die Retina-Auflösung ist zwar doppelt so breit und so hoch wie das für die Standardauflösung. Die Property size der Klasse UIImage liefert hingegen für beide Bilder die gleichen Werte – die der Standardauflösung. Das ist die logische Bildgröße. Wenn Sie das Bild nicht nur über einen Imageview anzeigen wollen, sondern es beispielsweise über Core Graphics verarbeiten möchten, brauchen Sie die physikalische Bildgröße.

Die können Sie durch die Multiplikation der Ausdehnungen mit dem Skalierungsfaktor berechnen, den Sie über die Property scale des Bildes erhalten:

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

Das Beispielprojekt Retina auf der beiliegenden DVD soll das Prinzip veranschaulichen. Sie finden es auf der DVD unter Code/iPhone/Apps/iOS7/Retina und im Git unter der URL https://github.com/Cocoaneheads/iPhone/tree/Auflage_3/Apps/iOS7/Retina. Außerdem gibt es eine Version ohne Image-Asset unter Code/iPhone/Apps/iOS4/Retina beziehungsweise https://github.com/Cocoaneheads/iPhone/tree/Auflage_3/Apps/iOS4/Retina. Die Projekte enthalten jeweils vier Bilder mit unterschiedlichem Inhalt für die unterschiedlichen Displaytypen und gleichem Inhalt für gleiche Displaytypen. Dabei gibt es zu zwei Bildmengen jeweils nur eine Bilddatei, so dass es insgesamt vier Bilddateien (both.png, both@2x.png, normal.png und retina@2x.png) gibt. Die iOS7-Variante des Projekts besitzt analog konfigurierte Bildmengen (siehe Abbildung 3.52).

Die Retina-Auflösung im Simulator

Der Simulator kann sowohl Geräte mit Standard- als auch mit Retina-Auflösung simulieren. Sie können den Displaytyp über den Menüpunkt HardwareGerät umstellen. Auf kleinen Computerdisplays verkleinert der Simulator allerdings das Ausgabefenster auf die halbe Größe. Das ist zum Testen der höheren Auflösung natürlich suboptimal. Sie können jedoch über den Menüpunkt FensterGrösse beziehungsweise cmd+1 den Simulator auf die volle Pixelzahl umstellen.

Seit Xcode 5 beziehungsweise iOS 7 unterstützt der Simulator für das iPhone nur noch Retina-Displays. Falls Sie Ihre iPhone-App im Simulator auf einem Standarddisplay testen möchten, können Sie in den Einstellungen unter dem Reiter Downloads Simulatoren für ältere iOS-Versionen laden. Diese Simulatoren unterstützen auch die Standardauflösung für iPhones.

Abbildung

Abbildung 3.52 Bildvarianten im Beispielprojekt

Die beiden letzten Dateien illustrieren das Verhalten von Cocoa Touch, 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 sehen Sie in Abbildung 3.53.

Abbildung

Abbildung 3.53 Anzeige der App »Retina« für Standard- und Retina-Auflösung

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 Displaytypen 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 Displayauflösung im Programmcode unterscheiden wollen, sollten Sie das nicht anhand der Displaygrößen machen. Die Anzahl und die Größe der Pixel eines Displays sind ja schließlich zwei vollkommen voneinander unabhängige Werte. Stattdessen sollten Sie dafür lieber die Methode scale der Klasse UIScreen verwenden. Das Screenobjekt zum eingebauten Display erhalten Sie über die Klassenmethode mainScreen, so dass 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 Retina zeigt diesen Wert ebenfalls an.


Rheinwerk Computing - Zum Seitenanfang

3.4.2Launch-ImagesZur nächsten ÜberschriftZur vorigen Überschrift

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 iOS-Versionen, Displayarten und Geräteausrichtungen insgesamt siebzehn Bilder in unterschiedlichen Formaten erstellen müssen. Glücklicherweise hat Apple auch hier die Verwaltung über Image-Assets erheblich vereinfacht. Die Bilddateien fügen Sie über die Bildmenge LaunchImage zu Ihrer App hinzu (siehe Abbildung 3.54).

Abbildung

Abbildung 3.54 LauchImages zu der Bildmenge hinzufügen

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 iPhones 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 [Anm.: Im Querformat zeigt sie entsprechend schwarze Ränder auf der rechten und linken Seite an.] am oberen und unteren Rand einen schwarzen Balken an, so dass 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. Während der Simulator für iOS 6 diesen Modus nach wie vor unterstützt, akzeptiert Apple allerdings keine Apps für diese iOS-Version mehr, die nicht auch das iPhone 5 unterstützt. Sie sollten also unbedingt das entsprechende Launch-Image bereitstellen. Zur Not verwenden Sie einfach ein schwarzes PNG mit 640 × 1.136 Pixeln, wie das auch Xcode 4.5 und 4.6 automatisch gemacht haben. Ab Version 7 geht das iOS davon aus, dass jede App das 4-Zoll-Display des iPhones 5 unterstützt, und die Bereitstellung entsprechender Launch-Images ist hier nicht mehr unbedingt notwendig.

Unterstützung des iPhones 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. Die Anpassungen der einzelnen Views müssen Sie vornehmen. Dazu stellt Cocoa Touch einige Möglichkeiten bereit, auf die wir später noch genauer eingehen.


Rheinwerk Computing - Zum Seitenanfang

3.4.3Sprachkursus für die AppZur nächsten ÜberschriftZur vorigen Überschrift

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 je nach gewählter 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. im Storyboard
  2. im Programmtext
  3. im Programmnamen

Bei größeren Projekten müssen Sie häufig auch 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 (alt+cmd+1) in Xcode sehen Sie, 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 localize..., mit dem Sie das nachholen können.

Abbildung

Abbildung 3.55 Lokalisierung im Dateiinspektor

Die Lokalisierungen verwalten Sie zentral über das Projekt; das heißt, Sie legen in den Projekteinstellungen fest, welche Sprachen Ihre App unterstützt. Bislang besitzt Ihre App nur Lokalisierungsdateien für Englisch. Wenn Sie auf den Plus-Button unter Localizations klicken, können Sie weitere Sprachen hinzufügen; z. B. für Deutsch (siehe Abbildung 3.56).

Danach fragt Sie Xcode in einem Dialog, von welchen Dateien es Varianten für die ausgewählte Sprache anlegen soll (siehe Abbildung 3.57). Sie können diese Auswahl jedoch nachträglich jederzeit über die in Abbildung 3.55 gezeigten Checkboxen des Dateiinspektors wieder ändern.

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.

Abbildung

Abbildung 3.56 Sprachvarianten der App festlegen

Abbildung

Abbildung 3.57 Dateien für eine Sprachvariante auswählen

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, so dass die App die Texte auch aus einer speziellen Textdatei lädt. Dazu schreiben Sie um Ihre Zeichenketten den Makroaufruf NSLocalizedString. Beispielsweise können Sie in Listing 3.55 die Zuweisung für den Nachrichtentext durch folgende Zeile ersetzen:

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

Listing 3.69 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 in der App die Benachrichtigung erscheint, zeigt sie allerdings immer noch die Meldung »Wake up« an.

Tipp

Am besten gewöhnen Sie sich an, um jeden Text einen Aufruf von NSLocalizedString zu schreiben. Dann entsteht Ihnen später bei der Lokalisierung Ihrer App kein zusätzlicher Aufwand für das Einfügen der Makros. Eine mögliche Lokalisierung von Anfang an vorzubereiten, ist für Sie wenig Mehraufwand. Ein komplexes Projekt im Nachhinein zu lokalisieren, ist in der Regel sehr aufwendig, unangenehm und fehlerträchtig.

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 im 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.70 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.

Um die deutsche Variante der Datei Localizable.strings zu erzeugen, öffnen Sie den Dateiinspektor dieser Datei und setzen das Häkchen vor German. In der Navigatorspalte finden Sie unter Localizable.strings jetzt auch eine Variante für die deutsche Version der Datei, die allerdings noch englische Texte enthält. Wenn Sie sie öffnen, können Sie auf der rechten Seite 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).

Vorsicht mit Umlauten

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 können.

Den Namen der App können Sie ebenfalls an verschiedene Sprachen anpassen. Dazu verwenden Sie die Ressource InfoPlist.strings, die Xcode 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 im Springboard auf »Wecker« um. Analog können Sie natürlich auch den englischen Namen anpassen.

Xcode hat für das Storyboard übrigens keine deutsche Variante angelegt, sondern eine Datei mit dem Namen Main.strings im Unterordner de.lproj. Seit iOS 6 können Sie Storyboards und XIB-Dateien über Strings-Dateien lokalisieren. Diese Base Internationalization hat gegenüber einzelnen Storyboards beziehungsweise XIB-Dateien den Vorteil, dass Sie sich dabei nur um die Lokalisierung kümmern müssen. Bei sprachabhängigen Storyboards müssen Sie hingegen ständig darauf achten, die darin enthaltenen Views und Objekte auf dem gleichen Stand zu halten. Allerdings gibt es dabei einige Fallen, auf die wir später noch genauer eingehen.


Rheinwerk Computing - Zum Seitenanfang

3.4.4Es funktioniert nichtZur nächsten ÜberschriftZur vorigen Überschrift

Sie haben alle Anweisungen befolgt und alles noch einmal überprüft, und trotzdem zeigt der Simulator nur eine Sprachvariante Ihrer App an? Keine Sorge, Sie haben wahrscheinlich 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 rufen Sie den Menüpunkt ProductClean auf, oder drücken Sie cmd+ª+K.

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-Dateien und dem Storyboard gesetzt sein.

Abbildung

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

Auf der beiliegenden DVD finden Sie das Programm SimPholders von Rico Becker und Gunnar Herzog, das Sie auch über die URL http://simpholders.com laden können. Das Programm fügt zu der Menüleiste Ihres Macs einen weiteren Menüpunkt hinzu, über den Sie verschiedene Operationen zu den installierten Apps im Simulator ausführen können (siehe Abbildung 3.59).

Die angezeigten Versionsnummern in der Rubrik SDKs beziehen sich auf die installierten Simulatorversionen. Darüber sehen Sie die letzten im Simulator verwendeten Apps. Wenn Sie beispielsweise im Menü die Simulatorversion und darunter eine App auswählen, öffnet SimPholders den Ordner der App im Finder. Weitere Möglichkeiten stehen Ihnen durch das gleichzeitige Drücken folgender Tasten zur Verfügung:

  • cmd öffnet die App im Simulator.
  • alt löscht die App aus dem Simulator und startet diesen neu.
  • ctrl löscht nur die Daten der App und setzt sie somit auf ihren Ursprungszustand.
  • ª zeigt die Dateigröße in Bytes und die Anzahl der Dateien der App im Menü.

Abbildung

Abbildung 3.59 Das SimPholders-Menü

Sie können also SimPholders sehr gut zur Überprüfung der Dateien in der App nutzen, indem Sie über das Menü die App auswählen (siehe Abbildung 3.59). SimPholders öffnet daraufhin den Ordner im Finder, der die App und weitere Verzeichnisse enthält. Über einen Rechtsklick auf die App öffnen Sie ein Kontextmenü, über das Sie sich den Paketinhalt des App-Bundles im Finder anzeigen lassen können (siehe Abbildung 3.60). Damit können Sie dann recht einfach prüfen, ob sich alle lokalisierten Dateien an der richtigen Stelle, d. h. in den .lproj-Ordnern und nicht direkt im App-Ordner, befinden.

Abbildung

Abbildung 3.60 Paketinhalt des App-Bundles anzeigen

Auch Programmierer wollen leben

Falls Ihnen SimPholders gefällt, freuen sich die beiden Entwickler über eine Spende. Einen entsprechenden Button finden Sie auf der Website http://simpholders.com.


Rheinwerk Computing - Zum Seitenanfang

3.4.5Unterstützung älterer iOS-VersionenZur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie ein Gerät mit einer älteren iOS-Version an Ihren Rechner anschließen, zeigt Xcode es nicht in der Werkzeugleiste an, weil die Wecker-App bislang nur iOS 7 unterstützt. Da die App jedoch keine besondere Eigenschaft von iOS 7 nutzt, die nicht auch schon iOS 6 bereitstellt, spricht aus technischer Sicht also nichts dagegen, die App auch für diese Betriebssystemversion freizugeben.

Für die Umstellung brauchen Sie nur das Deployment-Target des Projekts oder des Targets zu ändern. Dabei können Sie die Version für alle Targets einheitlich festlegen, in dem Sie das Deployment-Target des Projekts wie in Abbildung 3.61 festlegen und danach die Einstellung in den Targets löschen, indem Sie in den Target-Einstellungen den Text aus dem Feld Deployment Target löschen. Xcode zeigt dann dort den Wert aus den Projekteinstellungen in grauer Schrift an.

Abbildung

Abbildung 3.61 Auswahl des Deployment-Targets

Allerdings sind Sie bei der Auswahl des Deployment-Targets für die Wecker-App nicht völlig frei. Das Projekt nutzt einige Eigenschaften aus iOS 6, die es unter iOS 5 nicht gibt. Dazu gehören beispielsweise die Base Internationalization und das Autolayout, auf das Kapitel 7, »Programmieren, aber sicher«, genauer eingeht. Tabelle 3.5 listet einige Funktionalitäten mit der iOS-Version auf, unter der Apple sie eingeführt hat; diese Auflistung ist natürlich sehr unvollständig.

Tabelle 3.5 Einige Funktionalitäten nach iOS-Versionen geordnet

Eigenschaft Mindestversion

Storyboards, Page-Viewcontrollers, Prototypzellen in Tableviews

iOS 5

Autolayout, Collectionviews, Base Internationalization

iOS 6

neues Design der Benutzeroberfläche, Sprite Kit, AirDrop

iOS 7

Wenn Sie das Deployment-Target im Wecker-Projekt auf iOS 5 stellen, zeigt Xcode die Fehlermeldung Auto Layout on iOS Versions prior to 6.0 an, und Sie können das Projekt nicht übersetzen. Wenn Sie hingegen eine Methode aufrufen, die es erst seit iOS 7.0 gibt, erhalten Sie noch nicht einmal eine Warnung.

Eine Kuh macht Muh, viele Kühe machen Mühe

Jede iOS-Version, die Ihre App unterstützen soll, erfordert zusätzlichen Aufwand. Sie müssen darauf achten, dass die App nur Nachrichten versendet, die die iOS-Version auf dem Gerät auch unterstützt. Dazu schränken Sie die verwendeten Methoden und Klassen Ihrer App möglichst auf die minimale iOS-Version ein.

Möchten Sie dennoch Funktionalitäten bereitstellen, die es nur unter neueren iOS-Versionen gibt, müssen Sie die Existenz der entsprechenden Klassen und Methoden überprüfen. Die Existenz einer Klasse können Sie über dessen Klassenobjekt ermitteln:

if([UICriticalClass class] != nil) {
// Klasse vorhanden
}

Bei problematischen Methoden können Sie hingegen die Methode respondsToSelector: um Rat fragen:

if([theObject respondsToSelector:@selector(criticalMethod:)]) {
// Methode vorhanden
}

Sie brauchen diese Tests natürlich nur bei den kritischen Klassen und Methoden durchzuführen. In Abschnitt 3.1.6, »Zeichenfarbe festlegen«, haben Sie dieses Vorgehen bereits für die Methode tintColor kennengelernt; der Clockview sendet in Listing 3.21 nur dann die gleichnamige Nachricht, wenn das Objekt die entsprechende Methode auch besitzt.

Optimalerweise sollten Sie die App unter allen unterstützten iOS-Versionen auch testen, denn es kann sehr leicht passieren, dass Ihre App doch eine nicht vorhandene Klasse oder Methode verwendet.


Rheinwerk Computing - Zum Seitenanfang

3.4.6Base-Internationalisierung ausschaltenZur nächsten ÜberschriftZur vorigen Überschrift

Wenn Ihre App auch unter iOS 5 laufen soll, darf sie keine Base-Internationalisierung verwenden. Allerdings schaltet Xcode diese Option bei neuen Projekten immer ein. Bevor Sie die folgenden Schritte ausführen, sollten Sie eine Sicherungskopie Ihres Projekts anfertigen, da Sie dabei durch einen kleinen Fehler leicht viele Stunden Arbeit zunichtemachen können.

Um die Base-Internationalisierung auszuschalten, müssen Sie zunächst für jede Lokalisierung eine eigene Kopie des Storyboards erstellen. Dazu öffnen Sie den Dateiinspektor des Storyboards. In der Rubrik Localization aktivieren Sie zu jeder Sprache die Checkbox und wählen auf der rechten Seite den Eintrag Interface Builder Cocoa Touch Storyboard aus, wie Abbildung 3.62 es zeigt.

Abbildung

Abbildung 3.62 Storyboard-Lokalisierung umstellen

Xcode fragt für jede Localizable.strings-Datei nach, ob Sie daraus ein entsprechendes Storyboard erstellen wollen. Durch Drücken des Buttons Convert stimmen Sie dieser Aktion zu (siehe Abbildung 3.63).

Abbildung

Abbildung 3.63 Konvertierung in ein Storyboard bestätigen

Alle Lokalisierungen an (Story-)Board

Sollte Ihr Projekt mehrere Storyboards (oder XIB-Dateien) enthalten, müssen Sie diese Umstellung für jede Datei durchführen.

Wenn Sie danach im Projektnavigator den Eintrag für das Storyboard aufklappen, finden Sie darunter nur noch Storyboard- und keine Strings-Dateien mehr (siehe Abbildung 3.64).

Abbildung

Abbildung 3.64 Jede Sprache besitzt ein eigenes Storyboard

Sie können nun in dem Projekt die Base-Internationalisierung über die Projekteinstellungen ausschalten. Wählen Sie dazu im Projektnavigator das Projekt aus, und selektieren Sie danach in der Spalte daneben ebenfalls das Projekt. Unter der Rubrik Localizations können Sie die Base-Internationalisierung über die Checkbox Use Base Internationalization deaktivieren (siehe Abbildung 3.65).

In dem Bestätigungsdialog sollten Sie die Option Delete localized resource files from disk wie in Abbildung 3.66 aktivieren. Dadurch löscht Xcode die Dateien für die Base-Internationalisierung auch von der Festplatte, was unnötige Komplikationen vermeidet. Nach diesem Schritt haben Sie die Base-Internationalisierung ausgeschaltet.

Abbildung

Abbildung 3.65 Base-Internationalisierung ausschalten

Abbildung

Abbildung 3.66 Nicht benötigte Dateien sollte Xcode löschen

Tipps für die Umstellung

Bei dieser Umstellung können Sie sehr leicht wichtige Dateien löschen oder unbrauchbar machen. Deswegen hier einige Tipps, wie Sie unnötigen Ärger vermeiden können:

  1. Machen Sie vor der Umstellung eine Sicherheitskopie des Projekts.
  2. Führen Sie die Umstellung so früh wie möglich durch; am besten direkt nachdem Sie das Projekt angelegt haben.
  3. Überprüfen Sie über den Projektnavigator (siehe Abbildung 3.64) nach dem Anlegen der sprachabhängigen Storyboards, bevor Sie die Base-Internationalisierung ausschalten, ob tatsächlich keine Strings-Dateien mehr vorhanden sind.
  4. Löschen Sie die Dateien der Base-Internationalisierung wie in Abbildung 3.66 gezeigt.

Rheinwerk Computing - Zum Seitenanfang

3.4.7Universelle AppsZur vorigen Überschrift

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 die Target-Einstellungen Ihrer Applikation (siehe Abbildung 3.67) und wählen in dem Dropdown-Menü Devices den Punkt Universal aus. Xcode fragt Sie darauf, ob es für das Storyboard Main.storyboard eine Variante für das iPad erzeugen soll, indem es davon eine Kopie Main-iPad.storyboard anlegt. Da das in der Regel eine gute Idee ist, wählen Sie diese Option.

Abbildung

Abbildung 3.67 Universelle App auswählen

Öffnen Sie das neue Storyboard, und überprüfen Sie die Größen und Positionen des Clockviews und des Clock-Controls in deren Größeninspektor: Beide Views sollten am Nullpunkt liegen und eine Breite und Höhe von jeweils 768 haben. Das Label für die Anzeige der Alarmzeit sollte unterhalb des Clockviews liegen und beispielsweise die Position (20, 788), eine Breite von 728 und eine Höhe von 30 haben. Über den Attributinspektor des Labels können Sie außerdem einen größeren Font (z. B. 24 pt) wählen, damit die Alarmzeit auch gut sichtbar ist. Wenn Sie Ihre App jetzt im iPad Simulator starten, belegt sie den kompletten Bildschirm.

Durch das neue Storyboard haben Sie zwar eine eigene View-Hierarchie für das iPad erzeugt, beide Versionen verwenden jedoch die gleiche Viewcontroller-Klasse für die Verwaltung des Views. Das ist so auch sinnvoll, da die Views für die Darstellung auf den unterschiedlichen Gerätetypen verantwortlich sind und der Viewcontroller die Eingaben verarbeitet und die Ausgaben steuert. Dieses Verhalten ist, zumindest beim Wecker, jedoch beim iPhone und beim iPad absolut identisch.

Abbildung

Abbildung 3.68 Darstellung des Weckers auf dem iPad



Ihr Kommentar

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

>> Zum Feedback-Formular
<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de


  Zum Katalog
Zum Katalog: Apps programmieren für iPhone und iPad






Neuauflage: Apps programmieren für iPhone und iPad
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Einstieg in Objective-C 2.0 und Cocoa






Einstieg in Objective-C 2.0 und Cocoa


Zum Katalog: Spieleprogrammierung mit Android Studio






Spieleprogrammierung mit Android Studio


Zum Katalog: Android 5






Android 5


Zum Katalog: iPhone und iPad-Apps entwickeln






iPhone und iPad-Apps entwickeln


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo