Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


¿La manera más simple de crear un Singleton w / Dagger 2?

¿Necesito configurar Módulos, Proveedores e Interfaces (Componentes)? Parece un poco de gastos generales sólo para poder inyectar un singleton.

¿Puede alguien proporcionar un ejemplo de singleton simple usando Dagger 2? (También mostrar cómo se puede establecer las propiedades de la singleton como el contexto por lo que no es necesario pasarlo en cada vez que utilice el singleton)

  • Dagger 2 inyectar parámetros del constructor
  • Dagger 2, a veces en la compilación me sale "no se puede encontrar la clase de símbolo DaggerApplicationComponent"
  • Creación de una aplicación Android Instant con componente de aplicación de Dagger
  • Daga 2 - dos proporciona el método que proporcionan la misma interfaz
  • Dagger- ¿Debemos crear cada componente y módulo para cada Actividad / Fragmento
  • Dagger 2 ciclo de vida de un componente, módulo y alcance
  • Dagger 2 error: dependency "no se puede proporcionar sin un constructor @Inject" mientras que realmente anotado con @Inject
  • Dagger2 - nulo en lugar del objeto inyectado
  • Creación de una aplicación Android Instant con componente de aplicación de Dagger
  • ¿Cómo organizas tus módulos y componentes Dagger 2?
  • Inyección de dependencia de Java: Dagger 1 vs Dagger 2, que es mejor?
  • Dagger2: Error cuando dos componentes tienen la misma firma de método de inyección
  • 2 Solutions collect form web for “¿La manera más simple de crear un Singleton w / Dagger 2?”

    Sólo necesitas módulos para cosas que no puedes anotar con el constructor @Inject (porque, por ejemplo, el framework lo crea para ti, como el contexto). Si no puede agregar un constructor @Inject, también debe especificar un método void inject(...) en el componente.

    Sin embargo, si puede crearlo con un constructor @Inject , entonces @Inject funciona como una anotación de campo

     @Component(modules={ContextModule.class}) @Singleton public interface SingletonComponent { void inject(MainActivity mainActivity); } @Module public class ContextModule { Context context; public ContextModule(Context context) { this.context = context; } @Provides Context context() { return context; } } @Singleton public class MyOtherSingleton { @Inject public MyOtherSingleton() { } } @Singleton public class MySingleton { @Inject Context context; @Inject MyOtherSingleton myOtherSingleton; @Inject public MySingleton() { } } 

    También puede hacer parámetros de constructor

     Context context; MyOtherSingleton myOtherSingleton; @Inject public MySingleton(Context context, MyOtherSingleton myOtherSingleton) { this.context = context; this.myOtherSingleton = myOtherSingleton; } 

     @Inject MySingleton mySingleton; //... SingletonComponent singletonComponent = DaggerSingletonComponent.builder() .contextModule(new ContextModule(this.getApplicationContext())) .build(); singletonComponent.inject(this); 

    Verificado para trabajar:

     08-23 04:39:28.418 com.zhuinden.rxrealm D/DogView: My singleton has [com.zhuinden.rxrealm.application.CustomApplication@53348a58] and [com.zhuinden.rxrealm.application.injection.test.MyOtherSingleton@5336bb74] 08-23 04:39:36.422 com.zhuinden.rxrealm D/CatView: My singleton has [com.zhuinden.rxrealm.application.CustomApplication@53348a58] and [com.zhuinden.rxrealm.application.injection.test.MyOtherSingleton@5336bb74] 

    Este es un texto simplificado (no completamente preciso – ver enlaces abajo) gradualmente explicando Dagger2 y la idea detrás de él. Mis esperanzas son que usted podrá leer y entender otros detalles en Dagger2 después de este texto.

    No se concentre en el término singleton. Dagger2 (olvidar daga y usar dagger2) existe para reforzar el alcance del objeto. No es el ámbito de lo que solemos hablar (clases, métodos, bucles) sino el ámbito en un nivel de arquitectura (se definen esas capas).

    Algunas capas típicas de Android son Aplicación, Actividad y Fragmento. Como ya sabes, tu aplicación para Android recibe sólo una instancia de la clase Aplicación. Muchas instancias de la clase Activity y muchas instancias de la clase Fragment.

    Desea mantener su aplicación agradable y limpia y desea mantener sus objetos en el lugar adecuado (hacer cumplir la semántica). Estos objetos necesitan ser creados en algún lugar (por lo general, tiene que escribir clases de fábrica / métodos / proyectos – la primera fue una broma) , que la utilidad de creación debe ser llamado en alguna parte y es necesario pasar esos objetos de algún lugar a donde pertenecen!

    Eso es un montón de somewheres a tipo (por lo general las clases con nombres extraños) y pasando por los objetos desde donde fueron creados a donde pertenecen puede ser todo un reto. Especialmente cuando muchas clases diferentes usan ese objeto especial tuyo.

    ¡Dagger2 al rescate! Básicamente hay dos términos que usted necesita entender. Componentes y Módulos.

    Los componentes están aquí para inyectarse. Inyectan sus clases con objetos que necesitan para ser construidos. Los componentes sólo se inyectan, no crean los objetos. Entonces, ¿quién crea objetos?

    Los módulos crean objetos que los componentes inyectan en clases que necesitan ser construidas. Los módulos están llenos de métodos InsertName . Estos métodos crean objetos que necesita pasar a las clases que los necesitan. Un método de proporcionar siempre creará un nuevo objeto o reutilizará (singleton) el objeto ya creado si ese método se anota con @Scope (necesitará escribir una nueva anotación de ámbito, pero ese es el detalle) . Los nombres de proporcionar métodos realmente no importan. Lo que importa es el tipo de retorno de estos métodos (sólo recuerde que la información será útil más adelante) .

    Cuando escriba su Componente, deberá indicar qué Módulos están asociados con ese Componente y durante la instanciación de Componentes tendrá que pasar instancias de Módulo asociadas a ese constructor de Componentes. Juntos, los componentes y los módulos forman una máquina de inyección.

    Instanciar su componente (Dagger2 genera clases de constructor para sus componentes) en la capa que cree que Component debe inyectar. Por ejemplo, crea una instancia ApplicationComponent dentro de la clase Application. Los objetos inyectados por ApplicationComponent se crean sólo una vez y existen mientras existe una instancia de ApplicationComponent (durante la inyección se obtendrán, no se recrearán) . La instancia ApplicationComponent existe mientras existe la instancia Application (por lo que en el entorno Android es básicamente siempre / durante la vida útil de la aplicación) .

    Puede repetir la misma historia con clases de actividad. Instanciar ActivityComponent dentro de su clase de actividad, ese componente existe mientras existe esa actividad. Observe cómo los objetos inyectados por ActivityComponent sólo existen cuando existe ActivityComponent (instancia de clase de actividad). Esa es la belleza de Dagger2. Los objetos que pertenecen a las capas de Actividad se definen literalmente en la capa Actividad.

    Nota: Los componentes pueden depender el uno del otro. Su ActivityComponent puede depender de su ApplicationComponent para que la capa Activity pueda usar objetos de la capa Application (pero no de otra manera, es un mal diseño) . De esta manera, los componentes forman un árbol de dependencias que hace que la búsqueda de objetos y la inyección sean muy eficientes.

    Después de leer esto (mis felicitaciones buen señor) le recomiendo revisar este enlace y revisar la charla de Jake Wharton en Dagger2 .

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.