html fromhtml android example

Daga 2 Alcance personalizado para cada Fragmento(o Actividad, etc....)

Question

He visto un par de artículos diferentes que parecen sugerir dos formas diferentes de hacer un alcance personalizado en Dagger 2:

1. Los presentadores de MVP que sobreviven a los cambios de configuración Parte 2 ( Repo de Github ):

   • Utiliza ámbitos personalizados únicos para cada fragmento, por ejemplo, @Hello1Scope y @Hello2Scope para Hello1Fragment y Hello2Fragment respectivamente

2. Tasting Dagger 2 en Android :

   • Utiliza un único ámbito personalizado para todos los fragmentos, por ejemplo, @PerFragment .

Por lo que entiendo, parece que, como en el método 2, debería estar bien tener definido un alcance único que pueda usarse para todos los fragmentos (es decir, @PerFragment ). De hecho (corríjanme si me equivoco), parece que el nombre del alcance personalizado es irrelevante, y es solo cuando se crea el subcomponente (es decir, en Aplicación, Actividad o Fragmento) lo que importa.

¿Hay algún caso de uso para definir un ámbito único para cada fragmento, como en el caso 1?

Answer 1

Después de leer la respuesta por @vaughandroid, y ¿Qué determina el ciclo de vida de un componente (gráfico de objetos) en Dagger 2? Creo que entiendo los ámbitos personalizados lo suficientemente bien como para responder mi propia pregunta.

Primero, aquí hay un par de reglas cuando se trata de componentes, módulos y anotaciones de alcance en dagger2.

• Un Componente debe tener una anotación (única) de ámbito (p @Singleton Ej. @Singleton o @CustomScope ).
• Un módulo no tiene una anotación de alcance.
• Un Método de Módulo puede tener un alcance (único) que coincida con su Componente o sin alcance, donde:
  • Alcance : significa que se crea una instancia única para cada instancia del componente.
  • Unscoped : significa que se crea una nueva instancia con cada inject () o llamada de proveedor
  • NOTA: Dagger2 reserva @Singleton para el componente raíz (y sus módulos). Los subcomponentes deben usar un alcance personalizado, pero la funcionalidad de ese alcance es exactamente la misma que @Singleton .

Ahora, para responder a la pregunta: Yo diría crear un nuevo alcance con nombre para cada ámbito conceptualmente diferente. Por ejemplo, cree una @PerActivity , @PerFragment o @PerView que indique dónde se debe crear una instancia del componente e indique su duración.

Nota : este es un compromiso entre dos extremos. Considere el caso de un componente raíz y n subcomponentes que necesitará:

• al menos 2 anotaciones ( @Singleton y @SubSingleton ), y
• a lo sumo n + 1 anotaciones ( @Singleton , @SubSingleton1 , ... @SubSingletonN ).

Ejemplo:

Solicitud:

/** AppComponent.java **/ 
@Singleton
@Component( modules = AppModule.class )
public interface AppComponent{
    void inject(MainActivity mainActivity);
}

/** AppModule.java **/
@Module
public class AppModule{
    private App app;

    public AppModule(App app){
        this.app = app;
    }

    // For singleton objects, annotate with same scope as component, i.e. @Singleton
    @Provides @Singleton public App provideApp() { return app; }
    @Provides @Singleton public EventBus provideBus() { return EventBus.getDefault(); }
}

Fragmento:

/** Fragment1Component.java **/
@PerFragment
@Component( modules = {Fragment1Module.class}, dependencies = {AppComponent.class} )
public interface Fragment1Component {
    void inject(Fragment1 fragment1);
}

/** Fragment1Module.java **/ 
@Module
public class Fragment1Module {
    // For singleton objects, annotate with same scope as component, i.e. @PerFragment
    @Provides @PerFragment public Fragment1Presenter providePresenter(){
        return new Fragment1Presenter();
    }
}

/** PerFragment.java **/ 
@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface PerFragment {}

Answer 2

Su comprensión es correcta. Los ámbitos nombrados le permiten comunicar la intención, pero todos funcionan de la misma manera.

• Para los métodos de proveedor de ámbito, cada instancia de componente creará 1 instancia del objeto proporcionado.
• Para los métodos de proveedor sin ámbito, cada instancia de Componente creará una nueva instancia del objeto provisto siempre que necesite inyectarlo.

El tiempo de vida de la instancia del Componente es importante sin embargo. 2 instancias diferentes del mismo componente proporcionarán diferentes instancias de objeto, incluso con ámbito.

Los nombres del ámbito deben indicar la duración del objeto proporcionado (que coincide con el de la instancia del Componente), por lo que @PerFragment tiene mucho más sentido para mí.

A partir de un vistazo rápido al tutorial "MVP Presenters ...", no me queda claro cuál es la intención del autor de tener ámbitos separados. Dado que los nombres son simplemente desechables, no leería demasiado.