PDF. Desarrollo de Entornos Interactivos Multidispositivo. Tema 9

DESARROLLO DE ENTORNOS INTERACTIVOS
MULTIDISPOSITIVO
El componente
content size fitter
y metodologías de
navegación
9
/ 1. Introducción y contextualización práctica 3
/ 2. El origen del problema que trata este componente 4
/ 3. El componente Content Size Fitter 4
/ 4. Caso práctico 1: “Decisiones de diseño” 5
/ 5. Uso básico del componente 6
/ 6. Las jerarquías y su influencia en la acción del componente 7
/ 7. Resultados habituales de un mal uso jerárquico del componente 8
/ 8. Previsión de problemas y actuaciones preventivas 9
/ 9. Scroll view con una cantidad de elementos dinámicos 9
/ 10. La navegación entre pantallas 10
/ 11. Canvas completo o múltiples canvas con habilitación y deshabilitación 11
/ 12. Caso práctico 2: “Creando una interfaz sencilla” 12
/ 13. Canvas por pantalla aplicando creación/destrucción dinámica 13
/ 14. Gestionando un sistema de pantallas dinámico 14
/ 15. Resumen y resolución del caso práctico de la unidad 15
/ 16. Bibliografía 16
© MEDAC
Reservados todos los derechos. Queda rigurosamente prohibida, sin la autorización escrita de los titulares del copyright,
bajo las sanciones establecidas en las leyes, la reproducción, transmisión y distribución total o parcial de esta obra por
cualquier medio o procedimiento, incluidos la reprografía y el tratamiento informático.
Aprender a usar el componente Content Size Fitter.
Entender sus limitaciones y cómo le afecta el resto de componentes en su

jerarquía.
Comprender distintas metodologías de navegación entre pantallas.
/ 1. Introducción y contextualización práctica

Hasta ahora hemos visto numerosas herramientas que nos ayudan a crear
un interfaz capaz de adaptarse a distintos problemas, generalmente
causados por cambios en la resolución o el aspect ratio de la pantalla en
que se ejecuta nuestra aplicación, pero ha quedado un aspecto que no
hemos sido capaces de solucionar todavía, la respuesta de nuestro diseño
ante cambios del tamaño del contenido.
En esta unidad trataremos este problema y mostraremos además distintas

alternativas para navegar entre pantallas explicando sus pros y contras.
Fig.1. Los elementos que pueden cambiar
A continuación, vamos a plantear un caso práctico a través del cual podremos de tamaño nos obligarán a usar nuevas
aproximarnos de forma práctica a la teoría de este tema. herramientas
Escucha el siguiente audio donde planteamos la contextualización práctica de este tema, encontrarás su resolución
en el apartado Resumen y Resolución del caso práctico.
Audio Intro. “El componente Content Size

Fitter”
https://bit.ly/3d21IA3
TEMA 9. EL COMPONENTE CONTENT SIZE FITTER Y METODOLOGÍAS DE NAVEGACIÓN
Desarrollo de entornos interactivos multidispositivo /4
/ 2. El origen del problema que trata este componente

Cuando creamos una interfaz, normalmente no deseamos que haya espacios que se queden vacíos, pero esto es aún
más cierto cuando hemos creado algún tipo de figura contenedora.
Pensemos por ejemplo en un popup donde se nos mostrará un texto y dos botones, uno para aceptar y otro para cancelar.
Por norma no queremos que la ventana del popup sea muy grande y contenga muy poco texto, y tampoco que sea muy
pequeña y el texto aparezca cortado. Queremos que la ventana del popup esté adaptada al tamaño del contenido que
mostrará, pero por desgracia un popup de validación suele reutilizarse continuamente con multitud de textos distintos,
por lo que suele ser un template y no deberíamos estar creando un popup diferente para cada texto.
Es decir, la reutilización es uno de los motivos que nos alientan a aprender a usar herramientas que nos ayuden a
ajustar el continente al contenido en nuestras representaciones visuales.
Ahora volvamos a recordar cómo afectan las traducciones a nuestros diseños

de elementos en pantalla. Si creamos un botón y la palabra que este contiene
cambia de tamaño en función del idioma, ¿cómo deberíamos proceder?
¿Diseñando el botón para el caso de la palabra más larga? Lógicamente esto
jugaría en contra de aquellos idiomas donde las palabras y frases sean más
cortas, porque mostrarían un contenedor enorme para un contenido mucho
más corto.
La adaptación del contenedor a la localización de textos es por tanto otro

de los aspectos importantes que deberíamos resolver para mejorar nuestras
interfaces.
Si piensas en ellos, podrás imaginar multitud de casos en los que ya no sólo

