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.5Geräteausrichtungen, Autosizing und AutolayoutZur nächsten Überschrift

Wenn Sie die App im iPhone-Simulator mit verschiedenen Geräteausrichtungen testen, stellen Sie fest, dass das Zifferblatt immer die gleiche Größe behält und am linken und oberen Rand liegt. Außerdem hat es mit einer Ausnahme immer die richtige Ausrichtung; der Strich für die Zwölf ist also oben. Abbildung 3.69 zeigt die Darstellung der App in den vier Geräteausrichtungen im Simulator. Dabei zeigen alle Uhren (fast) die gleiche Zeit an. An der Richtung des Alarmzeigers sehen Sie, dass nur in der Ausrichtung »Upside Down« das Zifferblatt nicht die richtige Ausrichtung hat; der Strich für die Zwölf zeigt nach rechts.

Abbildung

Abbildung 3.69 Die Wecker-App in verschiedenen Geräteausrichtungen

Standardmäßig unterstützt jedes neue iPhone-Projekt drei Geräteausrichtungen: das Hochformat und die beiden Querformate mit rechts beziehungsweise links liegendem Home-Button. Sie können die unterstützten Ausrichtungen über die Target-Einstellungen unter dem Punkt Device Orientation ändern und beispielsweise nur das Hochformat unterstützen, wie das Abbildung 3.70 zeigt.

Abbildung

Abbildung 3.70 Unterstützte Geräteausrichtungen festlegen

Wenn Sie beispielsweise nur die Ausrichtung Portrait zulassen, können Sie das iPhone drehen, wie Sie wollen; die App dreht den View nicht mehr, und der Strich für die Sechs zeigt immer in Richtung des Home-Buttons.


Rheinwerk Computing - Zum Seitenanfang

3.5.1Flexible Views dank AutosizingZur nächsten ÜberschriftZur vorigen Überschrift

Vielleicht ist Ihnen in Abbildung 3.69 aufgefallen, dass das Label mit der Alarmzeit nur in der Ausrichtung »Portrait« sichtbar ist. Das liegt daran, dass Cocoa Touch beim Drehen die Größe des Views ändert. Bei der Drehung vom Hoch- ins Querformat ändert Cocoa Touch beispielsweise die Größe des Views von 320 × 480 in 480 × 320. Da die y-Koordinate des Labels jedoch größer als 320 ist, liegt das Label nach der Drehung im nicht sichtbaren Bereich (siehe Abbildung 3.71).

Abbildung

Abbildung 3.71 Größenänderung des Views bei Gerätedrehung

Jeder View kann seine Positionierung bezüglich seines Superviews über seine Auto(re)sizing-Maske [Anm.: Apple verwendet im Interface Builder die Bezeichnung »Autosizing«, während die Methodennamen »autoresizing« enthalten. Wir verwenden diese Begriffe synonym.] festlegen. Sie besteht aus sechs booleschen Werten, die zu einer Bitmaske verknüpft sind. Die booleschen Werte stehen dabei für die Veränderlichkeit – entweder für einen Abstand zu den vier Seiten des Superviews oder für die Breite beziehungsweise Höhe des Views.

Damit Sie Autosizing verwenden können, müssen Sie im Dateiinspektor des Storyboards in der Rubrik Interface Builder Document den Haken bei Use Autolayout deaktivieren (siehe Abbildung 3.72). Wenn Ihre App auch mit iOS 5.1 oder früher kompatibel sein soll, sollten Sie das Autolayout auf jeden Fall ausschalten, da diese Betriebssystemversionen es noch nicht unterstützen.

Abbildung

Abbildung 3.72 Autolayout im Dateiinspektor des Storyboards ausschalten

Nach dieser Umstellung ändert sich die Größe des Clockviews bei einer Drehung des Gerätes in das Querformat: Das Zifferblatt nimmt die gesamte Breite des Bildschirms ein und hat eine wesentlich geringere Höhe. Das liegt daran, dass die Autosizingmask des Clockviews feste Abstände zu seinem Superview und eine flexible Breite und Höhe hat.

