Iniezione manuale di dipendenze

L'architettura delle app consigliata per Android incoraggia la divisione suddividere il codice in classi per trarre vantaggio dalla separazione dei problemi, un principio in cui ogni classe della gerarchia ha una singola responsabilità definita. Questo porta a un numero maggiore di classi più piccole che devono essere collegate tra loro per soddisfare le dipendenze reciproche.

Figura 1. Un modello dell'applicazione di un'app per Android grafico

.

Le dipendenze tra le classi possono essere rappresentate come un grafico, in cui è collegata alle classi da cui dipende. La rappresentazione di tutti i tuoi e le loro dipendenze formano il grafico delle applicazioni. Nella Figura 1, puoi vedere un'astrazione del grafico dell'applicazione. Quando la classe A (ViewModel) dipende dalla classe B (Repository), è presente una linea che punta da A a B che rappresenta quella dipendenza.

L'inserimento delle dipendenze consente di effettuare queste connessioni e di eseguire lo scambio implementazioni per i test. Ad esempio, durante il test di un ViewModel che dipende da un repository, puoi passare diverse implementazioni Repository con falsi o simulazioni per testare le diverse richieste.

Nozioni di base sull'inserimento manuale delle dipendenze

Questa sezione illustra come applicare l'inserimento manuale delle dipendenze in un dispositivo Android reale scenario di un'app. Il video illustra un approccio iterato che illustra come iniziare usando l'inserimento delle dipendenze nell'app. L'approccio migliora fino a raggiungere un punto molto simile a quello che genererebbe automaticamente Dagger te. Per saperne di più su Dagger, leggi le nozioni di base di Dagger.

Considera un flusso come un gruppo di schermate della tua app che corrispondono a una funzionalità. Accesso, registrazione e pagamento sono tutti esempi di flussi.

Quando si tratta di un flusso di accesso per una tipica app per Android, LoginActivity dipende da LoginViewModel, che a sua volta dipende da UserRepository. Allora UserRepository dipende da UserLocalDataSource e UserRemoteDataSource, che a sua volta dipende da un Retrofit completamente gestito di Google Cloud.

LoginActivity è il punto di accesso al flusso di accesso e l'utente interagisce con l'attività. Di conseguenza, LoginActivity deve creare LoginViewModel con tutte le sue dipendenze.

Le classi Repository e DataSource del flusso hanno il seguente aspetto:

Kotlin

class UserRepository(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

class UserLocalDataSource { ... }
class UserRemoteDataSource(
    private val loginService: LoginRetrofitService
) { ... }

Java

class UserLocalDataSource {
    public UserLocalDataSource() { }
    ...
}

class UserRemoteDataSource {

    private final Retrofit retrofit;

    public UserRemoteDataSource(Retrofit retrofit) {
        this.retrofit = retrofit;
    }

    ...
}

class UserRepository {

    private final UserLocalDataSource userLocalDataSource;
    private final UserRemoteDataSource userRemoteDataSource;

    public UserRepository(UserLocalDataSource userLocalDataSource, UserRemoteDataSource userRemoteDataSource) {
        this.userLocalDataSource = userLocalDataSource;
        this.userRemoteDataSource = userRemoteDataSource;
    }

    ...
}

Ecco l'aspetto di LoginActivity:

Kotlin

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // In order to satisfy the dependencies of LoginViewModel, you have to also
        // satisfy the dependencies of all of its dependencies recursively.
        // First, create retrofit which is the dependency of UserRemoteDataSource
        val retrofit = Retrofit.Builder()
            .baseUrl("https://example.com")
            .build()
            .create(LoginService::class.java)

        // Then, satisfy the dependencies of UserRepository
        val remoteDataSource = UserRemoteDataSource(retrofit)
        val localDataSource = UserLocalDataSource()

        // Now you can create an instance of UserRepository that LoginViewModel needs
        val userRepository = UserRepository(localDataSource, remoteDataSource)

        // Lastly, create an instance of LoginViewModel with userRepository
        loginViewModel = LoginViewModel(userRepository)
    }
}

Java

public class MainActivity extends Activity {