el texto es variable, sino que pueden existir ciertas zonas o no en función de
los datos disponibles, por ejemplo, la foto de un usuario, y puede que quieras Fig.2. Cuando creamos nuestros diseños
ajustar el tamaño de la ventana contenedora en función de la presencia o debemos tener en cuenta que no sabemos la
no de estos elementos. Para todas estas tareas, así como otras que también longitud exacta de los textos que mostraremos
veremos en esta unidad, contamos con el componente Content Size Fitter. debido a la localización
/ 3. El componente Content Size Fitter

El componente Content Size Fitter funciona de forma conjunta con los Layout Elements.
Fig.3. Componente Content Size Fitter
Consta únicamente de dos parámetros, Horizontal Fit y Vertical Fit, y cada uno de ellos presenta 3 posibles valores:
• Unconstrained. No aplica ningún tipo de limitación en el eje.
• Min Size. Ajusta su tamaño de acuerdo al valor de Min Size del Layout Element.
• Preferred Size. Ajusta su tamaño de acuerdo al valor Preferred Size del Layout Element.
/5 MEDAC · Instituto Oficial de Formación Profesional
Es decir, podemos tomar la decisión sobre qué aspecto controla el tamaño en las dimensiones vertical y horizontal
de nuestro elemento contenedor de acuerdo de forma independiente.
Así es posible que definamos un contenedor donde el alto o el ancho no será

susceptible de cambiar, mientras que el lado contrario sí que se adaptará
según el contenido que coloquemos dentro de él.
Podemos aplicarlo a cualquier objeto de nuestro UI a través del menú de

adición de componentes.
La ruta para alcanzarlo es Component > Layout > Content Size Fitter.
Si bien es cierto que podemos aplicarlo sobre cualquier objeto, sólo tiene
sentido hacerlo sobre aquellos elementos que formen parte del UI de un
canvas y cuyo tamaño pueda ser manipulado a través de un Rect Transform.
Además, necesitará tener elementos hijos que contengan el componente
Layout Element o no podrá realizar ninguna adaptación.
Usándolo, vamos a poder adaptar el tamaño de elementos de todo tipo de

contenedores como botones, ventanas de popup, etc. para que nuestro
diseño siempre resulte funcional. Fig.4. Controles principales de la localización
Sabías que...
Sin el componente Content Size Fitter sería muy complicado crear
aplicaciones multilenguaje ya que tendríamos que ajustar nuestro diseño
de acuerdo al idioma que más texto necesitase, lo que crearía grandes
espacios vacíos en el resto de casos.
/ 4. Caso práctico 1: “Decisiones de diseño”

Planteamiento: Somos los encargados de crear plantillas para el UI que serán utilizadas por nuestro equipo para
maquetar el menú de un videojuego. Nos encontramos definiendo un popup informativo.
Nudo: Este popup, pensado para ser utilizado en modo vertical, debe
mantener su ancho fijo, mientras que su alto se adaptará al texto que se
defina dentro del mismo, cuya longitud será variable. ¿Cómo deberíamos
configurar nuestro Content Size Fitter?
Desenlace: Nuestro Content Size Fitter permite configurar tanto la forma en

que se adapta verticalmente como horizontalmente.
En este caso sólo queremos que su tamaño crezca verticalmente junto

al texto que contenga, pero que su ancho se mantenga fijo, por lo que
su parámetro Horizontal Fit será configurado a Unconstrained, lo que
permitirá que mantenga el ancho que hayamos configurado. En el caso de
su parámetro Vertical Fit, aplicaremos generalmente el modo Min Size para
ajustar al máximo el contenido.
Si queremos definir márgenes, siempre podemos hacer uso del padding de Fig.5. Los popups suelen ajustar su tamaño
los layout de grupo. verticalmente
/ 5. Uso básico del componente

