La jerarquía de vistas de mi aplicación es bastante sencilla: un UINavigationController contiene un UITableViewController. La barra de navegación del controlador de navegación es opaca, lo que provoca un extraño comportamiento de inserción de la vista de tabla durante las transiciones de navegación, visto aquí:

Navigation Inset Issue

Para remediar esto, estoy configurando extendedLayoutIncludesOpaqueBars en true en UITableViewController. Al hacerlo correctamente, se extiende la vista debajo de la barra de navegación, pero cambia el comportamiento de la vista de tabla contentOffset de una manera que no entiendo del todo. Con esta propiedad establecida en true, el valor Y de la vista de tabla contentOffset informa que está desplazado más alto de lo que debería por la altura actual de la barra de navegación (es decir, desplazar la vista de tabla 1pt, informa que su desplazamiento en y es -63 puntos).

Esto me hizo pensar que el controlador de navegación administraba automáticamente la vista de desplazamiento contentInset, como lo hace para las barras translúcidas. Pero no pude ver ninguna evidencia de que la vista de desplazamiento tenía insertos de contenido establecidos en scrollViewDidScroll(). Incluso con automaticallyAdjustsScrollViewInsets configurado en false en el controlador de vista de tabla, el desplazamiento del contenido no era correcto, por lo que parece que no tiene nada que ver con las inserciones.

La documentación de Apple sobre extendedLayoutIncludesOpaqueBars no menciona ningún efecto en El comportamiento del desplazamiento del contenido de una vista de desplazamiento. Cambiar el contentInset de la vista de tabla desafortunadamente no resuelve esto.

Intenté cambiar la propiedad edgesForExtendedLayout del controlador de vista de tabla para forzarla a extenderse sin afectar la vista de desplazamiento, pero parece que esta propiedad no tiene poder contra las barras opacas.

¿Hay algún comportamiento oculto con extendedLayoutIncludesOpaqueBars que compense el desplazamiento del contenido de una vista de desplazamiento? ¿O podría ser esto un error?

5
John Wickham 18 oct. 2017 a las 17:26

3 respuestas

La mejor respuesta

¿Has probado esto?

if #available(iOS 11, *) {
    tableView.contentInsetAdjustmentBehavior = .never
}
4
JoniVR 19 oct. 2017 a las 18:23

Antecedentes de lo que está sucediendo ---

extendedLayoutIncludesOpaqueBars esencialmente le dice a su vista que se comporte como si las barras de navegación fueran translúcidas. El marco de su vista comenzará en la parte superior (debajo) de la barra de navegación, en lugar de en la parte inferior de la barra.

El controlador de navegación ve que tiene una vista de desplazamiento y la inserta automáticamente para compensar el área cubierta por la barra.

En iOS 10 , puede consultar contentInset y ver el recuadro top = 64. Sin embargo, en iOS 11, contentInset es estrictamente para cualquier inserto personalizado que controle; debe usar adjustedContentInset, que es la suma total de sus insertos personalizados y cualquier inserto de área segura.

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.

Entonces, realmente, el desplazamiento y de -63 tiene sentido, es lo mismo que verías si tus barras fueran translúcidas.


El problema del que está hablando , que su GIF demuestra, es que creo que es un error (consulte https: / /stackoverflow.com/a/46397291/2145198).

Si bien la respuesta de JoniVR debería funcionar, la resolví en mis proyectos configurando extendedLayoutIncludesOpaqueBars = true.

Aunque probablemente no sea un gran problema de cualquier manera que lo resuelva, ampliar el diseño me parece una mejor práctica, en lugar de cambiar el contentInsetAdjustmentBehavior. Establecer eso en never tiene una gama más amplia de efectos potenciales; le está diciendo que nunca se preocupe por el área segura, sin importar de dónde provenga el área segura. El área segura podría cambiar (como en la rotación) o si su controlador se presenta en diferentes contextos / contenedores (como la barra de pestañas o no).

3
beebcon 24 oct. 2017 a las 20:48

Como lo señaló @beebcon antes, esto era realmente un error (el ingeniero de Apple confirmó en Twitter) y debería repararse en iOS 11.2

first tweet enter image description here

(Lamento haber usado imágenes, pero de esta manera no desaparece en caso de que desaparezcan los tweets)

4
JoniVR 1 nov. 2017 a las 00:03