Inyección de dependencias con Hilt y Kotlin en Android
Separa repositorios de pantallas y prepara dependencias fáciles de sustituir en pruebas.
Crear una arquitectura con clases inyectadas en lugar de instanciarlas directamente en Activities.
Por qué es importante
La inyección de dependencias facilita probar y evolucionar una aplicación, pero una configuración mal diseñada puede esconder el flujo de creación de objetos. Hilt usa anotaciones y generación de código. Comienza con un repositorio pequeño antes de introducir módulos complejos.
Requisitos
- App Android en Kotlin con Gradle y versiones compatibles de Hilt y procesador de anotaciones.
- Conocer ViewModel, repositorio y función de Application.
Trabaja en un proyecto de pruebas. Revisa las versiones y condiciones específicas de la documentación oficial, ya que las APIs y las políticas evolucionan.
Implementación
Configura plugin y dependencias Hilt siguiendo la versión…
Configura plugin y dependencias Hilt siguiendo la versión oficial compatible con Gradle/Kotlin. Decide entre KSP y otros procesadores admitidos.
Crea una clase Application con @HiltAndroidApp y declárala…
Crea una clase Application con @HiltAndroidApp y declárala en AndroidManifest.xml.
Anota la Activity que consume dependencias con @AndroidEntryPoint…
Anota la Activity que consume dependencias con @AndroidEntryPoint y verifica que se use el alcance adecuado.
Crea un repositorio con @Inject constructor. Prefiere inyección…
Crea un repositorio con @Inject constructor. Prefiere inyección de constructor a módulos si controlas la creación de la clase.
Introduce un módulo @Module/@Provides solo cuando necesitas crear…
Introduce un módulo @Module/@Provides solo cuando necesitas crear objetos externos, como Retrofit o una base de datos.
Agrega una implementación falsa en pruebas para validar…
Agrega una implementación falsa en pruebas para validar la lógica sin llamar a la red; revisa los mensajes de compilación si falta un binding.
Fragmento de referencia
@HiltAndroidApp
class MiAplicacion : Application()
class Repositorio @Inject constructor() {
fun mensaje(): String = "Repositorio disponible"
}
@AndroidEntryPoint
class MainActivity : ComponentActivity() {
@Inject lateinit var repositorio: Repositorio
}
// Requiere importaciones, plugin, dependencias y manifest Hilt.Ejemplo educativo: cuando se indique, añade las importaciones, dependencias, claves de prueba o clases de tu proyecto. No se presenta como proyecto Android completo y compilado.
Ponlo a prueba
Añade una dependencia a una Activity de prueba, verifica su creación y anota qué ocurriría si el repositorio necesitara argumentos diferentes.
Lista de comprobación
- La implementación cumple el objetivo: crear una arquitectura con clases inyectadas en lugar de instanciarlas directamente en activities.
- El comportamiento se verificó con datos de prueba y se documentaron los casos de fallo.
- Los recursos, dependencias y políticas se comprobaron contra las referencias oficiales.
- No se registran datos sensibles ni se da por probada una mejora sin evidencia.
Errores habituales
- Olvidar declarar Application en el manifest.
- Inyectar dependencias en clases sin entry points cuando se necesitan.
- Utilizar SingletonComponent sin necesidad y retener objetos de interfaz.
¿Debo crear @Module para toda clase?
No. Las clases propias con constructor inyectable normalmente pueden resolverse sin un módulo.
Referencias para ampliar
Consulta las versiones, limitaciones y requisitos vigentes antes de integrar los ejemplos en producción.