Existen ciertas reglas relacionadas con el uso de Content Size Fitter que afectan a su comportamiento. Comenzaremos
por ver un uso sencillo y directo sobre un tipo de componente que suele ser usado en conjunto con él de forma
habitual, el texto.
Hay elementos cuyo tamaño una vez definido suele ser fijo como en el caso de la imagen, por lo que el uso directo
de este componente no aporta nada.
Sin embargo, en el caso del texto tenemos presentes 2 aspectos. En primer lugar, la superficie donde permitimos
la escritura de texto, y en segundo lugar, el propio texto, que puede usar sólo una porción, ajustarse exacto a ella e
incluso exceder de la misma. En este caso Content Size Fitter nos ayuda a cuadrar superficie y texto real.
Cuando aplicamos un Content Size Fitter a un texto de forma directa, podemos usar o no un Layout Element.
En caso de no usarlo, la respuesta de cada uno de los valores disponibles para los parámetros de configuración será
la siguiente:
A. Sin Layout Element o con Layout Element sin valores Min o Preferred
» Unconstrained. La superficie que define la zona de texto tendrá el tamaño definido en el Rect Transform.
» Min Size. La superficie que define la zona de texto tendrá un tamaño de 0. Aun así, el texto puede salir
de dicha superficie por lo que seguirá siendo visible, aunque puede resultar por ejemplo en una hilera de
letras en columna si lo aplicamos al eje vertical.
» Preferred Size. La superficie que define la zona de texto se adaptará de forma exacta al texto escrito.
B. Con Layout Element con valores Min y Preferred
» Unconstrained. La superficie que define la zona de texto tendrá el tamaño definido en el Rect Transform.
» Min Size. La superficie tomará el tamaño definido en el parámetro equivalente del Layout Element (Min
Width o Min Height).
» Preferred Size. La superficie tomará el tamaño definido en el parámetro equivalente del Layout Element
(Preferred Width o Preferred Height).
Fig.6. Texto superior sin ajuste (superficie con excedente en rojo) y texto inferior con ajuste
horizontal a Preferred Size
De esta forma podemos ajustar el tamaño del texto, pero ¿realmente es esto lo que queremos? Lo que nos interesa
realmente es ajustar el tamaño del contenedor que lo envuelve. ¿Cómo podemos hacer esto?
/ 6. Las jerarquías y su influencia en la acción del

componente
Cuando ya no es un texto individual lo que queremos ajustar, sino un elemento que hará de contenedor del mismo
en una jerarquía, nos encontraremos con una sorpresa.
Pensemos en este caso en un ajuste que deseamos hacer al ancho, de forma que queremos incluir 2 textos, y
queremos que nuestro ancho total para el contenedor sea la suma del ancho de ambos textos.
Como primer paso para dicho ajuste, probablemente añadiríamos un Horizontal Layout Group, de forma que
definimos dicho panel base como el padre de un grupo de elementos horizontales, y quizás posteriormente le
añadiríamos también un Content Size Fitter.
Fig.7. Ejemplo de contenedor padre de dos textos con un layout group antes de solucionar el
problema
Por el mero hecho de haber añadido este layout group, cualquier Content Size Fitter que utilice uno de sus hijos
directos mostrará un mensaje de advertencia, indicando que un hijo de un layout group no debería usar Content
Size Fitter.
Fig.8. Warning cuando el padre es de tipo Layout Group
Entonces, ¿Cómo debemos usar dicho componente para que podamos afectar tanto a los textos como al contenedor?
Aunque no resulte intuitivo, la forma de realizar este ajuste es eliminar los Content Size Fitter de los textos y añadir
sólo uno en el contenedor. Configuramos este componente para usar como Horizontal Fit el valor Preferred Size,
para el que no habremos fijado ningún valor específico en los elementos hijo, y finalmente, marcamos la casilla que
permite al grupo controlar el ancho de sus hijos (Control Child Size - Width).
Fig.9. Ejemplo de resultado con dos textos de longitud desigual, padding y spacing aplicados
Además podemos controlar el espaciado en el borde mediante el Padding, y el espacio entre los dos elementos a
contener mediante el Spacing o mediante otras técnicas ya vistas.
En todo caso, siempre deberíamos añadir el elemento Layout Element a los elementos que compongan un grupo e
indicar al menos el tamaño mínimo que deseamos permitir en cada uno de ellos, que siempre será respetado.
Fig.10. Ejemplo de aplicación para ajustar tamaño de botón a su texto
/ 7. Resultados habituales de un mal uso jerárquico del

componente
Por desgracia es habitual hacer un mal uso del Content Size Fitter, ya que:
A. Aunque muestra el warning, nos permite añadirlo a los componentes aunque su presencia no sea correcta.
B. Podemos causar la situación incorrecta manipulando el elemento padre, por lo que podemos no ser
conscientes de que hemos dado lugar a esa situación incoherente.
Por ello, debemos siempre repasar la jerarquía y estar atento a cualquier detalle extraño que detectemos durante la ejecución.
En el caso de un uso incorrecto de los Content Size Fitter, hay que prestar especial atención ya que los efectos que
pueden tener a veces se presentan de forma engañosa.
Por ejemplo, si hemos creado un prefabricado que será cargado en tiempo de ejecución, puede que al añadirlo al
editor aparezca durante un instante mal y a continuación se corrija y aparezca tal como deseábamos.
Esto que puede parecer simplemente un retardo en el ajuste del componente, muchas veces es un aviso de que ese
componente tiene un problema, y aunque funcione en el editor puede deberse simplemente a la forma en que se
actualiza el mismo en modo edición, y una vez hagamos uso de la aplicación en modo ejecución estos componentes
no ajustarán su tamaño y se verán mal.
Es más, en muchas ocasiones si forman parte de layouts de grupo, puede que se coloquen de forma incorrecta
en este, por ejemplo, no alineándose bien. Si se deselecciona el elemento en el editor y se vuelve a seleccionar, se
colocará correctamente por arte de magia…
Todo esto es síntoma de que hemos usado Contents Size Fitter de forma incorrecta, por ejemplo aplicándolo tanto
en un contenedor como en su hijo directo.
Fig.11. El último elemento que añado a una lista vertical sale mal posicionado hasta que lo
deselecciono y lo selecciono otra vez. ¿Por qué? Existe un error de Content Size Fitter
Todos estos pequeños fallos que en el editor nos puede parecer que simplemente son retrasos al ajustar los elementos,
aparecerán de forma insistente y no solucionable en cuanto generemos nuestro compilado.
Por ello, es de vital importancia que entendamos cómo hacer un uso correcto de todos estos componentes y siempre
revisemos nuestra jerarquía en busca de incoherencias.
/ 8. Previsión de problemas y actuaciones preventivas