    private LoginViewModel loginViewModel;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // In order to satisfy the dependencies of LoginViewModel, you have to also
        // satisfy the dependencies of all of its dependencies recursively.
        // First, create retrofit which is the dependency of UserRemoteDataSource
        Retrofit retrofit = new Retrofit.Builder()
                .baseUrl("https://example.com")
                .build()
                .create(LoginService.class);

        // Then, satisfy the dependencies of UserRepository
        UserRemoteDataSource remoteDataSource = new UserRemoteDataSource(retrofit);
        UserLocalDataSource localDataSource = new UserLocalDataSource();

        // Now you can create an instance of UserRepository that LoginViewModel needs
        UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);

        // Lastly, create an instance of LoginViewModel with userRepository
        loginViewModel = new LoginViewModel(userRepository);
    }
}

Si sono verificati problemi con questo approccio:

1. C'è molto codice boilerplate. Se volessi creare un'altra istanza di LoginViewModel in un'altra parte del codice, si otterrebbe una duplicazione del codice.

2. Le dipendenze devono essere dichiarate in ordine. Devi creare un'istanza UserRepository prima del giorno LoginViewModel per crearlo.

3. È difficile riutilizzare gli oggetti. Se vuoi riutilizzare UserRepository in più funzionalità, dovresti fare in modo che segua le pattern singleton. Il pattern singleton rende i test più difficili perché tutti i test condividono la stessa istanza singleton.

Gestione delle dipendenze con un container

Per risolvere il problema del riutilizzo di oggetti, puoi creare modelli dependencies container che utilizzi per ottenere le dipendenze. Tutte le istanze forniti da questo container possono essere pubblici. Nell'esempio, perché hai bisogno solo per un'istanza di UserRepository, puoi rendere private le sue dipendenze l'opzione per renderli pubblici in futuro qualora fosse necessario:

Kotlin

// Container of objects shared across the whole app
class AppContainer {

    // Since you want to expose userRepository out of the container, you need to satisfy
    // its dependencies as you did before
    private val retrofit = Retrofit.Builder()
                            .baseUrl("https://example.com")
                            .build()
                            .create(LoginService::class.java)

    private val remoteDataSource = UserRemoteDataSource(retrofit)
    private val localDataSource = UserLocalDataSource()

    // userRepository is not private; it'll be exposed
    val userRepository = UserRepository(localDataSource, remoteDataSource)
}

Java

// Container of objects shared across the whole app
public class AppContainer {

    // Since you want to expose userRepository out of the container, you need to satisfy
    // its dependencies as you did before
    private Retrofit retrofit = new Retrofit.Builder()
            .baseUrl("https://example.com")
            .build()
            .create(LoginService.class);

    private UserRemoteDataSource remoteDataSource = new UserRemoteDataSource(retrofit);
    private UserLocalDataSource localDataSource = new UserLocalDataSource();

    // userRepository is not private; it'll be exposed
    public UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);
}

Poiché queste dipendenze vengono utilizzate nell'intera applicazione, devono un luogo comune per tutte le attività: Application. Crea un'immagine personalizzata Classe Application che contiene un'istanza AppContainer.

Kotlin

// Custom Application class that needs to be specified
// in the AndroidManifest.xml file
class MyApplication : Application() {

    // Instance of AppContainer that will be used by all the Activities of the app
    val appContainer = AppContainer()
}

Java

// Custom Application class that needs to be specified
// in the AndroidManifest.xml file
public class MyApplication extends Application {

    // Instance of AppContainer that will be used by all the Activities of the app
    public AppContainer appContainer = new AppContainer();
}

Nota: AppContainer è solo una classe normale con un'istanza univoca condivisa nell'app inserita nel corso Application. Tuttavia, AppContainer è non segue lo schema singleton; in Kotlin, non è una object, mentre in Java non è possibile accedervi con la tipica Singleton.getInstance().

Ora puoi ottenere l'istanza di AppContainer dall'applicazione e ottieni la condivisione dell'istanza UserRepository:

Kotlin

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Gets userRepository from the instance of AppContainer in Application
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = LoginViewModel(appContainer.userRepository)
    }
}

Java

public class MainActivity extends Activity {

    private LoginViewModel loginViewModel;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // Gets userRepository from the instance of AppContainer in Application
        AppContainer appContainer = ((MyApplication) getApplication()).appContainer;
        loginViewModel = new LoginViewModel(appContainer.userRepository);
    }
}

