1. El laberinto del acoplamiento fuerte
Imagina que estás construyendo Detedroid y creas una clase para analizar la temperatura
(`TempAnalyzer`). Esta clase necesita interactuar con el chip de la batería (`BatterySensor`),
que a su vez requiere el (`DeviceManager`). Si lo escribes mal (instancias manuales
val sensor = BatterySensor()), tu clase `TempAnalyzer` será **imposible** de
testear unitariamente (Unit Testing), ya que está forzada a crear un ecosistema entero que puede
crashear sin el contexto de Android físico.
Ese es el terror de lo que conocemos como acoplamiento fuerte. ¿La solución de ingeniería de software para erradicar esto? La Inyección de Dependencias (DI).
2. ¿Por qué Dagger "Vanilla" era odiado?
Dagger 2 fue la reina indiscutible, la librería más sofisticada, veloz (generación de código en
tiempo de compilación) y poderosa del ecosistema. El problema es que configurarlo tomaba 5 días
llenos de llantos. Entender qué es un @Component, un @Subcomponent, o
crear factories y builders manuales ahuyentaba velozmente a las masas de desarrolladores junior,
que preferían abrazar Service Locators débiles en Kotlin como Koin.
3. Hilt al rescate: DI de Google en pañales
Google observó este problema crónico y construyó **Hilt** sobre la robustez indomable de Dagger 2. Hilt no es una nueva herramienta de inyección; es un envoltorio estandarizado, predefinido con buenas prácticas, pensado exclusivamente en la forma en que los Android Devs creamos apps y Actividades en nuestra vida diaria (Activity, Fragments, Application class).
Configurar Hilt involucra la gloria de un puñado de humildes anotaciones mágicas:
@HiltAndroidAppsobre tu clase App global: Esto genera silenciosa e internamente el Dios de los componentes por detrás (el famoso SingletonComponent raíz).@AndroidEntryPointsobre tu Activity/Fragmento. Le grita a la librería: "¡Ey! Genera un scope inyectable aquí para poder dotarme de mis ViewModels!"@HiltViewModeljunto con@Inject constructor(val repo: MyRepo)que ahorra horas de código manual definiendo absurdas Factories de Jetpack ViewModel.
4. El poder de los @Module
El código real que te ahorrarás la vida se llama módulo. ¿Cómo de fácil era instalar un
componente externo (como Retrofit o Firestore) en tu ViewModel? Con Hilt, abres un archivo
solitario, colocas @Module e instalas en el Singleton global con
@InstallIn(SingletonComponent::class) una pequeña función que devuelve la librería
preconfigurada con @Provides y anotada con @Singleton si es única.
De pronto, mágicamente y sin dolor, cada vez que en los 40 ViewModels distintos de tu app Android pidas en el constructor un "RetrofitService", Hilt te enviará la misma exactísima instancia veloz que creaste en tu modulo en la capa de datos.
5. El beneficio definitivo: El Testing
El motivo principal por el que pasarte a Hilt hoy mismo son los Test Unitarios (para JUnit puro o Instrumentados con Espresso/Compose UI Testing). Gracias a inyectar clases abstractas o interfaces requeridas en un constructor, durante la prueba en tu IDE puedes inyectarle deliberadamente interfaces que emulen información falsamente (Mocks) que siempre retornan "éxito", evadiendo los problemas del API de producción o demoras temporales.
Sin Inyección de dependencias, un código profesional simplemente no es auditable industrialmente.