Home » Cursos » Curso de Apps (II), Auto-layout
Curso Apps 2 - Auto-Layout

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.

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

Otras recomendaciones

Lecciones Prototipos (I): UITableView

Lecciones por prototipos (I): Vistas de tabla (UITableView)

Primera lección por prototipos, un nuevo e innovador contenido. A veces, lo normal es que nos perdamos sin terminar de entender qué es o cómo funcionan los componentes que forman parte de una app o un juego. Para este caso hemos creado las lecciones por prototipos. Una exploración básica de conceptos esenciales a través de prototipos en Playground que podemos probar con Swift Playgrounds en el iPad o con Xcode 8. En esta primera lección abordamos las UITableView (vistas de tabla). Un elemento esencial en la mayoría de apps de iOS que muchas veces no es entendido desde su base y por lo tanto, provoca un mal uso de las mismas.

  • Enrique Condo

    Buen artículo! el vídeo me ha gustado mucho, en cualquier caso me gustaría comentar que tanto los leading como los trailing de las etiquetas de usuario y contraseña deberían ajustarse con las mismas restricciones de las cajas de texto puesto que en el caso de una aplicación localizada a otros idiomas las restricciones explicadas en el video podrían provocar que las etiquetas se truncasen en el caso de que tanto las palabras “usuario” como “contraseña” tuviesen diferentes “anchos” en los diversos idiomas.

    • Hola Enrique, muchas gracias por tu comentario. Me alegra que te haya gustado el artículo y el vídeo. Respecto a lo que comentas, acabas de hacerme un “spoiler” 😉 … Ese fallo que tan correctamente comentas es la introducción al diseño adaptativo que veremos en una próxima lección. Porque aun como comentas, podrían verse recortadas las etiquetas según el caso. Pero muy bien visto 😉 Un saludo y gracias.

  • Juan Antonio Fernandez Cruz

    Estupendo tutorial, pero se te ha olvidado comentar que la imagen tiene que tener un tamaño acorde con el contrein, si no te da problemas con los demás auto-layout

    • Muchas gracias Juan Antonio. Me alegra que te guste el tutorial. Respecto al dato que comentas, como se dice en el vídeo es una introducción básica centrada en las constraints más básicas y principalmente, es entender cómo funcionan éstas en cuanto a posición y/o tamaño. En próximas lecciones hablaremos de imágenes y las constraints de tamaño implícitas como Width y Height. Hay que ir paso a paso 😉

      Un saludo y gracias