Estructura de un

proyecto

Organizando nuestro código

 Contexto

Modularización
Agenda
Layers

Patrón Repositorio
Contexto
 Contexto

Es muy poco frecuente ver proyectos chicos o que una vez que son lanzados
no reciben más mantenimiento.

A medida que una aplicación crece, se van agregando nuevas funcionalidades

una tras otra. Esto se traduce en un aumento en las líneas de código, clases,
archivos y demás.

Para evitar entrar en caos, se hace necesario empezar a organizar el proyecto

de forma tal que sea fácil entenderlo, extenderlo y mantenerlo.
Nuestra premisa para estos problemas, va a ser...

¡Divide y vencerás!
Modularización
 Modularización

La modularización no es un concepto exclusivo de Android, sino que es

transversal a las tecnologías.

En el caso de Android, Consiste en dividir nuestro proyecto Android en un

conjunto de módulos y dependencias entre ellos.
 Modularización

Ofrece muchas ventajas:

- Desacoplamiento entre distintas funcionalidades

- Reutilización de código
- Escalabilidad
- Se adapta muy bien a equipos grandes, donde cada equipo es dueño de
uno o más módulos
- Incremento en la velocidad de compilación (Parallel + incremental)
- Obligatorio para usar Dynamic Features, Wearable apps, Instant Apps,
etc.
 La modularización de una app incluye
Modularización los siguientes niveles:

- App: Este módulo conoce a todas

las features. Se encarga de la
navegación entre ellas. Es el que
está configurado para generar
el .apk/.aab
Dependencia

- Feature: Cada una de las

funcionalidades de la app,
incluyen Activities, ViewModels,
lógica de negocio y más.
- Library: Clases y componentes
reutilizables. Suelen cambiar
poco.
 Modularización

Los módulos pueden ser de varios tipos:

- Android Library: Es el más común, utilizado para código Android,

generalmente features y libraries.
- Dynamic Feature: Son módulos que no se incluyen al descargar nuestra
aplicación, sino que una vez instalada la misma se hace su descarga e
instalación on demand.
- Instant Dynamic Feature: Son aplicaciones muy livianas que sirven como
"preview" de nuestra aplicación.
- Java/Kotlin library: Son libraries que no tienen código específico de Android.
 Modularización
¿Cómo creamos un nuevo módulo?

File -> New -> New Module...

Elegimos el tipo de módulo que

vamos a crear
 Modularización
¿Cómo creamos un nuevo módulo?

Elegimos

- Nombre del módulo

- Package name
- Lenguaje (Kotlin)
- Mínimo SDK soportado
 Modularización
¿Cómo creamos un nuevo módulo?

En la vista de Project, ya tenemos nuestro

nuevo módulo listo para usarlo y agregar
código
Ahora bien… la mayor parte del tiempo vamos a estar creando módulos del
tipo "feature" donde también deberíamos organizarlo.

Entonces… ¿cómo organizamos el contenido en cada módulo?

Layers
 Layers

Continuando con nuestro lema de "divide y reinarás", a nivel módulo podemos pensar en
algo más relacionado al separation of concerns.

Para ello, debemos identificar qué elementos o capas intervienen en nuestra funcionalidad.
Lo más común, es encontrarnos con lo siguiente:
 Layers

- Capa de presentación: Se refiere a todo aquello que implique algo visual y está
estrechamente relacionado a la plataforma, esto es, Android. Esto incluye Activity,
Fragment, ViewModel.
- Capa de dominio o negocio: Comprende todas las clases y reglas de negocio que
intervienen en la solución. Por ej: Artículo, Persona e interfaces de repositorio. No
contiene referencias a la plataforma.
- Capa de acceso a datos: Todo aquello que permita acceder a información y que luego
va a ser representado por objetos de domino. Acá encontramos las implementaciones
de los repositorios. Esto incluye Bases de Datos, conexiones con APIs externas, etc.
 Layers

¿Cómo hacemos la división de nuestro módulo?

Se realiza a nivel de package, por ejemplo:

Patrón Repositorio
 Patrón Repositorio

- Son clases o componentes que encapsulan la implementación de la capa de datos

y el acceso a los mismos.
- Por cada entidad debemos contar con un repositorio.
- Permiten testear nuestra lógica de acceso a datos de forma sencilla.
- La diferencia con los DAO, es que los repositorios no son los encargados de
acceder directamente a la base de datos.
- Fácil implementación de técnicas de caché.

Para seguir investigando Patrón Unit Of Work

Patrón Repositorio
Patrón Repositorio
Patrón Repositorio
Patrón Repositorio
 Links

● Guide to app architecture

● Modularization - Why you should care
● Clean Architecture Guide (with tested examples): Data Flow != Dependency Rule
● Design the infrastructure persistence layer