La lógica para conseguir ciertos resultados puede ser relativamente compleja. Por ejemplo, ¿cómo conseguimos un
contenedor tipo lista vertical que se adapte al ancho de un conjunto de botones, que a su vez se adaptan al tamaño
de sus textos?
Bien, en este caso el Content Size Fitter se encuentra en la lista vertical con su correspondiente Vertical Layout Group,
que controlará tanto alto como ancho de sus hijos, los ajustes se realizan al tamaño preferido vertical y horizontal.
Por su parte, los botones, que cuentan con un Layout Element que define su altura, tienen además un Horizontal
Layout Group que controla el ancho de sus elementos hijos.
Esta combinación resulta en ese comportamiento deseado, pero como se puede observar se necesita pensar bien
qué elementos deben estar en cada lugar y con qué valores.
Fig.12. Ejemplo de elementos anidados cuyos tamaños se adaptan en distintos ejes
Debemos tener en cuenta que cuanto más complejas hagamos estas jerarquías, más compleja será la solución y más
problemas podemos encontrar para llegar a la solución requerida.
Por ello, es importante que conozcamos nuestras limitaciones y adaptemos el diseño de los interfaces a aquel tipo
de composiciones con las que nos sintamos más cómodos ya que si no tenemos una visión clara de cómo obtener un
resultado concreto, podemos generar errores en nuestra interfaz adaptable.
Además, ya conocemos distintos motivos por el que el tamaño de nuestros contenidos, especialmente en el caso de
los textos, puede sufrir cambios por aspectos tales como la localización, por lo que esto debe ser tenido en cuenta
en los diseños.
Por ejemplo, si vamos a crear una botonera con textos, debemos asegurarnos de que no usamos toda la longitud disponible
para permitir que estos puedan crecer (o decrecer si así se desea) de acuerdo a los textos que deban ser aplicados.
Siempre debemos intentar generar una jerarquía lo más plana posible, pero componiendo todos los elementos en
grupos que resulten claros, que faciliten la creación de los grupos necesarios para la aplicación de los layouts, y que
nos permitan identificar sin dificultades cada elemento de nuestra composición.
Analiza tus limitaciones, tenlas presente, y sé lo más pulcro y lógico posible cuando definas tus interfaces.
/ 9. Scroll view con una cantidad de elementos dinámicos

Volviendo la vista a las unidades anteriores, recordemos el componente Scroll View, que entre otros usos nos permite
crear listas navegables de una gran cantidad de elementos en una zona visible de tamaño más reducido.
Vimos cómo podemos colocar los elementos que queremos visualizar en su objeto Content, pero no contábamos con
ninguna herramienta para reajustar de forma automática su tamaño cuando añadimos elementos de forma dinámica.
Desarrollo de entornos interactivos multidispositivo / 10
Bien, el Content Size Fitter es el elemento que nos faltaba para automatizar nuestros scroll views.
Para ello, la solución más directa es usar un Vertical u Horizontal Layout Group en Content, así como un Content Size
Fitter configurado para ajustar el tamaño en aquella dimensión que necesitemos.
Los elementos de la lista serán los hijos directos de Content, que tendrán un Layout Element que definirá las
condiciones de tamaño que deseamos aplicar. Por ejemplo, podemos hacer que el grupo controle el ancho de
los elementos para que se extiendan horizontalmente, pero su alto sea controlado por el valor definido en la
configuración de cada elemento en su Layout Element.
Dentro de cada ítem de la lista, podemos ordenar aquellos elementos que queramos incluir de la forma que nos
resulte más adecuada.
En la siguiente imagen puedes ver un ejemplo de lista de contactos donde cada uno de los ítems de la lista son a
su vez un grupo horizontal que incluye tanto una foto del usuario como un texto con su nombre. En ella se puede
observar el resultado en pantalla, el estado real del canvas, con la máscara del scrollview deshabilitado, para que
pueda observarse como el tamaño de Content se ha ajustado de forma exacta a la cantidad de elementos actual, la
jerarquía de elementos, y finalmente la configuración del objeto Content.
Fig.13. Ejemplo de una lista de contactos
Aplicando esta filosofía, podemos añadir objetos de forma dinámica a nuestras listas y el tamaño del contenedor
principal se adaptará a la superficie total ocupada, lo que hará que los controles de navegación siempre operen sobre
la superficie correcta.
Sabías que...
El Scroll View de Unity no es muy eficiente ya que genera tantos
elementos como se desee utilizar en las listas. Existen herramientas
como el Enhanced Scroller de echo17 para Unity que mejora la gestión
de memoria re-usando los elementos visuales.
/ 10. La navegación entre pantallas