In questo modo, non hai un singleton UserRepository. È invece possibile AppContainer condiviso tra tutte le attività che contengono oggetti del grafico e crea istanze degli oggetti utilizzabili da altre classi.

Se è necessario LoginViewModel in più punti dell'applicazione, avere un posizione centralizzata in cui crei istanze di LoginViewModel senso. Puoi spostare la creazione di LoginViewModel nel container e fornire nuovi oggetti di quel tipo con una fabbrica. Il codice di un LoginViewModelFactory ha il seguente aspetto:

Kotlin

// Definition of a Factory interface with a function to create objects of a type
interface Factory<T> {
    fun create(): T
}

// Factory for LoginViewModel.
// Since LoginViewModel depends on UserRepository, in order to create instances of
// LoginViewModel, you need an instance of UserRepository that you pass as a parameter.
class LoginViewModelFactory(private val userRepository: UserRepository) : Factory {
    override fun create(): LoginViewModel {
        return LoginViewModel(userRepository)
    }
}

Java

// Definition of a Factory interface with a function to create objects of a type
public interface Factory<T> {
    T create();
}

// Factory for LoginViewModel.
// Since LoginViewModel depends on UserRepository, in order to create instances of
// LoginViewModel, you need an instance of UserRepository that you pass as a parameter.
class LoginViewModelFactory implements Factory {

    private final UserRepository userRepository;

    public LoginViewModelFactory(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public LoginViewModel create() {
        return new LoginViewModel(userRepository);
    }
}

Puoi includere LoginViewModelFactory in AppContainer e rendere LoginActivity ne consuma:

Kotlin

// AppContainer can now provide instances of LoginViewModel with LoginViewModelFactory
class AppContainer {
    ...
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Gets LoginViewModelFactory from the application instance of AppContainer
        // to create a new LoginViewModel instance
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = appContainer.loginViewModelFactory.create()
    }
}

Java

// AppContainer can now provide instances of LoginViewModel with LoginViewModelFactory
public class AppContainer {
    ...

    public UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);

    public LoginViewModelFactory loginViewModelFactory = new LoginViewModelFactory(userRepository);
}

public class MainActivity extends Activity {

    private LoginViewModel loginViewModel;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // Gets LoginViewModelFactory from the application instance of AppContainer
        // to create a new LoginViewModel instance
        AppContainer appContainer = ((MyApplication) getApplication()).appContainer;
        loginViewModel = appContainer.loginViewModelFactory.create();
    }
}

Questo approccio è migliore del precedente, ma ci sono comunque sfide da considerare:

1. Devi gestire personalmente AppContainer, creando istanze per tutti le dipendenze.

2. C'è ancora molto codice boilerplate. Devi creare fabbriche o manualmente i parametri a seconda che si voglia riutilizzare o meno un oggetto.

Gestione delle dipendenze nei flussi di applicazioni

AppContainer si complica quando si desidera includere più funzionalità del progetto. Quando l'app diventa più grande e inizi a introdurre diverse di caratteristiche, sorgono ancora più problemi:

1. Con flussi diversi, potresti volere che gli oggetti si trovino nell'ambito di tale flusso. Ad esempio, durante la creazione di LoginUserData (potrebbe essere consiste in nome utente e password utilizzati solo nel flusso di accesso) che non vuoi per mantenere i dati di un vecchio flusso di accesso da un altro utente. Vuoi un nuovo per ogni nuovo flusso. Puoi farlo creando FlowContainer all'interno di AppContainer, come illustrato nel prossimo esempio di codice.

2. Anche l'ottimizzazione del grafico dell'applicazione e dei container di flusso può essere difficile. Devi ricordarti di eliminare le istanze che non ti servono, a seconda il flusso in cui ti trovi.

Immagina di avere un flusso di accesso composto da un'attività (LoginActivity) e più frammenti (LoginUsernameFragment e LoginPasswordFragment). Queste viste mirano a:

1. Accedi alla stessa istanza LoginUserData che deve essere condivisa fino alla il flusso di accesso.

2. Crea una nuova istanza di LoginUserData quando il flusso viene riavviato.

Puoi farlo con un container del flusso di accesso. Questo container deve essere creato all'avvio del flusso di accesso e rimosso dalla memoria al termine del flusso.

