Ręczne wstrzykiwanie zależności (Views)

Pojęcia i implementacja w Jetpack Compose

Zalecana architektura aplikacji na Androida zachęca do dzielenia kodu na klasy, aby korzystać z zasady rozdzielenia odpowiedzialności, zgodnie z którą każda klasa w hierarchii ma jedno określone zadanie. Prowadzi to do powstania większej liczby mniejszych klas, które muszą być połączone, aby spełniać swoje zależności.

Aplikacje na Androida zwykle składają się z wielu klas, z których niektóre są od siebie zależne.
Rysunek 1. Model grafu aplikacji na Androida

Zależności między klasami można przedstawić w postaci grafu, w którym każda klasa jest połączona z klasami, od których zależy. Reprezentacja wszystkich klas i ich zależności tworzy wykres aplikacji. Na rysunku 1 widać abstrakcyjny wykres aplikacji. Jeśli klasa A (ViewModel) zależy od klasy B (Repository), między nimi znajduje się linia wskazująca zależność.

Wstrzykiwanie zależności pomaga nawiązywać te połączenia i umożliwia zamianę implementacji na potrzeby testowania. Na przykład podczas testowania ViewModel, które zależy od repozytorium, możesz przekazywać różne implementacje repozytorium z użyciem fałszywych obiektów lub atrap, aby przetestować różne przypadki.

Podstawy ręcznego wstrzykiwania zależności

Z tej sekcji dowiesz się, jak zastosować ręczne wstrzykiwanie zależności w rzeczywistej aplikacji na Androida. Opisuje iteracyjne podejście do rozpoczęcia korzystania z wstrzykiwania zależności w aplikacji. Podejście to jest ulepszane, aż osiągnie punkt bardzo podobny do tego, co Dagger generuje automatycznie. Więcej informacji o Daggerze znajdziesz w artykule Podstawy Daggera.

Ścieżka to grupa ekranów w aplikacji, które odpowiadają funkcji. Logowanie, rejestracja i płatność to przykłady ścieżek.

W przypadku typowej aplikacji na Androida proces logowania LoginActivity zależy od LoginViewModel, który z kolei zależy od UserRepository. Wtedy UserRepository zależy od UserLocalDataSource i UserRemoteDataSource, które z kolei zależą od usługi Retrofit.

LoginActivity to punkt wejścia do procesu logowania, a użytkownik wchodzi w interakcję z aktywnością. Dlatego LoginActivity musi utworzyć LoginViewModel ze wszystkimi zależnościami.

Klasy Repository i DataSource przepływu wyglądają tak:

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;
   }

   ...
}

Oto jak wygląda znak 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);
   }
}

Z tym podejściem wiążą się pewne problemy:

  1. Jest tam dużo powtarzalnego kodu. Jeśli chcesz utworzyć kolejną instancję LoginViewModel w innej części kodu, nastąpi duplikacja kodu.

  2. Zależności muszą być deklarowane w odpowiedniej kolejności. Aby utworzyć obiekt UserRepository, musisz go najpierw zainicjować LoginViewModel.

  3. Trudno jest ponownie użyć obiektów. Jeśli chcesz ponownie użyć UserRepositoryw wielu funkcjach, musisz zastosować wzorzec singleton. Wzorzec singleton utrudnia testowanie, ponieważ wszystkie testy korzystają z tej samej instancji singletona.

Zarządzanie zależnościami za pomocą kontenera

Aby rozwiązać problem z ponownym używaniem obiektów, możesz utworzyć własną klasę kontenera zależności, której będziesz używać do pobierania zależności. Wszystkie instancje udostępniane przez ten kontener mogą być publiczne. W tym przykładzie potrzebujesz tylko instancji UserRepository, więc możesz ustawić jej zależności jako prywatne, a w przyszłości, jeśli będzie to konieczne, możesz je udostępnić:

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);
}

Ponieważ te zależności są używane w całej aplikacji, muszą znajdować się w miejscu wspólnym, z którego mogą korzystać wszystkie aktywności: w klasie Application. Utwórz klasę niestandardową Application, która zawiera instancję 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();
}

