Prólogo – Motivación

Uno de los principales problemas que nos encontramos en los frameworks de desarrollo mobile es la tendencia a tener toda nuestra lógica implementada en una misma clase. En el caso de Android, suele recaer en las Activities, y en caso de iOS en los ViewControllers.

Este antipatrón ya se viene estudiando desde los noventa y se cita en varios libros de programación orientada a objetos con el sobrenombre de «God class» o «God object».

En la jerga Android se suele hablar de «God Activities», y en iOS se dice «Massive View Controller», creando un juego de palabras las siglas «MVC» del conocido patrón de diseño «Model-View-Controller».

En ambos casos, el problema en nuestro código aparece a medio o largo plazo, cuando tras intensas semanas de trabajo en nuestra App, las activities acaban teniendo por encima de 1000 o 1500 líneas de código.

La funcionalidad se cubre, el proyecto se entrega y el código se guarda durante un periodo de tiempo.

A medida que aparece el primer centenar de usuarios, los requisitos del problema cambian y aparecen nuevas funcionalidades muy prometedoras que no se habían pensado inicialmente.

Llega el momento de retornar al código que quedó guardado y de realizar los cambios pertinentes, y es entonces cuando nos encontramos con varios problemas graves:

• Dada la base de código existente, resulta muy difícil añadir funcionalidades que, a priori, deberían ser sencillas, y que frecuentemente se presupuestan en un número de horas y un plazo de entrega muy ajustados
• Al incorporar nueva funcionalidad a la aplicación, provocamos que otras partes dejen de funcionar correctamente. En lenguaje de programadores, «rompemos» otras partes de la App.

Cuando varios compañeros colaboran en el mismo proyecto, puede darse el caso de que un programador «rompa» funcionalidades de otro y posteriormente realice correcciones para devolver el programa a un estado coherente.

Cuando esta práctica se repite varias veces, llega un momento en que nadie del equipo conoce bien el funcionamiento de la App, nadie sabe si falla o no, y nadie conoce la forma de corregir los fallos. «Hemos creado un monstruo».

Es por esto que la comunidad realiza un gran esfuerzo en idear mecanismos que solucionen este tipo de problemas y un requisito indispensable para que no aparezcan, es hacer una correcta «Separación de responsabilidades».

Custom Views en Android – Introducción

Una de las formas más conocidas y ampliamente usadas de separar responsabilidades dentro del framework de Android son las denominadas «Custom Views de Android».

Como es bien sabido, Android incorpora la clase View de la cual heredan todos los widgets del sistema, como los botones (Button), las etiquetas (TextViews) o las imágenes (ImageView).

Todos estos widgets son personalizables en cuanto a color, tamaño, disposición de elementos y una larga lista de propiedades. Dicha personalización conllevará forzosamente un incremento de las líneas de código de nuestro proyecto.

Personalización de widgets – Contraejemplo

Imaginemos que queremos crear botones que muestren un texto con una fuente personalizada y que se “apilen” unos sobre otros con colores de fondo alternos, dependiendo de si son pares o impares.

Consultando algún tutorial básico de Android, la manera más sugerente de hacer esto puede parecer la que sigue:

El problema: Separación de responsabilidades.

La lógica que dibuja el color de fondo según la fila es par o impar recae en MainActivity. Del mismo modo lo hace la asignación de tipografía a la etiqueta.

A medida que la complejidad del problema al que nos enfrentamos vaya incrementándose, nuestra clase MainActivity crecerá notablemente en líneas de código. A largo plazo dará lugar a un serio problema en cuanto al mantenimiento de nuestra app.

Solución: Creando una Custom Views en Android

Para reducir la cantidad de código existente en el Activity, vamos a crear una Custom Views en Android que herede de Button y le asigne la tipografía y el color de fondo.

Como el color de fondo dependerá de si es un elemento par o impar, debemos almacenar esa información en la Custom Views en Android, por ejemplo mediante un Constructor que reciba un segundo parámetro booleano “isEven” que indique si es par, o bien a través de un setter.

Como puede verse, el código queda mucho más compacto:

Existen 3 formas principales de implementar Custom Views en Android:

1. Heredando de un widget (Button, TextView, ImageView).
2. Heredando de un Layout o ViewGroup e inflando un XML*.
3. Heredando de View y pintando en el Canvas.

Algunos ejemplos:

• De la primera: https://gist.github.com/voghDev/6b83aa0fd72fafc361aae1928d6abc98
• De la segunda: https://github.com/voghDev/ProgressButtonView
• De la tercera: https://github.com/dlazaro66/WheelIndicatorView

* Podría darse otro enfoque mixto como crear los widgets por código en lugar de XML.

La Custom Views que se muestra en este ejemplo pertenece al primer tipo, pues hereda de Button.

Desde AppAndWeb animamos a todos los desarrolladores Android a crear sus Custom Views, realizando una mejor separación de responsabilidades en su código, además de hacerlo más reutilizable entre proyectos.

Además, si quieres saber cual es la diferencia entre Transformación Digital y Digitalización, solo tienes que entrar aquí.

Un saludo y ¡feliz día programando!