Abbildung

Abbildung 3.73 Größenveränderung des Clockviews mit Autosizing

Sie passen die Autosizingmask über den Größeninspektor im Interface Builder an, der Ihnen dazu auch ein animiertes Beispiel anzeigt. Wenn Sie die Einstellungen aus Abbildung 3.74 für den Clockview übernehmen, dann verhält er sich bei einer Größenänderung seines Superviews wieder wie vor der Deaktivierung des Autolayouts.

Tipp

Nutzen Sie die Beispielansicht im Interface Builder, wenn Sie sich unsicher sind, wie Sie das Autosizing für Ihre Anforderungen einstellen müssen. Die Animation verdeutlicht sehr schön, wie sich der View (rotes Rechteck) bei einer Größenänderung seines Superviews (weißes Rechteck) verändert.

Abbildung

Abbildung 3.74 Die Autosizing-Einstellungen für den Clockview

Dabei bedeuten die roten Markierungen, dass die Abstände zum linken und zum oberen Rand des Superviews fest sind; die Abstände zum rechten und zum unteren Rand sind hingegen flexibel. Die ausgeschalteten Doppelpfeile in der Mitte besagen, dass die Breite und die Höhe des Clockviews ebenfalls flexibel sind. Wenn Sie die App mit diesen Einstellungen im Simulator testen, richtet sie den Clockview wieder am linken und am oberen Rand aus, ohne die Größe des Clockviews zu ändern.

Damit die App das Label für die Anzeige der Alarmzeit in jeder Geräteausrichtung anzeigt, müssen Sie es so platzieren, dass es nicht außerhalb des sichtbaren Bereiches liegt und dass es auch nicht der Clockview verdeckt. Da dieser ja immer links oben liegt, bietet sich eine Lage rechts unten an. Platzieren Sie also das Label rechts unten, stellen Sie in seiner Autosizingmask einen festen Abstand nach rechts und unten ein, und lassen Sie alle anderen Größen flexibel (siehe Abbildung 3.75). Nun sollte das Label bei allen Geräteausrichtungen sichtbar sein.

Abbildung

Abbildung 3.75 Autosizing-Einstellungen für das Label

Sie können die Autosizingmask auch über die Property autoresizingmask im Programmcode setzen. Dort setzen Sie jeweils das Bit für die flexiblen Größen. Sie können beispielsweise die Maske für das Label auch folgendermaßen im Programmcode setzen:

theLabel.autoresizingmask = 
UIViewAutoresizingFlexibleLeftMargin |
UIViewAutoresizingFlexibleTopMargin;

Listing 3.71 Setzen der Autoresizingmask im Programmcode

Die Einstellungen in der Autoresizing-Maske eines Views werden immer dann wirksam, wenn sich die Größe des Superviews ändert. Wenn die Maske für eine Größe festlegt, dass sie unveränderlich ist, hat sie nach der Größenänderung den gleichen Wert wie davor. Definiert die Maske den Wert hingegen als veränderlich, so wird die Größe dynamisch angepasst.

Die folgenden Beispiele sollen das Verhalten veranschaulichen:

  • Wenn Sie einem View eine flexible Breite und Höhe geben, hat der View immer den gleichen Abstand zu den Rändern seines Superviews. Sie können mit dieser Maske beispielsweise Rahmen mit einer festen Breite realisieren. Wenn Sie einen neuen Viewcontroller anlegen, bekommt der darin enthaltene View diese Maske, damit sich dessen Größe bei einer Rotation automatisch an die Größe des Bildschirms anpassen kann.
  • Wenn Sie Textfelder, Labels und Buttons im Interface Builder anlegen, bekommen sie zunächst einen flexiblen rechten und unteren Rand. Bei einer Größenveränderung des Superviews ändern sie also ihre Position zum linken und oberen Rand nicht. Das ist sinnvoll, da es allgemein üblich ist, Formulare von oben links her aufzubauen.
  • Formulare zeigen in der Regel die Buttons zum Annehmen oder Ablehnen am unteren Rand an. Hier müssen Sie also den oberen Rand flexibel und den unteren unveränderlich setzen, damit die Buttons sich immer am unteren Rand ausrichten.
  • Tabbars und Werkzeugleisten liegen am unteren Bildschirmrand und nehmen dessen komplette Breite ein. Sie müssen bei diesen Elementen also einen flexiblen oberen Rand und eine flexible Breite setzen, so wie es der Interface Builder bei diesen Elementen auch automatisch macht.

