BandaGeek.com es un blog de noticias en tecnología , tutoríales y entretenimiento. Aquí encuentras todo lo relacionado con la vida 2.0

¿Cómo se diseña una Interfaz Gráfica de Usuario?

En esta nueva entrega de Code Time continuamos con el camino de la programación hablando sobre diseño de GUIs. Para cerrar con la saga de episodios enfocados a explicar las metodologías de diseño hoy veremos cómo se diseña una Interfaz Gráfica de Usuario.

Nota: antes de continuar es recomendable leer las notas anteriores referidas al tema. De esa forma se podrá tener un mejor contexto de todo lo que se está hablando. Si estás interesado en hacerlo aquí tienes el enlace directo.

¿Cómo se diseña una Interfaz Gráfica de Usuario?

Esta pregunta no tiene una sola respuesta. Gracias a los avances a lo largo de los años hoy en día existen innumerables formas de diseñar una GUI, que van desde el uso de Interface Builders, Storyboards, código, etc.

Para saber qué opción escoger explicaremos en qué consiste cada una y de ahí en más queda en uno el tomar la decisión en base a las ventajas / desventajas de la misma.

Los Storyboards

Hasta ahora se ha hablado del Interface Builder para diseñar vistas individuales de una GUI. Pero la verdad es que es posible agrupar un buena cantidad de estas y diseñar el flujo visual de un programa.

Los Storyboards son representaciones gráficas del flujo de una aplicación. Estos cuentan con la ventaja de poder diseñar toda la interfaz gráfica dentro de un solo entorno. E incluso es posible crear storyboards para trabajar con distintas plataformas.

El primer entorno de desarrollo que se me viene a la mente por experiencia propia es Xcode. Dentro de esta gran IDE la forma principal de diseño de interfaces gráficas es mediante un Interface Builder que permite manipular un Storyboard (luego pueden incorporarse más).

Las desventajas de trabajar con Storyboards

Para todo principiante trabajar de esta forma es casi un sueño. El diseño a priori no podría ser más facil. Pero no todo es perfecto. Toda abstracción o simplificación y trae consigo algún sacrificio. De estos muchos son coincidentes con las desventajas de usar Interface Builder pero en ciertos casos el problema empeora.

Conflictos de fusión Git

Un momento de humor patrocinado por git merge
Un momento de humor patrocinado por git merge

Esto ya se habló con anterioridad. Aun así presentaremos nuevamente el contexto. Consideremos a dos personas trabajando en un proyecto. Ambos trabajan en todas las áreas de la aplicación desde el diseño hasta implementación. Un dia uno de ellos decide modificar el storyboard e incorporar un nuevo View Controller. Al mismo tiempo el otro tiene la idea de modificar levemente una vista existente para hacerla más fácil de usar. El problema se plante al momento de hacer el push.

Los Storyboards suelen ser tratados dentro de un mismo archivo. Por lo cual al hacer el push al repositorio habrá con conflicto y habrá que tomar medidas para resolverlo. Esto se traduce en una pérdida de tiempo que puede ir de unos minutos hasta horas que requerirán debates y acuerdos. Y si recordamos aquí se estaba desarrollando una aplicación para resolver problemas, no generarlos.

Obviamente todo esto depende del entorno de trabajo. Hay herramientas que solventan este problema bastante bien. Pero no se quita la probabilidad de que se produzcan conflictos. Ahora bien si lo escalamos a un proyecto de trabajo mucho mayor donde más de 5 personas trabajan, las chances de error se incrementan aun más.

Inicialización inadecuada

Los Storyboards se caracterizan por agrupar vistas simples las cuales interactúan entre sí. Imaginemos una Tableview que al presionar una de sus opciones nos lleva a una descripción más detallada del ítem. Para poder realizar esta acción es necesario decirle a la vista de detalle qué ítem es necesario expandir. Cada sistema tiene su forma de hacerlo.

