Stack Tecnológico Android

Objetivo

Definir las herramientas, librerías y configuraciones base recomendadas para desarrollar la aplicación Android bajo la arquitectura propuesta.

El stack debe ayudar a mantener el proyecto ordenado, seguro, escalable y fácil de mantener, respetando la separación por capas:

presentation → domain → data

También debe reforzar el uso de core para elementos reutilizables y di para la inyección de dependencias.

Entorno de desarrollo

Herramienta	Uso recomendado
Android Studio	IDE principal para desarrollo Android
Kotlin	Lenguaje principal del proyecto
XML Layouts	Construcción de interfaces visuales
Gradle Kotlin DSL	Configuración del proyecto mediante `build.gradle.kts`
Git	Control de versiones

Arquitectura base

Tecnología / Patrón	Uso dentro del proyecto
Clean Architecture	Separación de responsabilidades por capas
MVVM	Manejo de UI mediante `ViewModel` y estados
Single Activity	`MainActivity` como contenedor principal de navegación
Repository Pattern	Abstracción del acceso a datos
UseCases	Encapsular reglas de negocio específicas
Mappers	Convertir DTOs / Entities a modelos de dominio
Extension Functions	Reutilizar lógica simple sin duplicar código
Chain of Responsibility	Manejo de validaciones o flujos con múltiples pasos
Strategy Pattern	Cambiar comportamientos según reglas del negocio
Singleton	Solo para estados o managers globales justificados

Inyección de dependencias

Dagger Hilt

Se recomienda utilizar Hilt como herramienta principal para inyección de dependencias.

Uso recomendado:

Inyectar repositorios
Inyectar UseCases
Inyectar servicios de red
Inyectar DataSources
Inyectar managers globales controlados
Evitar instancias manuales dentro de Fragments, ViewModels o Repositories

Ubicación sugerida:

di/
├── NetworkModule.kt
├── RepositoryModule.kt
├── UseCaseModule.kt
└── StorageModule.kt

Reglas

Toda dependencia compartida debe declararse en la capa di y no instanciarse directamente desde presentation.
Para nuevos proyectos, siempre validar y utilizar la versión estable más reciente recomendada oficialmente.

Red y consumo de APIs

Librería	Uso recomendado
Retrofit	Consumo de servicios REST
OkHttp	Cliente HTTP base
OkHttp Interceptors	Headers, tokens, logs y manejo técnico de red
Gson / Moshi / Kotlinx Serialization	Serialización y deserialización de JSON

Ubicación sugerida:

data/remote/
├── api/
├── dto/
├── datasource/
└── interceptor/

Reglas:

Los DTOs no deben llegar a presentation.
Los errores técnicos deben manejarse en data o core.
Los modelos expuestos hacia domain deben ser modelos de dominio.

Persistencia local y almacenamiento

Librería / Herramienta	Uso recomendado
Room	Base de datos local estructurada
DataStore	Preferencias simples y reactivas
EncryptedSharedPreferences / Security Crypto	Guardar datos sensibles de forma segura
Cache local	Persistencia temporal cuando aplique

Ubicación sugerida:

data/local/
├── db/
├── datastore/
└── cache/

Reglas:

No guardar tokens o datos sensibles en SharedPreferences normales.
Usar EncryptedSharedPreferences cuando se requiera almacenar información sensible.
Evitar acceder al almacenamiento local directamente desde presentation.

Manejo de estado y asincronía

Tecnología	Uso recomendado
ViewModel	Mantener estado de pantalla y lógica de presentación
StateFlow	Exponer estado observable e inmutable hacia la UI
SharedFlow	Eventos únicos como navegación, mensajes o alertas
Coroutines	Operaciones asíncronas
LiveData	Permitido si el proyecto ya lo usa, pero no mezclar sin necesidad

Reglas:

El ViewModel no debe conocer vistas Android como Activity, Fragment o View.
La UI observa estado y delega acciones.
Los eventos únicos deben manejarse como eventos, no como estado permanente.

Navegación

Librería	Uso recomendado
Navigation Component	Navegación centralizada mediante `NavHostFragment` y `navigation.xml`
Safe Args	Paso de argumentos tipados entre pantallas cuando aplique

Ubicación sugerida:

presentation/navigation/
res/navigation/main_nav_graph.xml

Reglas:

No hardcodear rutas o acciones por todo el proyecto.
La navegación debe dispararse desde la UI.
Si el ViewModel necesita solicitar navegación, debe hacerlo mediante UiEvent.

Seguridad

Herramienta / Práctica	Uso recomendado
EncryptedSharedPreferences	Guardado seguro de tokens o datos sensibles
AndroidX Security Crypto	Cifrado de información local sensible
ProGuard / R8	Ofuscación y reducción de código en release
Network Security Config	Reglas de tráfico HTTP/HTTPS
BuildConfig	Separar configuraciones por ambiente

Reglas:

No subir llaves, tokens o credenciales al repositorio.
No guardar información sensible en texto plano.
No imprimir datos sensibles en logs.
Separar ambientes como debug, qa y release cuando aplique.

Calidad de código

Herramienta	Uso recomendado
ktlint	Validar formato y estilo de código Kotlin
Detekt	Detectar code smells y malas prácticas
Lint Android	Revisar problemas específicos de Android
Git Hooks	Ejecutar validaciones antes de subir código

Reglas:

El código debe pasar ktlint antes de abrir PR.
Evitar clases gigantes.
Evitar funciones con múltiples responsabilidades.
Mantener nombres claros y consistentes.
No dejar código comentado sin justificación.

Testing

Librería	Uso recomendado
JUnit	Pruebas unitarias
MockK / Mockito	Mocks para dependencias
Turbine	Pruebas de Flows
Coroutines Test	Pruebas de código asíncrono
Espresso	Pruebas de UI XML cuando aplique
Hilt Testing	Pruebas con inyección de dependencias

Prioridad de pruebas:

UseCases
Validaciones
ViewModels
Repositories con lógica relevante
Flujos críticos de UI

Carga de imágenes

Librería	Uso recomendado
Glide	Carga de imágenes desde URL o recursos locales
Coil	Alternativa moderna para carga de imágenes

Reglas:

Elegir una sola librería principal para evitar duplicidad.
Centralizar configuración de carga de imágenes si el proyecto la usa en muchas pantallas.
Evitar lógica de carga compleja dentro del Fragment.

Logs y monitoreo

Herramienta	Uso recomendado
Timber	Logs controlados por ambiente
Firebase Crashlytics	Reporte de crashes en producción
Firebase Analytics	Eventos de uso cuando el negocio lo requiera

Reglas:

No usar Log.d directamente en todas las capas.
Centralizar logs en core/logger.
No registrar información sensible.

Ubicación sugerida:

core/logger/
└── AppLogger.kt

Propuesta de dependencias base

// Dependency Injection
implementation("com.google.dagger:hilt-android:<version>")
kapt("com.google.dagger:hilt-compiler:<version>")

// Networking
implementation("com.squareup.retrofit2:retrofit:<version>")
implementation("com.squareup.okhttp3:okhttp:<version>")
implementation("com.squareup.okhttp3:logging-interceptor:<version>")

// Local Storage
implementation("androidx.room:room-runtime:<version>")
kapt("androidx.room:room-compiler:<version>")
implementation("androidx.datastore:datastore-preferences:<version>")
implementation("androidx.security:security-crypto:<version>")

// Coroutines / Lifecycle
implementation("androidx.lifecycle:lifecycle-viewmodel-ktx:<version>")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:<version>")
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:<version>")

// Navigation
implementation("androidx.navigation:navigation-fragment-ktx:<version>")
implementation("androidx.navigation:navigation-ui-ktx:<version>")

