El diseño de alto nivel en aplicaciones Android define cómo se conectan todas las piezas que hacen una app escalable, mantenible y con buen performance. Aquí entenderás qué hace cada capa, desde el backend hasta los flujos visuales, y por qué separar responsabilidades cambia por completo la calidad del producto.

Esta guía está pensada para desarrolladores Android que quieren visualizar el panorama completo antes de escribir una sola línea de código.

¿Qué es el backend y por qué no debe vivir en la aplicación?

El backend es la capa que aloja los datos y las reglas de negocio del sistema [0:18]. Toda la información que el usuario crea o consume viaja hacia allá, y es ahí donde se procesa.

Una regla clave del diseño limpio: la aplicación nunca debe contener reglas de negocio. Esa lógica vive en el servidor, no en el cliente. El cliente solo orquesta la experiencia.

¿Por qué las reglas de negocio no deben estar en la app? Porque si cambian, tendrías que actualizar la app en cada dispositivo. Manteniéndolas en el backend, el cambio es inmediato y centralizado.

¿Cómo se comunica la app con el backend usando un API service?

Entre la app y el servidor existe una capa intermedia llamada API service, que significa Application Programming Interface [1:05]. Es la funcionalidad pública con la que la aplicación puede interactuar.

Esta comunicación normalmente se hace con REST, Representation State Layer, un canal estructurado para consumir datos y reglas de negocio expuestas por el backend [1:32]. No todo el backend es accesible: el API decide qué se expone.

¿Qué es el patrón repositorio en arquitectura Android?

El repositorio es un patrón de diseño que aísla la capa de comunicación de la aplicación [2:05]. Mientras la capa visual maneja lo que el usuario ve, el repositorio se encarga de hablar con las APIs y administrar los datos.

Dentro de sus responsabilidades están:

• Consumir las APIs necesarias desde un único punto.
• Definir la estrategia de almacenamiento y caché.
• Decidir qué se guarda en base de datos y cómo se procesa.

La ventaja es que cualquier capa superior pide datos sin saber si vienen de la red, del caché o de la base de datos local.

¿Cómo se persisten los datos en aplicaciones móviles?

En el ecosistema Android existen cuatro formas de persistencia [2:55], y cada una tiene su lugar:

1. Bases de datos con SQLite, un motor SQL ligero ideal para datos estructurados.
2. Shared Preferences, pensadas para preferencias del usuario, como activar el modo dark una sola vez.
3. Memoria interna, donde tienes la certeza de que el archivo existe.
4. Memoria externa, que puede ser extraíble, por lo que el archivo podría no estar disponible.

La memoria interna y externa se reservan para archivos grandes y no sensibles, como contenido multimedia.

¿Cuándo usar Shared Preferences en lugar de SQLite? Cuando guardas valores simples como un toggle de tema o un idioma. Para colecciones de datos relacionales, SQLite es la opción correcta.

¿Qué es la inyección de dependencias y para qué sirve en Android?

El grafo de inyección de dependencias provee automáticamente las entidades que necesita cada componente [4:20]. En vez de instanciar un repositorio a mano cada vez, el grafo lo crea e inyecta donde haga falta, todo gestionado en tiempo de compilación.

En Android dominan dos opciones:

• Hilt, un wrapper sobre Dagger 2 que simplifica el grafo con anotaciones.
• Koin, motor de inyección más alineado con Kotlin como lenguaje.

Mantener esta capa aislada permite intercambiar entre Hilt y Koin sin que la aplicación deje de funcionar igual.

¿Cómo mejora la modularización el rendimiento de compilación?

Los App Modules separan las responsabilidades de cada capa de la aplicación [5:48]. Si modificas solo la parte visual de un feature B, únicamente se recompila ese módulo, mientras los demás se sirven desde caché.

Esto se traduce en builds más rápidos y un flujo de trabajo más ágil. Y abre la puerta a algo aún más interesante: los On-demand modules, módulos opcionales que el usuario descarga solo cuando los necesita, en lugar de cargar la app completa desde el inicio [6:30].

¿Qué son los flows y cómo conectan la interacción del usuario?

Los flows son los flujos del usuario, la representación de cómo alguien interactúa con la aplicación [7:00]. Aquí confluyen tres capas: la visual, la de manejo visual (view model o presenter) y el repositorio.

Es la zona donde aparecen las arquitecturas visuales más conocidas:

• MVVM, Model View ViewModel.
• MVP, Model View Presenter.
• MVI, Model View Intent.

Todas viven de cara al usuario y son las que determinan cómo respondes a sus acciones, cómo actualizas la pantalla y cómo solicitas datos al repositorio.

Si algún concepto te dejó dudas, déjalo en los comentarios y conversemos sobre cómo aterrizarlo en tu próximo proyecto.