En el caso de Xcode es bastante simple: se utilizan los “segues”. Al llamar al cambio de vista es posible pasar cierta información e incluso existen un método llamado prepareForSegue que cuenta con acceso al View Controller de origen y el de destino. Así pues uno puede realizar las configuraciones que sean necesarias.

El problema comienza cuando dentro del método de transición ocurren problemas de manejos de opcionales. Si no es posible obtener toda la información necesaria lenguajes como Swift permiten continuar trabajando gracias al encadenamiento de opcionales. Luego al mostrarse la nueva vista existe el riesgo de que esta no haya recibido toda la información necesaria y el resultado sea inadecuado. En otros casos podría ser peor: esto es que la aplicación entera crashee debido a puntero a null o algo por el estilo.

Las causas de la crisis

Es aquí donde trabajar con código es ventajoso. El problema en si no son los Storyboards aunque deriva de estos. La razón por la que las cosas fallaron es porque estos no cuentan con la obligación de llamar a un inicializador con los datos necesarios. Estos es gracias a la naturaleza de los mismos.

¿Cómo se inicializa mediante un Storyboard? Pues bien generalmente la creación de las vistas se hace mediante un código generado automáticamente por el compilador. Este no tiene contemplado ningún dato que nuestro código pueda proveer. Por eso permite luego de su inicialización, al hacer la transición, la configuración. La posibilidad de que se produzcan errores proviene de la falta de compromiso de la inicialización.

La salvación del código

Es aquí donde trabajar con código puede salvarnos. Al uno tener que crear la nueva vista explicitamente tiene uno que llamar a algún inicializador. Por eso antes es importante hacer que estos tomen toda la información necesaria. Así existe una obligación para el desarrollador y es imposible continuar sin estos datos.

Problemas de acoplamiento

Error de acoplamiento de botón con su acción en código
Error de acoplamiento de botón con su acción en código

Ya hemos hablado de la imperfección de los Interface Builders. Existen ciertas características a las que uno no puede acceder o configurar visualmente. Una de las más simples de ver es el establecimiento de respuestas a eventos como toques, clics, etc.

Al presionar un botón uno generalmente quiere poder reaccionar. Los IBs no proveen una forma directa de hacerlo por lo que es obligatorio recurrir al código. Generalmente uno diseña la parte visual en el Storyboard y finalmente asocia una clase al archivo para poder aprovechar de sus métodos.

El problema aparece cuando los acoples no se realizan de forma correcta por lo que este no surte efecto. Y uno diría ¿Qué tan difícil es detectar esta clase de errores? Pues bien, no estar preparado para esta clase de problemas puede llevar a la pérdida de horas de trabajo. Todo porque las cosas no se enlazaron.

Generalmente el problema se detecta al uno ver que un boton no responde o los resultados son irregulares. Luego de comentar secciones de código, plagar todo de prints uno se encuentra con que el Interface Builder no tiene la asociación. Y no solo se limita a no haber hecho el anclaje sino que también pueden producirse por fallos de la misma herramienta. He de decirles que puede ser muy frustrante ver que han sucedido este tipo de cosas en lo que han trabajado por tantas horas.

Tendencias a la complejidad excesiva

Clásico caos en Storyboard
Clásico caos en Storyboard

Una de las ventajas de la que habíamos hablado sobre los Interface Builders fue su facilidad de uso y comprensión a corto plazo. Pero no todo es perfecto. Eso compete más que nada a vistas simples donde las configuraciones son fáciles de ver. Pero todo cambia cuando trabajamos en un Storyboard.

¿Pues bién donde está el problema? Las cosas se complican cuando una aplicación llega a tener más de 5 o 6 View Controllers. En esos casos las conexiones pueden comenzar a hacerse confusas y no hablemos de aquellas apps diseñadas enteramente en Storyboard y que cuentan con tantas vistas como días tiene el año. Y créanme existen.

La cantidad de vistas, flechas que van de un lugar a otro, modularidades y más hacen de esto una pesadilla. Y no se hable de encontrar un error porque se convierte básicamente en el problema de “buscar una aguja en un pajar”.

Diseñando con Vistas individuales

