Modularización en Android (técnicas)
La modularización en Android es un modo de conseguir que nuestras apps sean más escalables.
Por un lado, nos permite separar responsabilidades. Con lo que cada módulo tiene su propio cometido.
Y por el otro, hace que los tiempos de compilación se reduzcan.
Este contenido está restringido.
Adquiere alguna formación.
O suscríbete para difrutar de los audios y vídeos exclusivos de Los androides Premium.
Hay 2 técnicas principales de modularización principales: la horizontal y la vertical.
¿Has visto la charla técnica de Javi Segovia sobre modularización en Android?
Modularización horizontal en Android
La modularización horizontal, también llamada en ocasiones por capas, nos permite separar los módulos en función de las capas de arquitectura.
Un ejemplo de módulos horizontales, podría ser domain, data, presentation…
Pero siendo práctico, esto suele ser en proyectos pequeños. Lo más normal es que estos módulos horizontales, sean elementos comunes dentro del proyecto. Por ejemplo, core, framework, analytics, etc.
Aunque también se podría dar el caso en el que en cada feature también se dividiera entre módulos horizontales, para asegurar que se sigue la arquitectura. IMHO, esto sería un poco overkill…
Modularización vertical en Android
La modularización vertical o por feature, nos permite separar el proyecto por funcionalidades.
Esto es superpráctico porque es lo que permite que el proyecto se vuelva muy escalable.
Si te interesa mejorar tus conocimientos en este campo,
es probable que también te interese el Audiocurso de Modularización en Android.
Tiempos de compilación
El hecho de que el código esté dividido en módulos es la caña. Ya que de la manera en la que Gradle gestiona el proyecto, nos permite que si un módulo no ha tenido cambios (ni los módulos de los que depende), no haga falta que se recompile. Lo que hace es coger la última build que tenga cacheada (si no es que es la primera vez, o se ha hecho un rebuild).
Por lo tanto, ese tiempo que nos ahorramos.
Con lo que cuantos más módulos tengamos, mejor. Sin volverse locos, claro. 😁
Consideraciones
Biblioteca Kotlin Vs Biblioteca Android
Ten en cuenta, que los módulos siempre deberían ser lo más puros posibles.
Me explico.
Que si un módulo no le hace falta el framework de Android, pues se hace de Kotlin puro.
Hacer una biblioteca de Android para algo que no le hace falta, sería un consumo de recursos superfluo.
Trabajo en equipo
También hay que tener presente que los módulos son una maravilla para trabajar en equipo.
Ya que podemos asignar el ownership de cada uno de estos a la persona / equipo / squad responsable.
Incluso te puedes crear un OWNERSHIP.md para tenerlo a mano y a la vista. Además, así lo tienes en tu control de versiones para ir actualizándolo.
Submódulos
Un modo muy práctico de organizar los módulos es precisamente hacerlo a través de submódulos.
A mí personalmente me gusta meter todos los horizontales dentro de uno llamado modules. Puedes verlo en el proyecto Base, que es donde está la app de «Los androides». Es el módulo de app gabimoreno.
Y los verticales, dentro de uno llamado features.