// Quality
ktlint("com.pinterest.ktlint:ktlint-cli:<version>")

// Testing
testImplementation("junit:junit:<version>")
testImplementation("io.mockk:mockk:<version>")
testImplementation("app.cash.turbine:turbine:<version>")
testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:<version>")

Las versiones deben definirse y actualizarse desde el catálogo de versiones o desde la estrategia Gradle definida por el equipo.

Relación del stack con la arquitectura

Capa	Tecnologías principales
presentation	XML, Fragment, ViewModel, StateFlow, SharedFlow, Navigation Component
domain	UseCases, modelos de dominio, contratos de repositorio
data	Retrofit, OkHttp, Room, DataStore, DTOs, Mappers, Repositories
core	Extensions, Validators, Logger, Security, Error Handler, Utils
di	Hilt Modules

Stack Tecnológico Base

Tecnología	Versión Base	Propósito	Dependencia Gradle	Recurso
Kotlin	2.2.10	Lenguaje principal del proyecto		Releases
Android Gradle Plugin	8.13.0	Build system Android		Releases
Gradle	9.1.0	Build automation		Releases
Dagger Hilt	2.59.2	Inyección de dependencias	`com.google.dagger:hilt-android`	Releases
Retrofit	3.0.0	Cliente REST API	`com.squareup.retrofit2:retrofit`	Releases
OkHttp	4.12.0	Cliente HTTP base	`com.squareup.okhttp3:okhttp`	Releases
OkHttp Logging Interceptor	4.12.0	Logging de requests/responses	`com.squareup.okhttp3:logging-interceptor`	Releases
Gson	2.14.0	Serialización JSON	`com.google.code.gson:gson`	Releases
Room	2.8.4	Persistencia local SQLite	`androidx.room:room-runtime`	Android Docs
Room Compiler	2.8.4	Generación de código Room	`androidx.room:room-compiler`	Android Docs
DataStore Preferences	1.2.1	Preferencias modernas	`androidx.datastore:datastore-preferences`	Android Docs
Security Crypto	1.1.0	Encriptación segura local	`androidx.security:security-crypto`	Android Docs
Lifecycle ViewModel	2.10.0	Manejo de ViewModels	`androidx.lifecycle:lifecycle-viewmodel-ktx`	Android Docs
Lifecycle Runtime	2.10.0	Lifecycle awareness	`androidx.lifecycle:lifecycle-runtime-ktx`	Android Docs
Coroutines Android	1.11.0	Programación asíncrona	`org.jetbrains.kotlinx:kotlinx-coroutines-android`	Releases
Navigation Component	2.9.4	Navegación XML + Fragments	`androidx.navigation:navigation-fragment-ktx`	Android Docs
Navigation UI	2.9.8	Integración con Toolbar/NavHost	`androidx.navigation:navigation-ui-ktx`	Android Docs
Ktlint	1.7.1	Formato y reglas Kotlin	`com.pinterest.ktlint:ktlint-cli`	Releases
JUnit	4.13.2	Testing unitario	`junit:junit`	GitHub
MockK	1.14.5	Mocking para Kotlin	`io.mockk:mockk`	Releases
Turbine	1.2.1	Testing de Flows	`app.cash.turbine:turbine`	Releases
Coroutines Test	1.10.2	Testing de corrutinas	`org.jetbrains.kotlinx:kotlinx-coroutines-test`	Releases

Regla clave

El stack tecnológico debe apoyar la arquitectura, no reemplazarla.

Antes de agregar una librería nueva, se debe validar si realmente resuelve una necesidad del proyecto y en qué capa debe vivir.

Conclusión

Este stack tecnológico permite construir una aplicación Android más segura, ordenada y mantenible. Además, refuerza la arquitectura limpia propuesta, facilita el trabajo por features y ayuda a mantener estándares claros para todo el equipo.