UIViewController: extendedLayoutIncludesOpaqueBars und scroll view offset

Question

Die Ansichtshierarchie meiner App ist ziemlich einfach: Eine UINavigationController enthält eine UITableViewController. Die Navigationsleiste der Navigationssteuerung undurchsichtig ist, die während der Navigation Übergänge einig seltsamen Inset Verhalten der Tabellenansicht verursacht, hier zu sehen:

Um dies zu beheben, ich bin extendedLayoutIncludesOpaqueBars zu true auf dem UITableViewController Einstellung. Dadurch wird die Ansicht unter der Navigationsleiste richtig erweitert, aber das Verhalten der Tabellenansicht contentOffset wird in einer Weise geändert, die ich nicht ganz verstehe. Wenn diese Eigenschaft auf true gesetzt ist, gibt der Y-Wert der Tabellenansicht contentOffset an, dass der Offset um die aktuelle Höhe der Navigationsleiste höher ist (dh die Tabellenansicht 1pt wird durchsucht und der Y-Offset angezeigt -63 Punkte).

Das brachte mich dazu zu denken, dass der Navigationscontroller die Bildlaufansicht contentInset automatisch verwaltet, wie es für durchscheinende Balken tut. Ich konnte jedoch keinen Hinweis darauf finden, dass in der Bildlaufansicht Inhaltseinfügungen in scrollViewDidScroll() festgelegt waren. Selbst wenn automaticallyAdjustsScrollViewInsets auf dem Tabellenansicht-Controller auf false gesetzt war, war der Inhalt-Offset nicht richtig, also scheint es, dass es nichts mit den Einfügungen zu tun hat.

Apple's documentation about extendedLayoutIncludesOpaqueBars erwähnt keine Auswirkungen auf das Verhalten des Inhalts Offset einer Bildlaufansicht. Das Ändern der contentInset der Tabellenansicht löst dies leider nicht.

Ich habe versucht, die edgesForExtendedLayout -Eigenschaft des TableView-Controllers zu ändern, um es zu erzwingen, ohne die Bildlaufansicht zu beeinträchtigen, aber es scheint, dass diese Eigenschaft gegen opake Balken machtlos ist.

Gibt es ein verstecktes Verhalten bei extendedLayoutIncludesOpaqueBars, das den Inhaltsoffset einer Bildlaufleiste festlegt? Oder könnte das ein Fehler sein?

Answer 1

Haben Sie das versucht?

if #available(iOS 11, *) { 
    tableView.contentInsetAdjustmentBehavior = .never 
} 

Answer 2

Hintergrund auf, was los ist ---

extendedLayoutIncludesOpaqueBars erzählt im Wesentlichen der Ansicht, als ob die Navigationsleisten durchscheinend sind zu verhalten. Der Rahmen Ihrer Ansicht wird dann oben (unterhalb) der Navigationsleiste und nicht unten in der Leiste beginnen.

Der Navigationscontroller sieht dann, dass Sie eine Bildlaufansicht haben, und fügt sie automatisch ein, um den von der Leiste abgedeckten Bereich auszugleichen.

In iOS können Sie contentInset abfragen und den top = 64 Einschub sehen. In iOS 11 ist contentInset jedoch ausschließlich für benutzerdefinierte Steuerelemente vorgesehen, die Sie steuern. Verwenden Sie daher adjustedContentInset, was die Summe Ihrer benutzerdefinierten Einfügungen und aller sicheren Bereichseinsätze ist.

adjustedContentInset - 
The insets derived from the content insets and the safe area of the scroll view. 

contentInset - 
The custom distance that the content view is inset from the safe area or scroll view edges. 

Also wirklich, die y-Offset von -63 macht Sinn, es ist die gleiche Sache, die Sie sehen würden, wenn Sie Ihre Bars durchscheinend sind.

---

Das Problem Sie sprechen, die Ihr GIF zeigt, ist denke ich einen Fehler (siehe https://stackoverflow.com/a/46397291/2145198).

Während JoniVR's Antwort funktionieren sollte, löste ich es in meinen Projekten durch Einstellung extendedLayoutIncludesOpaqueBars = true.

Obwohl es wahrscheinlich keine große Sache ist, wie Sie es lösen, die Erweiterung des Layouts fühlt sich für mich besser an, als die contentInsetAdjustmentBehavior zu ändern. Die Einstellung auf never hat eine größere Bandbreite möglicher Auswirkungen. Sie sagen, dass es sich nie um sichere Bereiche kümmern soll, egal woher der sichere Bereich kommt. Sicherer Bereich könnte sich ändern (wie bei Rotation) oder wenn Ihr Controller in verschiedenen Kontexten/Containern (wie Tab-Leiste oder nicht) angezeigt wird.

Answer 3

Wie zuvor von @beebcon hingewiesen, war dies in der Tat ein Fehler (Apple-Techniker bestätigt auf Twitter) und sollte in iOS 11.2 behoben werden.

(tut mir leid, ich verwendet, um Bilder, aber auf diese Weise nicht in Fall geht weg die Tweets verschwinden)