Cursos

Curso de Apps (II), Auto-layout

Segunda lección de aquella lejana pero aun actual primera lección que hicimos sobre cómo realizar apps. Auto-layout es, con diferencia, lo más solicitado por los lectores de Apple Coding, pero es un tema lo suficientemente complejo como para trabajar en ello para que sea fácilmente entendible. Si no sabéis llegar hasta aquí, os recomendamos que echéis un vistazo a la lección que habla sobre la básico de una primera app de ventana simple.

El problema

Hace muchos años, antes de la llegada del iPhone 5, el desarrollo en iOS en cuanto a las interfaces era bastante sencillo. Teníamos una sola pantalla de una sola resolución y en caso de hablar de Retina, las distribuciones eran las mismas por lo que la colocación dentro del constructor de interfaces no variaba. Y de hecho, esto mismo sucedía con el iPad por lo que la mayoría de la gente creaba una interfaz para el iPad y otra diferente para el iPhone y al no cambiar la proporción, el problema era menor.

Pero llegó el iPhone 5 y la cosa se complicó, porque de pronto teníamos una nueva relación de aspecto. Todos los iPhone hasta el 5 habían tenido una relación de aspecto 3:2 y los iPad son todos 4:3. Pero la llegada del iPhone introdujo el aspecto 16:9 y con ello se cerró el círculo actual. Pero además, por otro lado, llegaron los iPhone 6 y 6 Plus que traían nuevas resoluciones. Por eso, ahora mismo, nos enfrentamos a que una sola app a día de hoy, siendo solo para iPhone tiene que enfrentarse (si es para iOS 9) con 4 resoluciones de pantalla diferentes y en caso de iPad con 3.

Por lo tanto, crear una vista diferente para cada resolución en cada pantalla de una app se convierte en algo con poco sentido, por lo que hay que aplicar las mismas técnicas que otras sistemas como Android o Windows Phone usan: el auto-layout. Este sistema, no es otro que un sistema de proporcionalidad de posiciones y tamaños, de forma que a partir de una serie de reglas (restricciones o constraints) nuestros elementos dentro de la interfaz, saben cómo tendrán que dibujarse.

La solución

Normalmente la pantalla base para trabajar suele ser de 600×600 de resolución, completamente cuadrada, y en ella dibujamos los elementos de la interfaz. Pero luego, hay que crear las constraints pertinentes para que cada elemento sepa dónde colocarse sea cual sea el tamaño de la pantalla (o su orientación) y qué tamaño tendrá que tener: eso es hacer una interfaz usando auto-layout.

El truco está en pensar en proporciones y en qué elementos son los comunes a todas las interfaces que hagamos: los bordes. Todas las pantallas tienen un borde izquierdo, derecho, superior e inferior, por lo que en base a la posición relativa con respecto a estos podemos colocar los elementos. Por ejemplo, si tenemos una imagen en la parte superior de una pantalla, crearíamos una constraint que nos dijera que la distancia entre la imagen y el borde superior de la pantalla va a ser de 54 puntos (por ejemplo). ¿Qué significaría eso?

Pues que si nuestra pantalla de 600 de altura tiene que colocar un elemento (la imagen) a 54 puntos con respecto al borde superior, cuando la pantalla sea de 1136 de altura (un iPhone 5/5s/SE) esta imagen estará colocada a 102,24 puntos. ¿Por qué? Porque es una simple regla de tres: 1136 por 54 y dividido entre 600. Esto se aplica con todos los elementos. Así se nos permite saber cuál será la posición de Y pero también tendríamos que saber su posición en el eje X, para lo que nos puede servir (por ejemplo) una constraint que use el eje central de la pantalla para posicionar. De esta forma, da igual que la pantalla sea de 600 o de 1.920 de anchura: siempre se posicionará en el centro del eje X: es decir, la posición central con respecto a los bordes izquierdo y derecho de la pantalla.

Layout Constraints