Aggiungiamo LoginContainer al codice di esempio. Vuoi poter creare più istanze di LoginContainer nell'app, quindi invece di renderlo un singleton, rendila una classe con le dipendenze necessarie per il flusso di accesso AppContainer.

Kotlin

class LoginContainer(val userRepository: UserRepository) {

    val loginData = LoginUserData()

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

// AppContainer contains LoginContainer now
class AppContainer {
    ...
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    // LoginContainer will be null when the user is NOT in the login flow
    var loginContainer: LoginContainer? = null
}

Java

// Container with Login-specific dependencies
class LoginContainer {

    private final UserRepository userRepository;

    public LoginContainer(UserRepository userRepository) {
        this.userRepository = userRepository;
        loginViewModelFactory = new LoginViewModelFactory(userRepository);
    }

    public LoginUserData loginData = new LoginUserData();

    public LoginViewModelFactory loginViewModelFactory;
}

// AppContainer contains LoginContainer now
public class AppContainer {
    ...
    public UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);

    // LoginContainer will be null when the user is NOT in the login flow
    public LoginContainer loginContainer;
}

Quando hai un container specifico per un flusso, devi decidere quando creare ed eliminare l'istanza di container. Poiché il flusso di accesso è indipendente un'attività (LoginActivity), l'attività è quella che gestisce il ciclo di vita del container. LoginActivity può creare l'istanza in onCreate() e eliminalo in onDestroy().

Kotlin

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel
    private lateinit var loginData: LoginUserData
    private lateinit var appContainer: AppContainer


    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        appContainer = (application as MyApplication).appContainer

        // Login flow has started. Populate loginContainer in AppContainer
        appContainer.loginContainer = LoginContainer(appContainer.userRepository)

        loginViewModel = appContainer.loginContainer.loginViewModelFactory.create()
        loginData = appContainer.loginContainer.loginData
    }

    override fun onDestroy() {
        // Login flow is finishing
        // Removing the instance of loginContainer in the AppContainer
        appContainer.loginContainer = null
        super.onDestroy()
    }
}

Java

public class LoginActivity extends Activity {

    private LoginViewModel loginViewModel;
    private LoginData loginData;
    private AppContainer appContainer;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        appContainer = ((MyApplication) getApplication()).appContainer;

        // Login flow has started. Populate loginContainer in AppContainer
        appContainer.loginContainer = new LoginContainer(appContainer.userRepository);

        loginViewModel = appContainer.loginContainer.loginViewModelFactory.create();
        loginData = appContainer.loginContainer.loginData;
    }

    @Override
    protected void onDestroy() {
        // Login flow is finishing
        // Removing the instance of loginContainer in the AppContainer
        appContainer.loginContainer = null;

        super.onDestroy();
    }
}

Come nel caso di LoginActivity, i frammenti di accesso possono accedere all'elemento LoginContainer da AppContainer e utilizza l'istanza LoginUserData condivisa.

Perché in questo caso si ha a che fare con la logica del ciclo di vita delle visualizzazioni, utilizzando l'osservazione del ciclo di vita ha senso.

Nota: se devi mantenere il container dopo le modifiche alla configurazione, segui le Guida al salvataggio degli stati dell'interfaccia utente. Dovete gestirlo allo stesso modo gestire la morte del processo; altrimenti la tua app potrebbe perdere lo stato sui dispositivi con meno la memoria.

Conclusione

L'inserimento delle dipendenze è una buona tecnica per creare elementi scalabili e testabili. App per Android. Usa i container per condividere istanze di classi in diversi parti della tua app e come luogo centralizzato per creare istanze che utilizzano le fabbriche.

Quando la tua applicazione diventa più grande, inizierai a notare che scrivi molti codice boilerplate (come le fabbriche), che può essere soggetto a errori. Devi inoltre gestire autonomamente l'ambito e il ciclo di vita dei container, ottimizzandole e verranno ignorati i container che non sono più necessari per liberare memoria. Se lo fai in modo scorretto, potresti riscontrare lievi bug e perdite di memoria nella tua app.

Nella sezione Dagger, scopri come puoi usare Dagger per automatizzare questo processo e generare lo stesso codice altrimenti scriveresti a mano.