3.5Geräteausrichtungen, Autosizing und Autolayout

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

3.5.1Flexible Views dank Autosizing

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

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

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

3.5.2Autolayout

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.

3.5.3Restriktionen im Interface-Builder festlegen

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

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

3.5.4Autolayout und Lokalisierung

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 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«

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

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.