El concepto de pantalla de interfaz en Unity es algo difuso. Una pantalla puede ser un panel con cierta configuración,
un canvas con los elementos que la componen, o incluso un conjunto de ellos que deben ser activados a la vez.
Hablamos de navegación entre pantallas como el paso de una pantalla a otra, que puede ser realizado de múltiples
formas.
/ 11 MEDAC · Instituto Oficial de Formación Profesional
Daremos ciertas directrices sobre estas, ya se haga de forma más rudimentaria o con un control dinámico más
avanzado.
Audio 1. “Navegando entre pantallas”

https://bit.ly/3vN9HaO
En primer lugar intentemos tratar la pantalla como un elemento que puede contar con múltiples capas.
Vamos a pensar en un ejemplo concreto, una aplicación que cuenta con una barra de opciones en la zona superior y
una barra de ayuda en la zona inferior, mientras que únicamente el contenido de la zona principal cambia en función
de las opciones seleccionadas.
En este caso, ¿qué consideramos una pantalla?
Podríamos considerar que cada pantalla incluye todos los elementos que aparecen en la misma, incluyendo la propia
barra de opciones superior y la barra de ayuda.
También podríamos considerar que las pantallas navegables deberían incluir sólo la zona principal de contenido,
y tanto la barra de opciones superior como la barra de ayuda son dos secciones complementarias que deben ser
manipulables de forma independiente.
Cuando tomamos estas decisiones lo más importante es que seamos conscientes de las implicaciones de cada una
de ellas.
Por ejemplo, si decidimos que una pantalla en nuestra aplicación incluye todos los elementos, esto nos obligará a
replicar tanto la barra superior como la inferior visual y funcionalmente en todas nuestras pantallas. ¿Esto tiene
sentido? ¿Tenemos una forma de hacerlo de forma rápida o estamos obligados a repetir trabajo?.
Si decidimos que debemos reutilizar esas secciones de pantalla, nos

obliga a mantener un control de la situación actual del UI segmentado, y
normalmente afectará a la forma en que gestionamos el canvas, ya que
contará con una parte fija y otra parte variable. ¿Somos capaces de realizar
estas gestiones de nuestra interfaz de forma sencilla? ¿Contamos con el
conocimiento necesario para que escribir el código necesario no nos resulte
una tarea demasiado compleja o tediosa?
Hay soluciones mejores y peores, pero debemos ser prácticos y conscientes

de nuestro conocimiento actual. Tomemos un camino u otro porque se
ajuste mejor a nuestra capacidad actual, siempre debemos tener en mente Fig.14. Deberemos tomar muchas decisiones.
que nuestra interfaz debe cumplir unos fines funcionales que debemos Hagámoslo siendo conscientes de nuestros
satisfacer. recursos y nuestro nivel
/ 11. Canvas completo o múltiples canvas con