También podemos centrar sobre el eje Y (obviamente) e incluso podemos hacer que la posición de un elemento en X o en Y dependa de otro elemento que ya tenga definida su posición a través de una constraint. De esta forma, si tenemos un elemento debajo de nuestra imagen a 54 puntos con respecto al borde superior, podemos crear una nueva constraint que tenga como origen el nuevo elemento que queremos posicionar, destino la imagen con la constraint de 54 puntos mencionada y fijarla a 35 puntos. En caso que la pantalla sea de 1136, el elemento estará 66,27 puntos por debajo de la posición de 102,24 puntos que habíamos calculado previamente para el elemento del que depende. Eso hace una constraint: es una restricción proporcional de distancias entre elementos dentro de una interfaz que facilita una colocación dinámica sin importar la resolución de la pantalla

En el cálculo de cada constraint sobre el eje X, el eje Y y la dependencia de un elemento sobre otro, es como se calcula dónde ha de colocarse cada elemento en nuestra pantalla, sea cual sea la resolución u orientación de la misma (incluso a futuro). Porque además, usar las reglas del auto-layout son muy importantes para funciones como la pantalla partida del iPad o la función Slide Over, donde es imprescindible para que nuestra app funcione correctamente y se muestre bien al usuario, el hecho que sus constraints le digan cómo ha de dibujarse con la parte de interfaz que le corresponde.

En cuanto al tamaño, también dependemos de estas constraints y su asociación con otros elementos. Podemos hacer que un campo sepa que su borde tiene que estar a una distancia determinada con respecto al borde la pantalla o al de otro elemento. Por ejemplo, un campo de texto puede tener una constraint que, partiendo de su borde izquierdo, fije una distancia hasta el borde izquierdo de la propia pantalla. E igual con el borde derecho del campo y de la propia pantalla. ¿Qué conseguimos con esto?

Imaginemos que le decimos al campo, mediante constraints que su borde izquierdo tiene que estar a 87 puntos de cada uno de los bordes en una pantalla de 600 puntos de ancho. Esto querrá decir, que cuando la resolución cambie a 1334 (un iPhone 6S) lo que tendrá que hacer el auto-layout es calcular que el borde del campo esté separado del borde de la pantalla por 193,43 puntos. Por lo que si teníamos un campo de 426 puntos de ancho en una pantalla de 600 puntos de anchura, al aplicar las constraints en ambos bordes con respecto al borde la pantalla en 1134 nos daría que nuestro campo de texto en esta nueva pantalla debería medir 947,14 puntos de ancho.

Ejemplo práctico de auto-layout

El auto-layout da para mucho más de lo que estamos abarcando en esta lección, y a este habría que sumarle el concepto del adaptative-layout por el que el tamaño de los elementos es capaz de ajustarse a su contenido en función de una serie de asociaciones entre diferentes elementos en una misma columna (como por ejemplo, una etiqueta y su campo correspondiente).

Para ver un ejemplo práctico de cómo aplicar auto-layout a una interfaz básica de entrada a una app o sistema a partir de usuario y contraseña, incluyendo varios elementos como una imagen, etiquetas, dos campos y un botón de entrar, vamos a exponer el siguiente caso que podréis ver en el vídeo que acompaña a esta lección donde ejemplificamos cómo aplicar esta teoría. Y de paso, os invitamos a suscribiros al canal de Youtube de Apple Coding.

Reglas elementales

Ya lo hemos comentado: estamos trabajando con 4 resoluciones diferentes (en iOS 9) para iPhone o iPod Touch y otras 3 diferentes para los iPad. Y que nuestras apps se vean correctamente, proporcionadas y con calidad, depende de nosotros y el buen trabajo que hagamos. Si sumamos los mencionados split-screen (pantalla partida) y slide-over del iPad, dispositivos como el iPhone 6 Plus que tienen un modo apasaido de interfaz que difiere ligeramente del resto de modos del iPhone o en futuras posibles resoluciones como WQHD o 4K, podemos pensar que es muy importante que todas estas reglas de construcción las tengamos lo más claras posibles y que hagamos un buen test de interfaces en todos los dispositivos posibles para asegurarnos que el trabajo es lo más correcto y válido posible.

Así que, como decimos siempre, probad, experimentad y si tenéis cualquier duda, dejadla caer en los comentarios o por email y nos vemos en el próximo artículo. Hasta entonces, Good Apple Coding.

Etiquetas

Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Artículos relacionados

Cerrar
Cerrar