Ab iOS7 verwenden die View-Controller standardmäßig das Vollbild-Layout. Gleichzeitig haben Sie mehr Kontrolle darüber, wie es seine Ansichten ausgibt, und das ist mit diesen Eigenschaften getan: Grundsätzlich legen Sie mit dieser Eigenschaft fest, welche Seiten Ihrer Ansicht erweitert werden können, um den gesamten Bildschirm zu decken. Stellen Sie sich vor, Sie schieben einen UIViewController in einen UINavigationController. Wenn die Ansicht des View-Controllers ausgelegt ist, wird es gestartet, wo die Navigationsleiste endet, aber diese Eigenschaft stellt fest, welche Seiten der Ansicht (oben, links, unten, rechts) erweitert werden können, um den gesamten Bildschirm zu füllen. Lassen Sie es mit einem Beispiel sehen: Hier legen Sie den Wert von edgesForExtendedLayout nicht fest. Daher wird der Standardwert genommen (UIRectEdgeAll), so dass die Ansicht ihr Layout erweitert, um den gesamten Bildschirm zu füllen. Dies ist das Ergebnis: Wie Sie sehen können, erstreckt sich der rote Hintergrund hinter der Navigationsleiste und der Statusleiste. Jetzt werden Sie diesen Wert auf UIRectEdgeNone setzen. So dass Sie sagen, die Ansicht-Controller nicht erweitern Sie die Ansicht auf den Bildschirm zu decken: Diese Eigenschaft wird verwendet, wenn Ihre Ansicht ein UIScrollView oder ähnliches ist, wie ein UITableView. Sie möchten, dass Ihre Tabelle anfängt, wo die Navigationsleiste endet, weil Sie den gesamten Inhalt nicht sehen, wenn nicht, aber gleichzeitig möchten Sie, dass Ihr Tisch den gesamten Bildschirm beim Scrollen abdeckt. In diesem Fall wird das Setzen von KantenForExtendedLayout auf None nicht funktionieren, da Ihre Tabelle beginnt zu scrollen, wo die Navigationsleiste endet und es wird nicht dahinter gehen. Hier ist, wo diese Eigenschaft ist praktisch, wenn Sie lassen Sie die View-Controller automatisch passen Sie die Einfügungen (Einstellung dieser Eigenschaft auf YES, auch der Standardwert) wird es Insert an der Spitze der Tabelle hinzufügen, so dass die Tabelle beginnt, wo die Navigation Bar-Enden, aber die Spirale wird den gesamten Bildschirm zu decken. Das ist, wenn auf NEIN eingestellt ist: und JA (standardmäßig): In beiden Fällen blättert die Tabelle hinter der Navigationsleiste, aber im zweiten Fall (JA) wird sie unterhalb der Navigationsleiste gestartet. Dieser Wert ist nur eine Ergänzung zu den vorherigen. Wenn die Statusleiste undurchsichtig ist, werden die Ansichten nicht um die Statusleiste erweitert, es sei denn, dieser Parameter ist JA. Wenn Sie Ihre Ansicht erweitern, um die Navigationsleiste (edgesForExtendedLayout zu UIRectEdgeAll) zu decken, und der Parameter NO (Standard) ist, wird sie die Statusleiste nicht decken, wenn sie undurchsichtig ist. Wenn etwas nicht klar ist, schreiben Sie einen Kommentar und Kranke Antwort darauf. Wie iOS weiß, was UIScrollView verwenden iOS greift die erste Unteransicht in Ihrer viewcontroller-Ansicht, so dass die eine bei Index 0, und wenn seine eine Unterklasse von UIScrollView dann die erklärten Eigenschaften anwendet es. Natürlich bedeutet dies, dass UITableViewController standardmäßig arbeitet (seit dem UITableView ist die erste Ansicht).Object Life Cycle: UIViewController Bei der Programmierung in iOS, it8217s unvermeidlich, dass you8217ll müssen Subklassen UIViewController. Diese Unterklassen enthalten alle Logiken, die Ihre Apps aussehen und sich so verhalten, wie sie sollten. It8217s schwer, eine Unterklasse aufzubauen, ohne zu wissen, welche überschriebenen Methoden aufgerufen werden und wann. Um diese potenzielle Verwirrung zu beheben, wird dieser Beitrag einen Blick auf den Lebenszyklus eines UIViewController werfen. Ein einfaches Setup So sieht unsere Einrichtung im Interface Builder aus. Wir werden die Szene B untersuchen. Dieser Controller ist Teil eines UINavigationController-Stacks und enthält eine weitere Szene über eine Containeransicht. Wie die meisten Controller verfügt der Scene B8217s-Controller über Verweise auf Objekte, die im Interface Builder unter Verwendung von IBOutlet-Eigenschaften erstellt wurden. Controller A schaltet auf Controller B Wenn Szene A ein 8216show8217-Segueg auslöst, werden diese überschriebenen Methoden in der folgenden Reihenfolge auf dem Controller Scene B8217s aufgerufen: initWithCoder: Beim Verwenden von Storyboards wird der Controller mit dieser Methode initialisiert, nicht mit dem init - oder initWithNibName-Bündel : Methoden. AwakeFromNib willMoveToParentViewController: Der Controller, der mit diesem Aufruf übergeben wird, ist der UINavigationController. prefersStatusBarHidden preferredStatusBarUpdateAnimation Loadview UIViewController 8216s Loadview-Funktion ordnet alle Objekte mit 8216Referencing Outlets8217 (aka IBOutlets) im Interface Builder zu ihren entsprechenden IBOutlet Eigenschaften. Wenn Sie in dieser Funktion auf diese IBOutlet-Objekte zugreifen müssen, rufen Sie zuerst die erste Aufforderung an. prepareForSegue: Absender: Dieser Aufruf ermöglicht es uns, die UIStoryboardEmbedSegue zu untersuchen, die die kleineren Szene in Szene B8217s Container Ansicht einbettet. ViewDidLoad Diese Methode ist in der Regel, wo die meisten von einem Controller8217s Setup auftritt. Beachten Sie, dass alle unsere IBOutlets angeschlossen sind, aber unsere Ansichten sind noch nicht angelegt. extendedLayoutIncludesOpaqueBars edgesForExtendedLayout viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForExtendedLayout updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews-Animation Die Animation, die von Szene A zu Szene B übergeht läuft. Schritt 18 tritt nicht auf, bis die Animation beendet ist. ViewDidAppear: didMoveToParentViewController: Dieser Aufruf beendet den in Schritt 2 gestarteten Prozess. Hier erhalten wir die gleiche Instanz von UINavigationController. updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Dies beantwortet einige Fragen über die Anrufe zuerst dazu kommen, um einige interessante Macken auszusetzen. Mehrere Anrufe geschehen offenbar mehr als einmal. Die scene8217s-Ansicht führt ihr Layout zweimal aus, einmal vor und einmal nach der Animation. Die Szene fragt auch die Steuerung über das erweiterte Layout redundant. Controller B drückt auf Controller C Ähnlich unserem letzten Übergang löst Szene B nun einen 8216show8217-Segue aus. Die controller8217s überschrieben Methoden sind in der folgenden Reihenfolge aufgerufen: prepareForSegue: Absender: Dieser Aufruf uns die UIStoryboardShowSegue Objekt zu untersuchen ermöglicht, die Szene C. viewWillDisappear segue wird: updateViewConstraints-Animation Die Animation, die Übergänge von Szene B zu Szene C läuft. Schritt 5 tritt erst ein, wenn die Animation beendet ist. ViewDidDisappear: Keine Überraschungen hier. We8217re nur immer ein paar Anrufe und sie alle scheinen sinnvoll in diesem Zusammenhang. Controller C springt zu Controller B Nun, da wir vor Scene B gegangen sind, werden wir wieder zurückkommen. Szene B wird über einen UINavigationController-Pop geladen (im Gegensatz zum Push im ersten Beispiel). Wir erhalten die folgenden Aufrufe: prefersStatusBarHidden preferredStatusBarUpdateAnimation extendedLayoutIncludesOpaqueBars edgesForExtendedLayout viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForExtendedLayout updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews-Animation Die Animation, die von Szene C geht in Szene B läuft. Schritt 12 tritt nicht auf, bis die Animation beendet ist. ViewDidAppear: updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Diese Anrufe und deren Reihenfolge sollten aus dem ersten Übergang ziemlich vertraut sein. Bemerkenswert sind einige der Einmal-Schritte. Der Controller befindet sich noch im UINavigationController, so dass keine Anrufe über den übergeordneten Controller vorhanden sind. Controller B springt auf Controller A We8217re jetzt mit unserem Scene B Controller. Beim Abspielen des UINavigationController-Stacks stehen uns folgende Aufrufe zur Verfügung: willMoveToParentViewController: Das View-Controller-Argument in diesem Aufruf ist nil. Dies sagt uns, dass Szene B aus der Hierarchie entfernt wird. ViewWillDisappear: updateViewConstraints viewDidDisappear: Animation Die Animation, die von Szene B zu Szene A übergeht, wird ausgeführt. Schritt 6 tritt erst auf, wenn die Animation beendet ist. DidMoveToParentViewController: Dieser Aufruf beendet den in Schritt 1 gestarteten Prozess. Hier erhalten wir das gleiche nil-Argument. Dealloc Ähnlich wie der zweite Übergang scheint dieser Übergang ziemlich direkt. Nachdem der Controller aus der Hierarchie entfernt wurde, wird seine dealloc-Methode wie jedes andere NSObject aufgerufen. See For Yourself Der Code, den ich verwendet, um diesen Test laufen, ist auf meinem Github hier. Fühlen Sie sich frei, es selbst auszuprobieren, und fügen Sie alle anderen Schritte, die Sie in Ihrem eigenen Controller verwenden würde. Post navigation Kategorien Aktuelle Beiträge
No comments:
Post a Comment