habilitación y deshabilitación
Cuando no queremos complicaciones y no nos importa ser menos eficientes y que nuestra interfaz no tenga un rendimiento
óptimo, podemos optar por la solución más habitual, consistente en usar un único Canvas con todo el contenido.
Dentro de este Canvas completo, creamos paneles principales, cada uno de ellos definiendo bien una pantalla
completa, bien una zona común entre múltiples pantallas.
En cada uno de estos paneles-pantalla, creamos todos los contenidos necesarios para mostrar la información
requerida o recoger del usuario los datos que nos interesen.
Una vez el contenido está completo, desactivamos todos los paneles menos aquellos que deben mostrarse al
arrancar la aplicación.
En este sistema de canvas completo, el código que escribiremos se encargará de encender y apagar los paneles
que corresponda en cada momento según las pantallas a las que naveguemos o los popups, etc. que tengamos que
presentar al usuario.
Una ventaja de esta aproximación, si no tenemos mucha experiencia manteniendo la consistencia de la información
en nuestras pantallas, es que si queremos mantener los datos de una pantalla almacenados al volver a ella, al no
destruirse en el cambio de pantalla estas permanecen tal cual se dejaron al abandonarlas.
Además evitamos tener que controlar qué elementos hemos generado y cuáles no, etc.
Las principales desventajas de esta aproximación son la poca eficiencia tanto a nivel de rendimiento como de uso
de memoria, su poca escalabilidad y toda la problemática relacionada con la nula separación real entre contenidos.
Dado que al modificar cualquier elemento de un canvas forzamos que se lancen procesos de actualización y
redibujado, en algunas ocasiones se opta por usar canvas individuales para los distintos componentes, que agiliza
la carga de cada canvas a modo individual pero sigue sin ayudar a optimizar la carga en memoria y la organización
y escalabilidad de nuestro interfaz.
Sin embargo, al separar pantallas en Canvas, también nos permite hacer uso del sort order de este para definir la
ordenación de este contenido distribuido, lo que nos ayuda a garantizar que ciertas pantallas siempre aparezcan
sobre otras (por ejemplo los popups sobre las pantallas estándar).
Fig.15. Canvas completo y Canvas completo con canvas individuales por pantalla
/ 12. Caso práctico 2: “Creando una interfaz sencilla”

Planteamiento: Es nuestro primer día en una oficina de una pequeña empresa indie que desarrolla pequeños
videojuegos bajo demanda. El equipo al que nos hemos incorporado ha sufrido bajas y un cliente ha pedido que se
entregue de forma inmediata su juego que ya ha sufrido varios retrasos.
Nudo: El videojuego está terminado, pero la persona que lo creó ya no está en el equipo. Todo está preparado y lo
único que falta es hacer un pequeño menú de bienvenida, comienzo de partida y game over. Está todo preparado,
pero tenemos poco tiempo para completar la tarea, y nuestro nivel de habilidad todavía es relativamente bajo,
por lo que no sabemos si deberíamos intentar crear una interfaz muy optimizada que tenga un comportamiento
y rendimiento óptimo, o aplicar el conocimiento básico que si se tiene para hacer el conjunto de pantallas, aunque
la forma en que lo hacemos no suele ser la recomendada por los expertos.
Desenlace: Si bien durante la docencia se os anima a que aprendáis a realizar vuestras actividades profesionales
de la forma más correcta posible, en vuestros primeros compases en una empresa tendréis un conocimiento muy
limitado, os puede faltar personal con experiencia al que preguntar en caso de tener algún problema, y podéis
cometer el gran error de querer demostrar vuestra valía por encima de vuestro conocimiento actual. En estos casos
mientras adquirís conocimiento, si las condiciones para realizar un trabajo requieren rapidez y no estáis seguros de
cómo ejecutarlo de la mejor manera, intentad sed lo más resolutivos posibles dentro de vuestras posibilidades, ya
que un resultado tardío o con errores siempre jugará en vuestra contra.
En este caso concreto, los videojuegos que se crean son muy sencillos y apenas cuentan con unas pocas pantallas.
Tampoco hay demasiados elementos en cada pantalla, y en ningún caso se usarán en dispositivos con limitaciones
extremas de memoria o procesador, por lo que en este caso sólo debéis crear una pantalla de bienvenida con un “tap
to play”, una pantalla de “Start game”, y la pantalla final de “Game over”.
En este caso, la optimización y el rendimiento no son una preocupación real que afectaría al proyecto, sino algo
deseable a nivel profesional, y por lo tanto deberías aplicar la metodología que te resulta más conocida y que sabes
que te permitirá completar el interface a tiempo y libre de errores.
Fig.16. Los menús pueden comenzar a presentar problemas de rendimiento cuando generan gran
cantidad de elementos, por ejemplo en grandes listas de ítems
/ 13. Canvas por pantalla aplicando creación/

