Ambito attività Dagger2, quanti moduli/componenti ho bisogno?

Question

Ho un paio di domande su ambiti personalizzati:

1. sto usando MVP architecutre e ho bisogno di iniettare diversi relatori di diverse attività. A tale scopo ho creato @ActivityScope. Significa che devo creare un modulo/componente separato per ogni attività?
2. Qual è lo scopo delle annotazioni dell'ambito personalizzato se sono ancora responsabile della creazione e del rilascio di tali dipendenze? Non sono sicuro se ho ragione, ma posso usare @ Scope123 in tutti i miei moduli/componenti e non farà alcuna differenza.

Answer 1

Vuol dire che devo creare un modulo/componente separato per ogni activitiy?

Sì. E no

Al meno è necessario creare un nuovo componente oggetto per ogni attività, se si desidera fornire attività di ambito dipendenze, come il Activity stesso, il LoaderManager, o cose simili, perché la portata sarà solo vivere fintanto che l'attività.

La questione di sapere se avete bisogno di un modulo e componenti per ogni singolo uno dei tuoi attività dipende fortemente dalla vostra architettura. Inoltre potresti essere in grado di creare un generico ActivityModule fornendo il modello, il presentatore e la vista che potresti riutilizzare.

Si potrebbe anche andare bene con un solo Component ad es. se sono necessari solo le dipendenze di base delle attività come la LoaderManager o Activity in sé allora si può scrivere un ActivityModule per fornire solo quegli oggetti di base. È quindi possibile utilizzare questo modulo con il proprio componente per fornire le dipendenze. Se il Presenter (e le sue dipendenze) possono essere creati dall'iniezione del costruttore si potrebbe andare bene con un singolo componente e modulo per tutte le vostre attività.

Se il presentatore e la vista sono le interfacce che vengono implementati si avrebbe bisogno di creare un modulo che prevede la realizzazione vera e propria, però.

Qual è lo scopo delle annotazioni di ambito personalizzato se sono ancora responsabile della creazione e del rilascio di tali dipendenze?

Scopes sono usati per fare la gestione di tali dipendenze più facile. Come accennato, l'ambito di attività muore con l'attività che viene distrutta. Avendo quelle dipendenze di ambito si può essere sicuri che nulla dipende dalla vostra attività che ha una portata/durata superiore e potrebbe causare perdite di memoria.

Inoltre, mi piace pensarlo come un insieme di dipendenze che puoi scambiare a caldo e semplicemente "buttare via". Un buon esempio è uno @UserScope che manterrà i dati utente, i suoi dati di sessione, sessione, ...
Se cambio utente, ho solo bisogno di buttare fuori tutto con un scope utente o meno (chiudi attività, rimuovi UserComponent) e tutto per quanto riguarda l'utente è andato. Il prossimo può effettuare il login e il rischio di effetti collaterali è basso.

Scopes sono per lo più di compilazione controlli orari che aiuto si mettono gerarchia nelle vostre dipendenze, dal momento che tutto il compilatore non è controllare che non ci siano cicli in esso e che nulla chiede le dipendenze da un ambito che non può accedere.

Answer 2

1. Il modo più semplice per fare ciò che serve è quello di creare un componente livello di applicazione nel desiderio di fornire ogni tipo di presentatore. Il problema è che avrai tutte le classi di tutti i progetti allo stesso livello, che è un po 'brutto. Il bel modo è quello di creare un modulo per un'attività che inietta le dipendenze per l'attuale attività/frammento

2. Utilizzando @ActivityScope o qualsiasi altro solo mostrare il modulo ha una durata diversa da @Singleton, fintanto che è non un singleton, considera che il tuo modulo morirà come la tua attività che lo ha creato.