Sie können in vielen Fällen die Autosizingmask verwenden, um Ihre Views bei einer Geräterotation an die geänderte Größe anzupassen. Die Autosizingmask reicht aus, wenn die Größe des Views

  1. sich durch die Rotation nicht verändern soll oder
  2. nur von der entsprechenden Größe des umgebenden Views in der gleichen Dimension abhängt.

Tipp

Sie sollten Ihre Views möglichst so gestalten, dass sie flexibel auf Größenveränderungen reagieren. Zum einen kann der View in der App eine andere Größe als im Interface Builder haben, und zum anderen ist das die beste Voraussetzung, um dessen Rotationsfähigkeit sicherzustellen.

Sie sollten sich außerdem beim Anlegen eines Views nicht auf feste Displaygrößen verlassen. Momentan haben beispielsweise iPhone-Displays eine Größe von 320 × 480 Punkten, was entweder der Pixelzahl oder auf Retina-Displays 640 × 960 Pixeln entspricht. Das iPhone 5 hat hingegen eine Auflösung von 320 × 568 Punkten beziehungsweise 640 × 1.136 Pixeln. Wenn Sie den kompletten Bildschirm des iPhones 4(s) und des iPhones 5 ausnutzen wollen, sollten Sie Ihre Views also entsprechend flexibel gestalten.

Es lässt sich also beispielsweise die Breite des Views über die Autoresizingmask dynamisch anpassen, wenn die neue Breite nach der Rotation nur von der neuen Breite des Superviews abhängt. Abbildung 3.76 zeigt ein Beispiel für eine solche Rotationsanpassung mit festen und variablen Größenänderungen. In der Darstellung entspricht der linke View der Darstellung im Hochformat und der rechte View der Darstellung im Querformat. Die weißen Punkte bedeuten, dass der entsprechende Randwert in der Maske fixiert ist, und die gestrichelten Pfeile zeigen an, dass der entsprechende Größenwert in der Maske flexibel ist.

Während der hellgraue Bereich in der Mitte und die dunkelgraue Fußzeile ihre Breite jeweils an ihren Superview anpassen, bleiben die Größen des Titels und der Buttons am oberen Rand fest.

Abbildung

Abbildung 3.76 Layoutanpassung bei Rotation über die Autosizingmask

Die Autosizingmask ist eine relativ einfache und effektive Methode, Views größenunabhängig zu gestalten. Sie kann jedoch nicht alle Möglichkeiten abdecken. Beispielsweise sollte beim analogen Wecker das Ziffernblatt möglichst immer quadratisch sein. Das lässt sich durch die Autosizingmask jedoch nicht ausdrücken, sondern nur über Programmcode oder Autolayout-Constraints.


Rheinwerk Computing - Zum Seitenanfang

3.5.2AutolayoutZur nächsten ÜberschriftZur vorigen Überschrift

Mit iOS 6 hat Apple mit Autolayout ein neues Layoutsystem als Alternative zur Autosizingmask eingeführt. Dabei legen Restriktionen, die Autolayout-Constraints, die Größen und Abstände der Elemente fest. Sie können relativ vielfältige Restriktionen formulieren. Dabei können sich Restriktionen nur auf einen View beziehen, Beziehungen zwischen einem View und seinem Superview oder zwischen zwei Views in einer Hierarchieebene herstellen.


Rheinwerk Computing - Zum Seitenanfang

3.5.3Restriktionen im Interface-Builder festlegenZur nächsten ÜberschriftZur vorigen Überschrift