Teraz możesz pobrać instancję AppContainer z aplikacji i uzyskać instancję 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);
   }
}

W ten sposób nie masz pojedynczego elementu UserRepository. Zamiast tego masz AppContainerudostępniony we wszystkich działaniach, który zawiera obiekty z wykresuAppContainer i tworzy instancje tych obiektów, które mogą być używane przez inne klasy.

Jeśli LoginViewModel jest potrzebny w wielu miejscach w aplikacji, warto mieć centralne miejsce, w którym tworzysz instancje LoginViewModel. Możesz przenieść tworzenie LoginViewModel do kontenera i zapewnić nowe obiekty tego typu za pomocą fabryki. Kod dla LoginViewModelFactory wygląda tak:

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<LoginViewModel> {
   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<LoginViewModel> {

   private final UserRepository userRepository;

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

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

Możesz umieścić LoginViewModelFactory w AppContainer i sprawić, że LoginActivity będzie z niego korzystać:

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();
   }
}

To podejście jest lepsze od poprzedniego, ale nadal wiąże się z pewnymi wyzwaniami:

  1. Musisz samodzielnie zarządzać AppContainer, ręcznie tworząc instancje dla wszystkich zależności.
  2. Wciąż jest dużo powtarzalnego kodu. Fabryki lub parametry musisz tworzyć ręcznie w zależności od tego, czy chcesz ponownie użyć obiektu.

Zarządzanie zależnościami w przepływach aplikacji

AppContainer staje się skomplikowane, gdy chcesz dodać do projektu więcej funkcji. Gdy aplikacja się rozrasta i zaczynasz wprowadzać różne ścieżki funkcji, pojawia się jeszcze więcej problemów:

  1. Jeśli masz różne automatyzacje, możesz chcieć, aby obiekty istniały tylko w zakresie danej automatyzacji. Na przykład podczas tworzenia LoginUserData (który może składać się z nazwy użytkownika i hasła używanych tylko w procesie logowania) nie chcesz zachowywać danych ze starego procesu logowania innego użytkownika. Chcesz, aby każdy nowy przepływ miał nową instancję. Możesz to zrobić, tworząc obiekty FlowContainer w obiekcie AppContainer, jak pokazano w przykładzie kodu poniżej.
  2. Optymalizacja wykresu aplikacji i kontenerów przepływu może być trudna. W zależności od wybranego procesu musisz pamiętać o usuwaniu instancji, których nie potrzebujesz.

Załóżmy, że masz przepływ logowania składający się z 1 aktywności (LoginActivity) i kilku fragmentów (LoginUsernameFragment i LoginPasswordFragment). Te widoki chcą:

  1. Uzyskaj dostęp do tej samej instancji LoginUserData, która ma być udostępniana, aż do zakończenia procesu logowania.
  2. Utwórz nową instancję LoginUserData, gdy przepływ zacznie się od nowa.

Możesz to zrobić za pomocą kontenera przepływu logowania. Ten kontener musi zostać utworzony na początku procesu logowania i usunięty z pamięci po jego zakończeniu.

Dodajmy LoginContainer do przykładowego kodu. Chcesz mieć możliwość tworzenia w aplikacji wielu instancji LoginContainer, więc zamiast tworzyć z niej singleton, utwórz klasę z zależnościami, których proces logowania potrzebuje od 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;
}

Gdy masz już kontener przypisany do konkretnego przepływu, musisz zdecydować, kiedy utworzyć i usunąć instancję kontenera. Ponieważ proces logowania jest zawarty w aktywności (LoginActivity), to ona zarządza cyklem życia tego kontenera. LoginActivity może utworzyć instancję w onCreate i usunąć ją w 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();
   }
}

Podobnie jak LoginActivity, fragmenty logowania mogą uzyskiwać dostęp do LoginContainer z AppContainer i korzystać ze wspólnej instancji LoginUserData.

W tym przypadku masz do czynienia z logiką cyklu życia widoku, więc użycie lifecycle observation ma sens.