Las ventajas de diseñar mediante código

0 448

En esta nueva entrega de Code Time continuamos con el camino de la programación y seguimos enfocándonos en el diseño de Interfaces Gráficas de Usuario. Hasta el momento se presentaron los pros de trabajar con Interface Builder y hoy nos centraremos en explicar cuáles son las ventajas de diseñar mediante código.

Antes de continuar te recomendamos leas la nota a la que se hace referencia en el primer párrafo y sigas sus referencias para poder tener un mejor conocimiento sobre el tema. A lo largo de la nota se supondrán ciertos conocimientos ya explicados.

Las ventajas de diseñar mediante código

Generalmente para todo principiante diseñar Interfaces gráficas de usuario no es algo fácil. Es aquí donde los Interface Builders pueden ser de mucha ayuda, Peros estos no son perfectos. Es verdad que cuentan con múltiples abstracciones y ventajas pero también hay ciertas contras. Por eso a continuación pasaremos a listar las ventajas de diseñar mediante código.

Elegir explícito sobre implícito

Descripción gráfica explícito vs implícito
Descripción gráfica explícito vs implícito

Cuando uno diseña utilizando un Interface Builder lo que en realidad se hace es abstraer la escritura del código mediante una herramienta que lo hace por nosotros. Luego el compilador o intérprete tomará el o los archivos con las configuraciones y generará el código ejecutable.

El problema con este proceder es que muchos ajustes quedan implícitos. Es verdad que se pueden configurar algunas cosas mediante los inspectores de atributos entre otras opciones pero no es suficiente. Gracias a esto es probable que muchas veces la interfaz gráfica no se comporte como uno quiere por algún ajuste que uno accidentalmente cambió.

Para citar un ejemplo he trabajado en el diseño unas TableView en Xcode y por alguna razón estas no se ajustaban al data source y al delegate. Luego de un buen rato de intentar solucionarlo me topé con que el problema realmente estaba en un checkbox que indicaba que la tabla no era editable. Algo tan simple puede llevar a uno a perder mucho tiempo. Y se que suena algo tonto pero realmente un clic accidental en un lugar equivocado puede llevar a este tipo de pérdidas.

La solución mediante el código

A diferencia de lo antes descrito trabajando con código obliga a explicitar cada cosa. De esta forma siempre habrá un comportamiento por defecto que podemos modificar mediante las configuraciones con métodos y atributos. Pero todo es visible, nada queda escondido.

Obviamente para que esto tenga sentido es necesario tener cierto conocimiento de la implementación lo que deriva indefectiblemente a leer la documentación.

Por otra parte al estar las cosas explícitamente establecidas es más fácil para alguien que ingresa a un proyecto entender cómo fueron creadas las cosas y cómo deben reaccionar.

Es más fácil de escalar y reutilizar

La escalabilidad
La escalabilidad

Trabajar con Interface Builder hace las cosas más simples al principio. El problema con esto se da cuando un proyecto es grande y se trabaja, por ejemplo, con un sistema de control de versiones. Dos personas podrían modificar la GUI de una aplicación y el realizar un merge de eso puede ser conflictivo.

Para que este problema sea más visible tiene que darse el caso de que la interfaz tiende a un diseño mediante storyboards, como ser con Xcode (esto lo trataremos más específicamente en otra nota). Los storyboards se caracterizan con concentrar una buena cantidad de controladores de vista (View Controllers). De esta forma una persona puede cambiar los ajustes de una vistas y otra incorporar un nuevo controlador. Al hacerse un pull habrán conflictos ya que ambos modificaron el archivo de la GUI.

Es necesario recordar que los IBs están pensados para ocultar los detalles de implementación y a pesar de que los archivos que estos generan son legibles, su modificación no es necesariamente trivial y es peligrosa.

El código al rescate

Nuevamente el trabajo con código trae una solución. La idea de modularidad es justamente separar los componentes en base a su funcionalidad. De esta forma los archivos de dos View Controllers están en dos archivos separados. Así pues es posible modificar varias partes de la GUI con mucho menos riesgo de generar conflictos.

Obviamente si dos usuarios trabajan con el mismo archivo el problema se repetirá, pero al ser código es más fácil de realizar un merge decente. Por no mencionar el hecho de que la modularidad reduce la probabilidad bastante.

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

A reutilizar componentes

Una de las bases del desarrollo de software es generar soluciones coherentes, En esto debemos tener en cuenta que la solución no debe ser más compleja que el problema. Por esot las buenas prácticas indican muchas veces trabajar con componentes más genéricos. De esa forma no solo son capaces de resolver más de un problema sino que esos mismos componentes pueden ser reutilizados en otros proyectos.

De esta forma la escalabilidad y reusabilidad son mucho mayores trabajando con código y el tiempo que puede ahorrarse aplicando buenas prácticas ayuda a mejorar el rendimiento del desarrollo en general.

La estabilidad

Con esto no quiero generar un malentendido. Trabajar con Interface Builder no hace que la aplicación resultante sea peor en rendimiento ni nada por el estilo. Esto se enfoca más que nada a la herramienta de desarrollo.

Cuando uno utiliza un IDE para desarrollar estos suelen incorporar un Interface Builder, editores de texto, compiladores, debuggers entre otras cosas. El problema se enfoca más que nada a la estabilidad de la herramienta en general. No existe programa perfecto. Un fallo en el Interface Builder puede llevar a pérdidas de configuración, cuelgues e incluso pérdida de rendimiento en el sistema. Esto se da ya que este tipo de utilidades suelen consumir muchos recursos.

¿Cual es la ventaja del código aquí?

Esto es más bien cuestión de probabilidad y rendimiento. Cuando uno trabaja diseñando mediante código solo se requiere un editor de texto mientras que al utilizar un Interface Builder también es requerido ejecutar ese programa. De esta forma es fácil deducir que el consumo de recursos será mucho menor y habrán menos probabilidades de que la herramienta crashee.

Las desventajas de diseñar mediante código

Obviamente no todo es bueno y de hecho en la nota anterior se han mencionado las ventajas de trabajar con Interface Builder, que podríamos interpretarlas como las contras de diseñar mediante código. Ahora pues veremos una ventaja/desventaja del suo del código.

Es complejo al principio pero más claro al final

¿Qué significa esto? Bueno en si diseñar mediante código requiere ciertos conocimientos como los componentes visuales, sus propiedades, funciones, delegados, etc. Para cualquier principiante esto solo logrará asustarlo. Se requiere de paciencia y diligencia leyendo documentación, otras implementaciones y practicando.

Es una ardua tarea pero a la larga lleva a la compresión del funcionamiento interno de muchas cosas y a diseñar de una mejor manera. Así pues el resultado para un experto llega a ser mucho más claro estando explícito en un archivo de código que mediante un Interface Builder.

Para cerrar

Antes de terminar aclaro que la cosa no termina aquí. Aún queda ver el uso de Storyboards entre otros recursos pero primero era necesario ver todo lo referente al diseño mediante código e Interface Builder. Así pues con esto cerramos este artículo y presentamos la parte final sobre diseño de GUIs.

Esperamos que les haya gustado la nota y que les haya sido de utilidad. Si así fue déjanoslo saber en los comentarios. Su opinión 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...

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More

Privacy & Cookies Policy