Bei eingeschaltetem Autolayout zeigt der Interface Builder die Restriktionen als Objekte in der View-Hierarchie an (siehe Abbildung 3.77).

Abbildung

Abbildung 3.77 Restriktionen in der View-Hierarchie

Allerdings erscheint das Constraints-Objekt erst, wenn Sie explizit Restriktionen zu den Views anlegen. Das geht entweder über die Untermenüs Align, Arrange, Resolve Autolayout Issues und Pin des Hauptmenüs Editor oder über die Icons am unteren Rand der Zeichenfläche (siehe Abbildung 3.78); bei allen Varianten müssen Sie mindestens einen, bei manchen auch mehrere Views selektiert haben.

Abbildung

Abbildung 3.78 Restriktionen festlegen

Die Autosizing-Einstellungen lassen sich recht gut über die Pin-Restriktionen abbilden, die feste Abstände beschreiben. Die in Abbildung 3.78 gezeigten Einstellungen für das Label mit der Alarmzeit entsprechen beispielsweise der Autosizingmask aus Abbildung 3.75: Die Positionierung erfolgt relativ zum rechten und unteren Rand. Außerdem legen Sie die Abstände zum Rand mit jeweils 20 Punkten sowie eine Größe von 200 × 30 Punkten fest.

Nachdem Drücken des Buttons Add 4 Constraints legt der Interface Builder die entsprechenden Restriktionen an. Wenn Sie vorher unter Update Frames zusätzlich den Punkt Items of New Constraints oder All Frames in Container auswählen, wendet der Interface Builder auch die neuen Restriktionen auf die betroffenen beziehungsweise alle Views an.

Sie können auch relative Restriktionen anlegen. Ein Beispiel dafür sind Buttons, die immer die gleiche Breite haben sollen. Diese Restriktion stellt der Interface Builder durch dicke blaue Linien mit einem Gleichheitszeichen in der Mitte dar (siehe Abbildung 3.79). Außerdem hat der rechte Rand des OK-Buttons einen festen Abstand zum linken Rand des Abbrechen-Buttons, und beide Buttons sind bezüglich ihrer vertikalen Mittellinie zentriert.

Abbildung

Abbildung 3.79 Restriktion für Buttons mit gleicher Breite

All diese Restriktion lassen sich ebenfalls durch mehrmalige Aufrufe des in Abbildung 3.78 gezeigten Pop-over-Fensters definieren:

  1. Über die Option Equal Widths erzwingen Sie die gleiche Breite der Buttons, dazu müssen Sie allerdings beim Aufruf des Dialogs beide Buttons auswählen.
  2. Den rechten Rand des OK-Buttons legen Sie analog zum rechten Rand des Labels fest; allerdings müssen Sie hier gegebenenfalls den Bezugsview für den rechten Rand auswählen, indem Sie auf das Dreieck in dem Eingabefeld klicken (siehe Abbildung 3.80); in diesem Fall ist das der Abbrechen-Button.
  3. Für die vertikale Zentrierung der Buttons müssen Sie wiederum beide Buttons auswählen und im Pop-over-Fenster die Option Align mit dem Eintrag Vertical Centers auswählen.

Abbildung

Abbildung 3.80 Bezugsview für den rechten Rand auswählen

Der Attributinspektor einer Restriktion (siehe Abbildung 3.81) bietet abhängig vom Typ mehrere Einstellungen an. Unter Relation können Sie auswählen, ob der Wert unter Constant als exaktes Maß (Equal), Mindestmaß (Greater Than or Equal) oder Höchstmaß (Less Than or Equal) gelten soll. Der Haken vor Standard bewirkt, dass die Restriktion den Wert verwendet, den Apple dafür empfiehlt.

