¿Cómo funciona la daga en Android?

Cuando creamos un nuevo proyecto de Android, eventualmente comenzamos a acumular dependencias diferentes para obtener ciertas funcionalidades, pero con el tiempo administrarlas se vuelve engorroso, por lo que entra en juego un marco de inyección como Dagger. Sin embargo, configurar un servicio de inyección como Dagger requiere una gran cantidad de código repetitivo y tiene una curva de aprendizaje muy pronunciada. Agregar originalmente una versión/dependencia sin formato de Dagger sin compatibilidad con Android es una pesadilla.

PERO….. 

Luego viene Dagger-Android, que cambia este juego y satisface todo lo que le faltaba a Dagger en bruto, como un código prefabricado reducido (repetitivo), pero aún así no tuvo éxito. Recientemente, Dagger-Hilt se lanzó en la parte de las famosas bibliotecas Jetpack, y ahora Google también recomienda una determinada forma de lograr la implementación. Los siguientes son ups de usar Dagger-Hilt como lo mencionan:

1. Proporciona un conjunto diferente de enlaces para diferentes tipos y versiones de compilación.
2. Haga que el código dagger sin procesar sea fácil y legible para los desarrolladores.
3. Se encarga de dónde inyectar las dependencias.
4. Todas las generaciones restantes de código que ocurren son manejadas por la propia daga mediante el uso de anotaciones y, por lo tanto, eliminando todo el código repetitivo.

Pero aún así, la pregunta sigue siendo…

¿Cómo funciona la daga?

Para eso, repasemos esta historia rápida:

Permítanme presentarles: Spandan , un desarrollador de Android , y su robot Zen recientemente desarrollado

Spandan puede ser un tipo misterioso, pero tal vez demasiado solitario…

Ahora Zen tiene dos características principales:

• responda “Like a Daisy” cuando se le pregunte “¿Cómo estás?
• Camina por el apartamento de Spandan evitando los obstáculos.

Para desarrollar Zen, Spandan no usó inyección de dependencia.

Resultado : Zen es rápidamente funcional y ejecuta sus funcionalidades muy fácilmente (caminar y hablar).

Un día, Spandan quiere variar el comportamiento de Zen porque bueno… tener un robot que camina por la casa es bueno, pero ahora no hace mucho, ¿verdad?

Por ello, nuestro desarrollador debe olvidar su lema “cuanto menos me moleste, mejor” . De hecho, ya sea para variar el comportamiento de Zen o probar su código, debe tocar su código. Si su código es lo suficientemente modular, esto podría ayudarlo considerablemente. Pero para cambiar el comportamiento de Zen solo durante las pruebas, el problema no está resuelto.

Afortunadamente, ¡Spandan finalmente descubrió la inyección de dependencia! ¡Una revelación para él! Sí, lleva más tiempo alinearse, pero una vez hecho, ¡no más dolor de cabeza! De hecho, Spandan dividió su robot en varias partes (o módulos) distintas e independientes: la parte superior, el brazo derecho, el brazo izquierdo, etc. Todos estos se agregarán al cuerpo de Zen, que, por otro lado, necesita estas partes para función.

Nuevas dependencias de Zen (todas en diferentes partes)

Estas diferentes partes de las que depende Zen se denominan dependencias. Estos se crean independientemente de su cuerpo, van a ser “inyectados” en su código. es decir, simplemente están «conectados» al cuerpo de Zen, que puede usarlos para dirigir y hablar. Esto significa que, si, por ejemplo, Spandan quiere que Zen aproveche su paseo para lavarse, solo tiene que modificar la dependencia correspondiente (aquí, uno de los brazos). además, cuando Spandan quiera realizar diferentes pruebas de funcionamiento en Buggy, definirá dependencias especialmente para este caso, y alterará el comportamiento del robot para que permanezca inmóvil durante la prueba de funcionamiento de “caminar”.

Entendiendo la daga

Antes de comenzar con Dagger-Hilt, nos gustaría conocer los conceptos básicos de Dagger. Durante esta sección, comprenderá la Daga y sus terminologías. Básicamente, para conocer Dagger tenemos que conocer las 4 anotaciones principales,

1. Módulo
2. Componente
3. proporciona
4. Inyectar

Para entenderlo mejor durante un curso básico, piense en el módulo como un proveedor de dependencia y considere una actividad o la otra clase como un consumidor. Ahora, para suministrar la dependencia del proveedor al consumidor, tenemos un puente entre ellos, en Dagger, el componente funciona como ese puente específico.

Ahora, un módulo puede ser una clase, y lo anotamos con @Module para que Dagger lo conozca como Módulo. Un componente es una interfaz, que se anota con @Component y toma módulos en él. (Pero ahora, esta anotación no es necesaria en Dagger-Hilt). Inyectar es una anotación que suele definir una dependencia dentro del comprador.

Entendiendo Dagger a través de FlowChart

#1. Configuración de un proyecto nuevo

Crear un proyecto

1. Seleccione Actividad vacía y luego Siguiente
2. Nombre : GeeksforGeeksDaggerTutorial
3. Nombre del paquete : com.geeksforgeeks.dagger
4. Idioma : Kotlin
5. Finalizar

Su proyecto inicial está preparado ahora

#2. Agregar dependencias

Agregue las dependencias subsiguientes dentro del archivo build.gradle de la aplicación :

implementación “androidx.recyclerview:recyclerview:{última-versión}”

implementación ‘android.arch.lifecycle:extensions:{última versión}’

implementación ‘com.github.bumptech.glide:glide:{última-versión}’

implementación ‘androidx.actividad:actividad-ktx:{última-versión}’

¡Su archivo Gradle inicial ya está listo!

#3. Necesitamos la enumeración para representar el estado de la interfaz de usuario. Lo crearemos en el paquete utils.

package com.geeksforgeeks.dagger.utils
  
enum class Status {
    SUCCESS,
    ERROR,
    LOADING
}

Ahora necesitamos una clase de utilidad que manejará la comunicación del estado actual de la llamada de red a la capa de interfaz de usuario (UI). Estamos (para este proyecto) nombrándolo como Resource .

#4. Cree una clase de Kotlin ‘Resource.kt’ dentro del mismo paquete de utilidades y agregue el siguiente código:

package com.geeksforgeeks.dagger.utils
  
data class Resource<out T>(val status: Status, val data: T?, val message: String?) {
  
    companion object {
  
        fun <T> success(data: T?): Resource<T> {
            return Resource(Status.SUCCESS, data, null)
        }
  
        fun <T> error(msg: String, data: T?): Resource<T> {
            return Resource(Status.ERROR, data, msg)
        }
  
        fun <T> loading(data: T?): Resource<T> {
            return Resource(Status.LOADING, data, null)
        }
    }
}

¡Ahora estamos listos para rodar con este paquete! Espero que hayas captado el verdadero aroma a través de este artículo y hayas entendido bien cómo funciona la daga 🙂