destrucción dinámica
Cuando se crean interfaces más complejos, suelen utilizarse estrategias dinámicas, donde sólo los elementos que
se encuentran en uso por la interfaz estarán cargados en escena.
Esto lo podemos hacer a través de la instanciación y destrucción de paneles o Canvas. Normalmente se opta por lo
segundo, definiendo cada pantalla como un Canvas totalmente independiente ya que así los cambios en una pantalla
no fuerzan la actualización y redibujado del resto de pantallas.
Para ello, creamos cada pantalla como un Canvas totalmente independiente. Esto además nos permite aplicar
distintos settings si fuese necesario a cada uno de ellos.
Si existen zonas comunes, como las barras de herramientas, etc, creamos estos elementos también como Canvas
independientes, ya que podemos crearlos y destruirlos como nos dicte la lógica de navegación.
En este caso, el sistema de control de la navegación instancia al arrancar la pantalla de bienvenida que mostraría el
mensaje de “tap to play” y el logo del videojuego. No habrá nada más salvo esos elementos, que son los que deben
visibilizarse en ese momento.
Una vez tocamos la pantalla, nuestro gestor de pantallas recibe el evento y decide el cambio a la pantalla de login,
destruyendo la pantalla instanciada de bienvenida y creando una instancia de la pantalla de login.
Recordemos que hablamos de instancia porque cuando aplicamos la orden de instanciado a un prefabricado, estamos creando
una copia totalmente autónoma. Nunca hacemos operaciones directas sobre un prefabricado, ya que es una plantilla.
Si fallamos realizando el login, puede instanciarse una ventana de popup, con un sort order superior al de la pantalla
de Login para que la bloquee. Este popup nos informará del motivo del fallo de acceso, teniendo que pulsar un botón
de aceptar para continuar.
En este caso por ejemplo, no destruimos la pantalla de login al mostrar el popup, sino que la tratamos como una
capa adicional.
Al aceptar el mensaje, la instancia del popup es destruida, volviendo a quedar como pantalla actual la pantalla de Login.
Cuando el usuario completa el login correctamente, destruimos la pantalla de Login y creamos una instancia de
la barra de herramientas, otra de la barra de ayuda y otra instancia de la pantalla Home. Ahora son 3 los canvas
simultáneos en pantalla, pero sólo existen elementos que deben verse en este momento.
Fig.17. Elementos en escena en cada uno de los 3 momentos
¿Cómo gestionamos desde código este comportamiento?
/ 14. Gestionando un sistema de pantallas dinámico

Antes de comenzar, recordemos que cuando creamos interfaces debemos separar siempre la lógica de datos de la
visualización de estos. Es habitual el uso de patrones como MVC.
Enlaces de interés...
Aquí puedes leer sobre el patrón de diseño MVC, que aunque no tiene
en cuenta las particularidades de Unity, te permitirá tener una vista más
general sobre él. https://bit.ly/3p2bPHZ
Al gestionar la navegación entre pantallas de forma dinámica, recomendamos que se trabaje de la siguiente manera.
Se creará un script que se encargará de gestionar la presencia de la pantalla principal y sus diferentes componentes UILogic.
Este definirá todas las acciones de navegación entre pantallas y dejaremos que sean las propias pantallas de forma
individual las que gestionen la creación y destrucción de popups o elementos emergentes relacionados con la
interacción con ellas, y que una vez destruidos normalmente nos hacen volver a dicha pantalla.
Fig.18. Ejemplo de script básico de gestión de la lógica de navegación

Las vistas de las pantallas principales heredarán de una clase común que las identifica fácilmente, por ejemplo
ViewScreen.
A este método podemos asociarle un modelo de datos que indica sus necesidades, y que podemos obtener por
ejemplo mediante una llamada al método GetViewModel.
A partir de él, podemos conocer los elementos complementarios que necesita la pantalla y usar los modelos de
settings de cada uno de ellos para pasar toda la información de golpe a los elementos interesados.
Consideremos que existen una barra de herramientas y una barra de ayuda., estas contarán con clases específicas
separadas de las pantallas principales, por ejemplo ViewToolBar y ViewHelpBar.
Nuestro sistema de lógica guarda en todo momento una referencia a la pantalla actual y las barras existentes. En el
ejemplo se usan las variables currentScreen, currentToolBar y currentHelpBar.
Los popups heredarán de una clase PopUp que las diferenciará del resto de pantallas y componentes. Normalmente
los popups no serán gestionados desde el script de lógica de navegación, sino que lo hará la lógica individual de cada
pantalla según las interacciones que tengan lugar con el usuario.
Con esta organización, cada vez que navegamos a una pantalla con la orden NavigateTo, se analizará qué elementos
deben ser destruidos, creados, o reconfigurados, se eliminará la pantalla actual y se creará una instancia de la nueva
pantalla deseada.
/ 15. Resumen y resolución del caso práctico de la unidad

En esta unidad hemos presentado el componente Content Size Fitter y cómo su uso nos ayuda a ajustar y adaptar el
tamaño tanto de componentes individuales como de elementos contenedores e incluso grupos de estos. Además,
hemos analizado distintas formas de navegar entre pantallas y los aspectos que influyen en ellos, explicando de
forma breve una metodología de navegación dinámica.
Uso de un canvas Gestión de elementos fijos

Size Fitter y metodologías
El componente Content
Navegación entre pantallas