Bei horizontalen Abständen können Sie die Verlaufsrichtung der Views über Direction festlegen; dabei bedeutet der Standartwert Leading To Trailing, dass sie sich nach der aktuellen Anzeigesprache richtet – bei Deutsch oder Englisch also von links nach rechts und bei Hebräisch oder Arabisch von rechts nach links. Die letzte Einstellung, Priority, ist ein Wert zwischen 0 und 1000 und legt die Rangfolge der Restriktionen untereinander fest. Restriktionen sind dabei umso wichtiger, je höher ihre Priorität ist.

Abbildung

Abbildung 3.81 Der Attributinspektor einer Restriktion

Sie können zu jedem View mehrere Restriktionen anlegen, die Cocoa Touch jedoch nicht unbedingt immer alle einhalten kann oder die sich sogar widersprechen können. Ob Restriktionen widersprüchlich sind, prüft Cocoa Touch bei der Anzeige des Views. Gegebenenfalls gibt es eine Warnung aus.

Nicht erfüllbare Restriktionen entstehen leicht bei Viewrotationen oder durch die Lokalisierung. In Abbildung 3.82 sehen Sie ein Beispiel für Restriktionen, die sich nach der Viewrotation nicht mehr erfüllen lassen; dabei stehen die Pfeile in der Grafik für feste Abstände. Während sich die beiden Buttons mit den Abständen problemlos im Querformat unterbringen lassen (links), passt dieses Arrangement natürlich nicht ins Hochformat (gestricheltes Rechteck). Für die Anpassung an das Hochformat muss Cocoa Touch also auf die Einhaltung – zumindest einiger – Restriktionen verzichten.

Abbildung

Abbildung 3.82 Restriktionen und Viewrotation

Wenn Sie keine Rangfolge festlegen, wählt Cocoa Touch die zu missachtenden Restriktionen aus. Für das Beispiel aus Abbildung 3.82 ist es wahrscheinlich am sinnvollsten, auf die Einhaltung der Abstände zu den Außenrändern und zwischen den beiden Buttons zu verzichten. Dies können Sie dadurch erreichen, dass Sie deren Priorität von dem Maximalwert 1000 heruntersetzen.

Autosizing oder Autolayout?

Mit dem Interface Builder lassen sich viele Autolayout-Einstellungen relativ einfach und schnell umsetzen, und es ist gegenüber dem Autosizing das eindeutig mächtigere Werkzeug. Allerdings liegt darin auch sein wesentlicher Nachteil, da die Erstellung der notwendigen Restriktionen mitunter recht viel Aufwand erfordert. Im Gegensatz dazu ist das Autosizing eine relativ einfache Technologie, die es bereits seit OS X 10.0 gibt und die für sehr viele Anwendungsfälle vollkommen ausreicht. Es spricht also nichts dagegen, eigene Projekte zuerst auf Basis von Autosizing zu beginnen und gegebenenfalls später auf Autolayout umzusteigen.


Rheinwerk Computing - Zum Seitenanfang

3.5.4Autolayout und LokalisierungZur vorigen Überschrift

Zusammen mit der Einführung der Autolayouts hat Apple auch das Lokalisierungskonzept für Apps erweitert. Vor iOS 6 mussten Sie für jede Sprache ein eigenes Storyboard oder eigene XIBs erstellen, die jeweils alle Objekte enthalten. Während das Anlegen der ersten Lokalisierungsversion noch relativ einfach zu bewerkstelligen ist, können sich Änderungen an den Views, den Outlet- und den Action-Verbindungen sehr mühselig gestalten. Dieser Umstand führt dazu, dass viele Entwickler keine XIB-Dateien oder Storyboards einsetzen.

Durch das Autolayout ist es nun möglich, auf eigene Interface-Dateien für die einzelnen Sprachen zu verzichten. Stattdessen erstellen Sie bei der Base Internationalization jeden View nur einmal und legen die Texte in getrennten Dateien ab. Dieses Vorgehen ist zwar naheliegend, jedoch erst durch das Autolayout möglich, da die Views beim Layout über die Autorezising-Maske abhängig von der Orientierung eine feste Größe haben. Wenn Sie nun einen Text in eine andere Sprache übersetzen, hat er in den meisten Fällen auch eine andere Länge, wodurch er entweder zu breit oder zu schmal für den View ist. Beim Autolayout können Views hingegen eine flexible Größe haben, die sich an der Größe des Inhalts orientiert. Dadurch passen sich beispielsweise Buttons oder Labels automatisch an die Breite des enthaltenen Textes an. Ein Beispiel dafür sehen Sie in Abbildung 3.83.