Otra forma de trabajar con Interface Builder y evitar muchos de los problemas de los Storyboards es mediante el uso de vistas simples. Esta forma de diseño se caracteriza por contar con un archivo separado para cada Vista. Así pues el diseño se puede seccionar y por ejemplo los problemas de conflictos con sistemas de control de versiones se resuelven en su mayoría.

Esta metodología de aislamiento funciona bastante bien y permiten aprovechar las ventajas de los Interface Builders sin las desventajas de los Storyboards.

Algunas variantes

Diseño mediante vistas individuales
Diseño mediante vistas individuales

Cada sistema puede emplear variantes de esta metodología. Una de ellas que es utilizada por Xcode en mac OS se caracteriza por permitir la creación de clases con inicializadores personalizados. Así pues es imposible crear una vista sin proveer la información básica necesaria.

Ahora bien ¿Como se usa el Interface Builder? Pues bien para eso existen unos archivos llamados XIB (en el caso de Xcode) donde uno puede crear la instancia de la vista y la parte visual se carga desde estos archivos por lo que es posible juntar la facilidad del Interface Builder con el poder del código.

Por otra parte podríamos hablar de la forma similar que tiene Java FX para crear sus GUIs. Gracias al Interface Builder uno es capaz de diseñar la interfaz y manejar los comportamientos  mediante un controlador. La desventaja y ventaja, depende cómo se lo vea, es que las transiciones entre distintas “pantallas” de una aplicación hay que hacerla manualmente tal cual se haría mediante código.

Entonces pués, ¿cómo se diseña una Interfaz Gráfica de Usuario?

Como se podrán esperar no existe una sola respuesta a esta pregunta. Hemos tratado el diseño con Interface Builder mediante vistas individuales y Storyboards hasta escritura directa de código. Pero tiene que haber algún criterio. Por esto plantearé mi opinión al respecto.

Los XIBs y Storyboards son recursos poderosos pero no perfectos. Hemos mencionado los posibles problemas que los Storyboards pueden acarrear pero por su parte los XIB plantean sus problemas.

Los Storyboards no son malos

Imaginemos una aplicación con cinco vistas donde el flujo del programa está bien establecido. Casi que podríamos hacer una lista enlazada. Para manejar la interfaz gráfica son necesarios al menos 10 archivos (5 para las vistas y 5 para los controladores), esto considerando que cada una es diferente a la anterior. Además hay que agregar todos los archivos extras que forman parte del programa en si. Como podemos ver esta aproximación podría ser algo engorrosa por lo que utilizar código o Storyboard sería más organizado.

Si pensamos desarrollar una aplicación nosotros solos y esta tiene una Interfaz Simple y bien definida escoger trabajar con Storyboards no es una mala idea. Eso sí es importante considerar la escalabilidad del proyecto.

¿Es el Interface Builder malo?

Personalmente considero que no lo es. Pero también es verdad que da la facilidad de dejarse llevar y no considerar detalles importantes. Y esto se hace más grave al uno no aprender cómo es que están implementadas las cosas.

Por otra parte al programar mediante código uno está obligado a leer más sobre las implementación y así aprender los métodos y propiedades de cada componente y cómo interactúan. Es aquí donde la curiosidad es la mejor aliada.

Conclusiones

Existen muchas formas de diseñar Interfaces Gráficas de Usuario y como hemos visto cada una tiene sus pros y contras. Elegir una no es una tarea trivial. Si he de elegir alguna considero más sencilla los Storyboards. Pero a la hora de enriquecerme y darle verdadero poder a la implementación me decanto por el código en lo posible. Además hay que admitir que llama más la atención. Se que esto no significa nada pero al menos se siente lindo.

Esperamos que esta nota te haya gustado. Si así fue déjanos saber en los comentarios y no dudes en compartir. Su opinión muy es importante para nosotros.

Aprende a desarrollar aplicaciones para iOS 11
Mis medios de contacto

Twitter    Gmail

Contenido

Spreaker    iTunes    Ivoox    Canal de Telegram    Soundcloud    Youtube

Comentarios
Loading...