Gestión de elementos fijos
de navegación
Uso de múltiples
canvas un canvas
Gestión de elementos dinámica
Uso en elementos independientes

Content Size Fitter
Uso en grupos Uso en grupos con jerarquía compleja
Fig.19. Esquema resumen del tema
Resolución del caso práctico de la unidad

En el siguiente vídeo podemos encontrar la resolución al caso práctico planteado al comienzo de la unidad.
Video 1. “Uso de Content Size Fitter”

https://bit.ly/3P5EXIT
/ 16. Bibliografía
Documentación sobre el Layout Element de Unity3D. (s. f.). https://docs.unity3d.com. Recuperado 24 de junio de 2022, de
https://docs.unity3d.com/Packages/com.unity.ugui@1.0/manual/script-LayoutElement.html

PDF. Desarrollo de Entornos Interactivos Multidispositivo. Tema 9

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PDF. Desarrollo de Entornos Interactivos Multidispositivo. Tema 9

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE ENTORNOS INTERACTIVOS

/ 2. El origen del problema que trata este componente 4

/ 3. El componente Content Size Fitter 4

/ 4. Caso práctico 1: “Decisiones de diseño” 5

/ 5. Uso básico del componente 6

/ 6. Las jerarquías y su influencia en la acción del componente 7

/ 7. Resultados habituales de un mal uso jerárquico del componente 8

/ 8. Previsión de problemas y actuaciones preventivas 9

/ 9. Scroll view con una cantidad de elementos dinámicos 9

/ 10. La navegación entre pantallas 10

/ 11. Canvas completo o múltiples canvas con habilitación y deshabilitación 11

/ 12. Caso práctico 2: “Creando una interfaz sencilla” 12

/ 13. Canvas por pantalla aplicando creación/destrucción dinámica 13

/ 14. Gestionando un sistema de pantallas dinámico 14

/ 15. Resumen y resolución del caso práctico de la unidad 15

Entender sus limitaciones y cómo le afecta el resto de componentes en su

Comprender distintas metodologías de navegación entre pantallas.

/ 1. Introducción y contextualización práctica

En esta unidad trataremos este problema y mostraremos además distintas

Audio Intro. “El componente Content Size

/ 2. El origen del problema que trata este componente

Ahora volvamos a recordar cómo afectan las traducciones a nuestros diseños

La adaptación del contenedor a la localización de textos es por tanto otro

Si piensas en ellos, podrás imaginar multitud de casos en los que ya no sólo

/ 3. El componente Content Size Fitter

Fig.3. Componente Content Size Fitter

• Unconstrained. No aplica ningún tipo de limitación en el eje.

Así es posible que definamos un contenedor donde el alto o el ancho no será

Podemos aplicarlo a cualquier objeto de nuestro UI a través del menú de

Usándolo, vamos a poder adaptar el tamaño de elementos de todo tipo de

/ 4. Caso práctico 1: “Decisiones de diseño”

Desenlace: Nuestro Content Size Fitter permite configurar tanto la forma en

En este caso sólo queremos que su tamaño crezca verticalmente junto

/ 5. Uso básico del componente

B. Con Layout Element con valores Min y Preferred

/ 6. Las jerarquías y su influencia en la acción del

Fig.8. Warning cuando el padre es de tipo Layout Group

Fig.10. Ejemplo de aplicación para ajustar tamaño de botón a su texto

/ 7. Resultados habituales de un mal uso jerárquico del

/ 8. Previsión de problemas y actuaciones preventivas

Fig.12. Ejemplo de elementos anidados cuyos tamaños se adaptan en distintos ejes

/ 9. Scroll view con una cantidad de elementos dinámicos

Fig.13. Ejemplo de una lista de contactos

/ 10. La navegación entre pantallas

Audio 1. “Navegando entre pantallas”

En este caso, ¿qué consideramos una pantalla?

Si decidimos que debemos reutilizar esas secciones de pantalla, nos

Hay soluciones mejores y peores, pero debemos ser prácticos y conscientes

/ 11. Canvas completo o múltiples canvas con

/ 12. Caso práctico 2: “Creando una interfaz sencilla”

/ 13. Canvas por pantalla aplicando creación/

Fig.17. Elementos en escena en cada uno de los 3 momentos

¿Cómo gestionamos desde código este comportamiento?

/ 14. Gestionando un sistema de pantallas dinámico

Fig.18. Ejemplo de script básico de gestión de la lógica de navegación

/ 15. Resumen y resolución del caso práctico de la unidad

Uso de un canvas Gestión de elementos fijos

Navegación entre pantallas

Uso en elementos independientes

Fig.19. Esquema resumen del tema

Resolución del caso práctico de la unidad

Video 1. “Uso de Content Size Fitter”

También podría gustarte