Abbildung

Abbildung 3.83 Flexible Button-Größen dank Autolayout

Bei Verwendung der Base Internationalization legt Xcode für das Main-Storyboard die Datei Main.strings im Ordner de.lproj an, die für jeden Text aus dem Storyboard ein Schlüssel-Wert-Paar enthält. Sie können nun die Werte auf der rechten Seite von den Gleichheitszeichen in die gewünschte Sprache übersetzen. Für die beiden Buttons sieht die deutsche Version dieser Datei beispielsweise so aus:

/* Class = "IBUIButton"; normalTitle = "Back"; 
ObjectID = "QQl-ha-OEf"; */
"QQl-ha-OEf.normalTitle" = "Zurück";

/* Class = "IBUIButton"; normalTitle = "Accept";
ObjectID = "zEx-L5-tjS"; */
"zEx-L5-tjS.normalTitle" = "Akzeptieren";

Listing 3.72 Lokalisierung der Datei »Main.strings«

Schlüsselfrage

Die kryptischen Präfixe in den Schlüsselnamen erzeugt Xcode automatisch, und Sie dürfen weder sie noch den restlichen Schlüssel verändern. Wenn Sie nachträglich Schlüssel-Wert-Paare hinzufügen möchten oder nachvollziehen möchten, welches Paar zu welchem View gehört, finden Sie das Präfix im Identitätsinspektor des Views im Feld Object ID unter der Rubrik Document.

Im Dateiinspektor sehen Sie unter der Rubrik Localization, für welche Sprachen eine Anpassung vorliegt (siehe Abbildung 3.84). Dabei bedeutet ein gesetzter Haken, dass es eine angepasste Version für die Sprache gibt. Wenn der Haken fehlt, verwendet Cocoa Touch die Basis-Lokalisierung für diese Datei. Wenn Sie den Haken vor einer Sprache löschen, löscht Xcode nach Rückfrage auch die dazugehörende Datei.

Abbildung

Abbildung 3.84 Lokalisierungsinformationen für eine Datei

Mit der Basis-Lokalisierung können Sie jedoch auch für einzelne Sprachen eigene Storyboards verwenden. Dazu müssen Sie rechts von der Sprache im Pop-up-Menü den Eintrag Interface Builder Cocoa Touch Storyboard wie in Abbildung 3.84 auswählen. Xcode ersetzt dann nach einer Rückfrage die .strings-Datei durch ein entsprechendes Storyboard. Sie sollten allerdings nur dann getrennte Storyboards verwenden, wenn dies wirklich notwendig ist und sich die Anpassungen für die Sprache nicht über .strings-Dateien beziehungsweise lokalisierte Bilder realisieren lassen.

Tipp

Über dieses Dropdown-Menü können Sie die fehlenden Schlüssel-Wert-Paare in einer .strings-Datei erzeugen, wenn Sie die Views im Storyboard erweitert haben, oder auch die Lokalisierung in den Views durchführen. Schalten Sie dazu einfach von Localizable strings auf Interface Builder Cocoa Touch Storyboard um. Sie können nun das Storyboard für die entsprechende Lokalisierung öffnen und die Texte anpassen. Wenn Sie damit fertig sind, können Sie über den Menüpunkt Localizable strings das Storyboard wieder in eine .stings-Datei umwandeln. Aber Vorsicht: Bei diesem Vorgehen löscht Xcode auch all diejenigen Einträge aus der Textdatei, die das Storyboard nicht verwendet.



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.


[Rheinwerk Computing]

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






Apps programmieren für iPhone und iPad
Jetzt bestellen


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

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






Apps programmieren für iPhone und iPad


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