Injeção de dependência manual (Views)

Conceitos e implementação do Jetpack Composearrow_forward

A arquitetura de apps recomendada do Android incentiva a divisão do código em classes para tirar proveito da separação de preocupações, um princípio em que cada classe da hierarquia tem uma única responsabilidade definida. Isso leva a mais classes menores que precisam ser conectadas para atender às dependências umas das outras.

.

As dependências entre as classes podem ser representadas como um gráfico, em que cada classe se conecta às classes de que depende. A representação de todas as classes e as respectivas dependências representam o gráfico do aplicativo. Na Figura 1, é possível ver uma abstração do gráfico do aplicativo. Quando a classe A (ViewModel) depende da classe B (Repository), há uma linha que aponta de A para B representando essa dependência.

A injeção de dependências ajuda a fazer essas conexões e permite que você troque implementações para testes. Por exemplo, ao testar um ViewModel que depende de um repositório, você pode transmitir implementações diferentes deRepository com falsificações ou simulações para testar os casos diferentes.

Conceitos básicos da injeção de dependência manual

Esta seção aborda como aplicar a injeção manual de dependências em um cenário real de um app Android. Ela trata de uma abordagem iterada de como é possível começar a usar a injeção de dependência no seu app. A abordagem melhora até chegar a um ponto muito parecido com o que o Dagger geraria automaticamente para você. Para mais informações sobre o Dagger, consulte Princípios básicos do Dagger.

Considere um fluxo como um grupo de telas no app, correspondente a um recurso. Login, registro e finalizações de compra são exemplos de fluxos.

Ao cobrir um fluxo de login para um app Android típico, o LoginActivity depende de LoginViewModel, que, por sua vez, depende de UserRepository. Em seguida, UserRepository depende de um UserLocalDataSource e um UserRemoteDataSource, que, por sua vez, dependem de um Retrofit serviço.

LoginActivity é o ponto de entrada para o fluxo de login, e o usuário interage com a atividade. Assim, LoginActivity precisa criar o LoginViewModel com todas as dependências.

As classes Repository e DataSource do fluxo têm esta aparência:

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

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

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

class UserRemoteDataSource {

   private final Retrofit retrofit;

   public UserRemoteDataSource(Retrofit retrofit)