[Android : Kotlin] 의존성 주입의 기본을 이해해보자~!

들어가기 전에

프로젝트에서 Hilt를 사용하고 있다. 기능을 구현하기에 바빠 Hilt가 나오기까지 흐름을 제대로 시간 들여 공부해보지 못했는데 앱 출시를 위해 테스트까지 걸리는 기간동안 그동안 못했던 공부를 하며 부족한 내용을 채워보려한다~! 오늘은 의존성 주입파트!!

아자자

의존성 주입 기본

액티비티에서 뷰모델 객체가 필요한 경우

뷰모델 객체를 구성하기 위해서 레포지토리 객체가 필요
레포지토리 객체를 구성하기 위해 데이터 소스 객체가 필요
데이터 소스 객체를 구성하기 위해서 서비스 객체가 필요
서비스 객체를 구성하기 위해서는 레트로핏 객체가 필요

// 코드 구현 시
0. 레트로핏 객체 구성
1. 서비스 객체 구성
2. 데이터 소스 객체 구성 
3. 레포지토리 객체 구성
4. 뷰모델 객체 구성

 

위와 같이 순서대로 구현해줘야한다.

다른 부분에서 다른 뷰모델 객체를 만드려고 한다면 위 과정을 중복해서 구현필요

종속 항목을 순서대로 선언해줘야한다.

객체를 재사용하기 어렵다.

컨테이너로 종속 항목 관리

• 객체 재사용 문제 해결을 위해
• 종속 항목을 가져오는데 사용하는 자체 종속 항목 컨테이너 클래스 생성!
• Application에 배치하기

// Application.kt

class Application : Application() {

	// 싱글톤 패턴을 따르지 않음
	//  앱 전체에서 공유되는 고유한 인스턴스가 있는 클래스이다. 
	val appContainer : AppContainer() 
	
	}

• AppContainer

class AppContainer {

 val userViewModelFactory = UserViewModelFactory(userRepository)
	
	 private val retrofit = Retrofit
            .Builder()
            .baseUrl(movieApiBaseUrl)
            .client(OkHttpClient)
            .addCallAdapterFactory(ResultCallAdapter.Factory(retryCount))
            .addConverterFactory(json.asConverterFactory(contentType.toMediaType()))
            .build()
            
            
    
  private val userService = retrofit.create(UserService::class.java)
   
   
  private val userDataSource = UserDataSourceImpl(userService)
	
	val userRepository = UserRepositoryImpl(userDataSource)
	

• 프래그먼트에서 뷰 모델 객체 만들기

class UserFragment : Fragment() {
private lateinit var viewModel : UserViewModel

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

        // Gets userRepository from the instance of AppContainer in Application
        
        val appContainer = (application as Application).appContainer
//        viewModel = UserViewModel(appContainer.userRepository)

viewModel = appContainer.userViewModelFactory.create()
    }
}

 

이렇게 만들어진 UserRepository 객체는 싱글톤이 아니다. 다른 클래스에서도 사용할 수 있는 객체를 만들어주는 것이다.

이러한 방식으로 레포지토리 객체를 생성한다면 프로젝트에서 사용하는 모든 레포지토리 객체 생성과 관련하여 dataSource, Service, retrofit을 모두 구성해주는 코드가 필요하겠다....

 

만약 viewModel이 더 많은 곳에서 필요하다면 한곳에서 객체를 만드는 것이 좋다. 만든 뷰모델을 appContainer로 이동하고, 그 유형의 새 객체에 팩토리를 제공할 수 잇따.

// T : 만들고 싶은 어떤 타입이든 ok
// create() 는 그 타입의 새로운 객체를 만들어주는 메서드 
interface Factory<T> {
	fun create() : T
	}
	
// UserViewModel용 Factory
class UserViewModelFactory(
    private val userRepository: UserRepository
) : Factory<UserViewModel> {
// 여기서 T : UserViewModel
    override fun create(): UserViewModel {
        return UserViewModel(userRepository)
    }
}

비교

• 기존
  • 액티비티나 프래그먼트에서 뷰모델 생성

  userViewModel = UserViewModel(appContainer.userRepository)
  
  

• 변경 : Factory를 통해 AppContainer로 뷰모델 생성 책임을 이동한다.
• class AppContainer { val userViewModelFactory = UserViewModelFactory(userRepository)

팩토리 패턴

• 객체 생성을 담당하는 별도의 클래스(팩토리)를 두어 객체 생성 로직을 캡슐화하는 디자인 패턴

범위

• 다양한 기능 흐름을 도입하며 객체가 해당 흐름의 범위에만 있기를 원할 수 있다.
  • 예를 들어 로그인 흐름에서만 사용되는 사용자 이름과 비밀번호로 구성될 수 있는 LoginUserData를 만들 때, 다른 사용자의 이전 로그인 흐름의 데이터를 유지하지 않고 모든 새 흐름에 새 인스턴스를 만들고 싶을 수도 있다.

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
}

 

흐름 관련 컨테이너가 있으면 컨테이너 객체를 언제 만들고 삭제할지 판단해야한다.

로그인 흐름이 LoginActivity에 독립적이므로 이 컨테이너의 수명 주기를 LoginActicity에서 관리하면 된다. onCreate에서 객체를 만들고, onDestroy에서 삭제할 수 있다. 

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

}

---

Dagger

종속항목을 선언하고, 어노테이션을 사용하여 종속항목을 어떻게 충족하는지 지정하기만 하면 아래를 빌드 시간에 자동으로 구현해준다.

위에서 수동으로 종속항목에 대한 컨테이너를 생성해보며 , 여러 레포지토리 객체를 구성할 경우 중복, 반복해서 작성해줘야할 코드가 많겠다고 느꼈다. 이를 해소해주기 위해 Dagger에서는 수동으로 구현하던 로직을 자동으로 구현해준다.

• 위에서 수동으로 구현했던 AppContainer 코드를 생성해준다.
• AppContainer(application grapth)에서 사용하는 클래스의 팩토리를 만들어준다.
• 범위를 통해 종속 항목을 재사용할지, 새 인스턴스를 만들지 결정
• 로그인 흐름을 처리했던 것처럼 Dagger subcomponent를 사용하여 특정한 플로우를 위한 컨테이너를 만들어준다.
  • 더이상 사용되지 않을 대 객체를 해제해줌으로써 성능 향상
• 클래스의 인스턴스를 제공하는 방법을 찾기 위해 참조할 수 있는 객체의 그래프를 만든다.
  • 그래프의 모든 클래스와 관련하여 필요한 유형의 인스턴스를 가져오는데 내부적으로 팩토리 유형 클래스를 생성

예시

UserRepository 객체를 생성하기 위해 UserLocalDataSource, UserRemoteDataSource가  필요하다면 아래와 같이 작성할 수 있다. 

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

 

  Dagger가 UserRepository 를 생성하는 방법을 알 수 있도록 @Inject 주석을 UserRepository 생성자에 추가한다.

// @Inject
// 1. Dagger가 UserRepository 객체를 어떻게 생성하는지 알게 해준다.
// 2. 종속항목은 UserLocalDataSource 및 UserRemoteDataSource임을 알려준다.

class UserRepository @Inject constructor(
	private val localDataSource : UserLocalDataSource,
	private val remoteDataSource:  
) { ... }

 

이제 종속항목을 만드는 방법을 알려줘야한다. UserLocalDataSource와UserRemoteDataSource에도 @Inject를 붙여서 객체를 생성하는 방법을 알려준다.

class UserLocalDataSource @Inject constructor() { ... }
class UserRemoteDataSource @Inject constructor() { ... }

 

Dagger 구성요소

Dagger는 종속 항목이 필요할 때 가져올 위치를 찾는데 사용할 수 있는 프로젝트의 종속 항목 그래프를 만들 수 있다.

1. 인터페이스 생성
2. @Component로 주석 지정

→ 이를 통해 컨테이너를 만든다.

@Component로 주석을 준 interface 내에서 필요한 클래스의 인스턴스(UserRepository)를 반환하는 함수를 정의할 수 있다.

즉 @Component는 Dagger에게 이렇게 말하는 것과 같다.

@Component : Dagger야 나는 이런 것들이 필요해. 알아서 만들어줄래?

//@Component : Dagger가 의존성 그래프를 생성하도록 한다.
@Component(modules = [NetworkModule::class, DatabaseModule::class])
interface ApplicationGraph {
    fun repository(): UserRepository
}

 

프로젝트 빌드 시에 Dagger는 자동으로 ApplicationGraph 인터페이스의 구현인 DaggerApplicationGraph를 생성한다. 

이를 통해 이 그래프는 UserRepository, UserLocalDataSource, UserRemoteDataSource 클래스 간의 관계로 구성된 중속 항목 그래프를 만들어준다.

val applicationGraph : ApplicationGraph = DaggerApplicationGraph.create()
val userRepository : UserRepository = applicationGrapgh.repotiroy()

 

Dagger는 applicationGrapgh.repository() 를 호출할 때마다   UserRepository의 새 인스턴스를 만든다.

val applicationGraph: ApplicationGraph = DaggerApplicationGraph.create()

val userRepository: UserRepository = applicationGraph.repository()
val userRepository2: UserRepository = applicationGraph.repository()

assert(userRepository != userRepository2)

 

만약 고유한 인스턴스가 필요하다면??

 

매번 UserRepository 객체를 새로 생성할 필요가 있을까??

- 만약 동일한 데이터를 여러 뷰모델에서 공유하고자 하는 경우 

- 객체를 생성하는데 비용이 많이 든다는 점 을 고려했을 때 로직에 맞게 인스턴스를 구성하는 것이 좋다!

 

수동으로 종속 항목을 구현할 때는 동일한 UserRepository 객체를 뷰모델 클래스의 생성자에 전달하는 것으로 구현했지만 Dagger에서는 범위 주석을 통해서 동일한 객체를 생성할거야! 라고 알려줄 수 있다.

범위 지정

// Dagger에게 이 그래프에서 만드는 @Singleton 객체들은 앱이 살아있는 동안 
// 딱! 하나만 만들어서 재사용해줘 라고 말하는 것과 같다.

@Singleton
@Component 
interface ApplicationGraph {
	fun repository() : UserRepository
}

 

UserRepository를 앱 전체에서 딱 하나의 객체를 사용하도록 만들어준다. 

이를 통해 뷰모델에서 UserRepostory로 작업 시에 일관된 데이터를 사용할 수 있다. 

@Singleton
class UserRepository @Inject constructor(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

이 파트에서는 종속 항목 그래프를 그려나가면서, 필요한 범위를 생각해보면 좋겠다. 무턱대로 싱글톤으로 구현하기 보다는 적절한 범위를 지정해보자!

---

Android에서 Dagger를 사용해보자!

권장 사항

- 가능하면 생성자 삽입을 하고 가능하지 않은 경우는 아래와 같이 하자

- @Binds -> 인터페이스 형태의 종속 항목 삽입으로 인터페이스에 어떤 구현이 있어야하는지 알려주기

- @Provides -> 프로젝트가 소유하지 않은 클래스를 제공하는 방법을 알려준다.

- 사용되는 전체 기간에 따라 범위를 지정해준다

 

// 1. 앱의 의존성 그래프 정의 
@Component
interface ApplicaitionComponent {...}


// Application의 생명주기를 공유하기 위해 appComponent를 Application에 둔다.
class Application : Application() {
	val appComponent = DaggerApplicationComponent.create()
}

 

액티비티나 프래그먼트와 같은 클래스는 시스템에 의해 인스턴스화되기 때문에 Dagger가 자동으로 생성할 수 없다. 

따라서 액티비티나 프래그먼트에서는 필드 삽입을 통해서 필요한 종속 항목을 알려줄 수 있다.

 

Activity, Fragment, Service, BroadcastReceiver, ContentProvider , 즉 안드로이드 프레임워크 클래스에서 생성자 삽입이 불가능하다!! 따라서  필드 삽입을 사용해야한다.

class UserFragment : Fragment()  {

	@Inject lateinit var userViewModel : UserViewModel

}

 

액티비티에서 뷰모델 객체를 제공받기 위해서는

@Component
interface ApplicationComponent {
	
    fun inject(activity : LoginActivity)
    // Dagger에게  " LoginActivity가 주입을 요청하고 있어. 
    // 그러니까 그래프는 액티비티가 요청하는 모든 필드의 의존성을 만족해야해!" 
    
    // 액티비티가 그래프에 접근하길 원하며 삽입을 요청한다고 Dagger에게 알려준다. 

}

 

class LoginActivity : Activity() {

	// 뷰모델 객체 
    // 종속 항목 그래프를 통해LoginViewModel 객체를 받고 싶어요! 라고 Dagger에게 요청하는 것
    @Inject lateinit var loginViewModel : LoginViewModel


	override fun onCreate(savedInstanceState: Bundle?) {
        
        (applicationContext as Application).appComponent.inject(this)
        
        /*
        	1. Dagger야 , LoginActivity의 @Inject 필드 들을 초기화해줘
            2. 실제로 주입 
            3. 이제 loginViewModel 사용 가능 
        
        */ 

        super.onCreate(savedInstanceState)
    }

}

 

@Inject : Dagger야, LoginViewModel은 이렇게 만들면 돼! 

class LoginViewModel @Inject constructor(
    private val userRepository: UserRepository
)

 

그러면 Dagger는 레토지토리 객체를  구성하려고 할 것이고, 이에 따라 필요한 UserLocalDataSource, UserRemoteDataSource 객체들을 구성하는 방법을 Dagger에게 알려줘야한다. 이를 위해서는 @Inject constructor (...)을 사용하면 된다.

모듈

UserRemoteDataSource에는 레트로핏이 사용된다. 레트로핏 객체 구성을 위해서는 클래스 인스턴스화가 아닌 Retrofit.Builder()를 호출해야한다.

이 때는 @Inject 대신 @Module을 통해 Dagger에게 이 클래스는 Dagger 모듈이야 라고 알려줄 수 있다.

@Module 
class NetworkModule {...}

 

여기서 모듈은 객체를 제공하는 방법에 대한 정보를 캡슐화한 것이다. 

아래에서는 네트워킹 관련 객체를 제공하는 로직을 그룹화하기 위해 NetworkModule 클래스를 호출했다. 

// 1. Dagger 모듈이야 
@Module
class NetworkModule {
	
    // 2. 이 함수가 반환하는 타입의 객체를 생성하면 돼
    // 프로젝트가 소유하지 않은 클래스(ex. retrofit, okHttpClient, Gson 등) 객체를 제공하는 방법을 알려준다.
	@Provides
    fun provideLoginRetrofitService(
    	okHttpClient : OkHttpClient
    ) : LoginRetrofitService {
    	return Retrofit.Builder()
        		.baseUrl("https://example.com")
                .build()
               
                .create(LoginService::class.java) 
    } 
    
  
}

 

이렇게 모듈을 정의해준 후 Dagger 그래프가 이 모듈에 관해 알 수 있도록 하려면 다음과 같이 @Component 인터페이스에 모듈을 추가해줘야한다.

 

// modules:  그래프를 구성할 때 포함되어야할 모듈을 알려주는 역할 
@Component(modules = [NetworkModule::class])
interface ApplicationComponent {...}

 

 

LoginActivity는 LoginViewModel이 필요하다. Dagger는 LoginViewModel & 종속 항목의 인스턴스를 제공하는 방법을 담은 그래프를 빌드한다. 

Dagger는 클래스 생성자의 @Inject는 통해 방법을 알고 있다. 생성한 ApplicationComponent 내에는 제공 방법을 알 고 있는 모든 클래스의 인스턴스를 가져오는 팩토리 메서드가 있다. 또한 LoginRetrofitService 객체를 얻기 위해 NetworkModule을 포함하고 있다.

범위

@Singleton
@Component(modules = [NetworkModule::class])
interface ApplicationComponent {
	fun inject(activity : LoginActivity)
}

@Singleton
class UserRepository @Inject constructor(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }


@Module
class NetworkModule {
	
    @Singleton
    @Provides
    fun provideLoginRetrofitService(): LoginRetrofitService { ... }

}

---

원하는 Scope로 구성해보자

로그인 흐름을 구성하는 화면이 여러 개의 프래그먼트로 되어있다면 로그인 흐름의 프래그먼트에서는 동일한 LoginViewModel 객체를 재사용해야한다.

그렇다면 로그인 흐름이 완료된 후에는 어떨까?

로그인 흐름이 끝났다면 이제 더이상 LoginViewModel이 남아있지 않아도 된다.

각 로그인 흐름마다 , 다시 말해 로그인 흐름에 대해서 다른 LoginViewModel 인스턴스가 필요하다.  사용자가 로그아웃한 경우에는 처음 로그인했을 때와는 다른 뷰모델 객체가 필요하다.

싱글톤으로 구현 시에는 이전 로그인 정보가 남아있거나 이전 데이터나 남아있을 수 있기 때문에 이를 방지하기 위해서  뷰모델의 범위를 LoginActicity의 수명 주기로 지정할 수 있다.

 

따라서 이런 경우라면 로그인 전용 Scope를 만들어주면 된다.

@Component
interface LoginComponent {}

 

LoginActivity는 로그인 별 구성이 있으므로 LoginComponent에서 종속 항목을 받아야한다.

@Component
interface LoginComponent {
	fun inject(activity : LoginActivity)
}

 

LoginActivity는 LoginViewModel이 필요하다. 이 때 LoginViewModel은 UserRepository에 종속되기 때문에 LoginComponent는 ApplicationComponent의 객체에 접근할 수 있어야한다. 이 때 Dagger의 SubComponent를 사용할 수 있다.

 

새 구성요소가 다른 구성 요소의 일부를 사용하도록 하는 방법이 @SubComponent이다.

여기서 하위 구성요소는 상위 구성 요소의 객체 그래프를 상속 및 확장하는 구성 요소이다.  따라서 상위 구성요소에 제공된 모든 객체는 하위 구성요소에도 제공된다. 즉 ApplicationComponent에 제공된 모든 객체는 LoginComponent에도 제공되도록 할 수 있다.

 

// @SubComponent : Dagger에게 이 인터페이스가 하위 구성 요소임을 알려준다.
@SubComponent
interface LoginComponent {
	fun inject(loginActivity: LoginActivity)
}

 

또한 ApplicationComponent가 LoginComponent의 인스턴스를 생성하는 방법을 알 수 있도록 아래와 같이 하위 구성요소 팩토리를 정의해준다.

@Subcomponent
interface LoginComponent {

	@Subcomponent.Factory
    interface Factory {
    	fun create() : LoginComponent
    }
    
    fun inject(loginActivity: LoginActivity)
}

 

그리고 LoginComponent가 ApplicationComponent의 하위 구성 요소임을 Dagger에게 알려준다.

 

1. 먼저 하위 구성 요소 클래스를 subcomponents 속성에 전달하는 새로운 모듈을 만들어준다.

@Module(subcomponents = LoginComponent::Class)
class SubComponentModule {}

 

2. 새 모듈을 ApplicationComponent에 추가해준다.

@Singleton
@Component(modules = [NetworkModule::Class, SubComponentsModule::Class])
interface ApplicationComponent { ... }

 

이제 LoginActivity에 종속항목을 주입하는 것은 ApplicationComponent가 아닌 LoginComponent이기 때문에 ApplicationComponent 내부 inject() 메서드를 삭제할 수 있다.

대신 LoginComponent 인스턴스를 생성하는 방법을 알아야하기 때문에 팩토리를 호출해준다.

@Singleton
@Component(modules = [NetworkModule::class, SubcomponentsModule::Class])
interface ApplicationComponent {
	// fun inject(activity : LoginActivity) -> 삭제 
    
    fun loginComponent() : LoginComponent.Factory
}

 

LoginComponent의 범위는?

LoginComponent를 만들었던 이유는

1. 로그인 흐름 중 동일한 LoginViewModel 인스턴스를 공유하기 위함

2, 각 로그인 흐름마다는 다른 뷰모델 객체를 사용해야함

이었다. 따라서 LoginComponent의 적절한 기간은 LoginActivity와 동일하다. 모든 새 활동에는 LoginComponent의 새로운 인스턴스와 이러한 인스턴스를 사용할 수 있는 프래그먼트가 필요하다. 

 

이렇게함으로써 LoginComponent는 LoginActivity의 수명주기와 연결된다. 

class LoginActivity : Activity() {
	// 로그인 그래프에 대한 참조
	lateinit var loginComponent : LoginComponent

}

 

ApplicationComponent를 사용해서 LoginComponent의 참조를 가져온 후 변수에 넣어주면 된다.

class LoginActivity: Activity() {

    lateinit var loginComponent: LoginComponent
    
    // 로그인 그래프에 의해서 주입되어야하는 필드 
    @Inject lateinit var loginViewModel : LoginViewModel
    
     override fun onCreate(savedInstanceState: Bundle?) {
     
     // application 그래프를 이용해서 로그인 그래프를 만든다.
     	loginComponent = (applicationContext as Application).appComponent.loginComponent().create()
       
     // 로그인 액티비티에서 @Inject 필드들을 초기화해준다. -> 삽입 -> 뷰모델을 사용할 있다.
       loginComponent.inject(this)

        super.onCreate(savedInstanceState)
    }
    
}

 

이 쯤에서 구조를 한번 정리해보면 

- Application Scope

• ApplicationComponent : 앱 전체의 싱글톤 의존성 관리 
• NetworkModule(OkhttpClient, Retrofit)과 같은 전역적으로 필요한 의존성 포함

- LoginFlow Scope

• LoginComponent는 로그인 기능만 담당
• LoginViewModel은 이 scope안에서만 존재
• 모든 로그인 흐름과 관려된 화면들은 뷰모델 공유

LoginViewModel이 필요한 두개의 프래그먼트가 있다면 두 프래그먼트 모두 동일한 인스턴스와 함께 제공된다.

@ActivityScope
@SubComponent
interface LoginComponent {
	
    @Subcomponent.Factory
    interface Factory {
    	fun create(): LoginComponent
    }	
    
   // LoginActivity , LoginUsernameFragment , LoginPasswordFragment 등 
   // 로그인과 관련된 모든 화면들은 LoginComponent에 의존성 주입을 요청한다.
   fun inject(loginActivity : LoginActivity)
   fun inject(usernameFragment : LoginUsernameFragment)
   fun inject(passwordFragment : LoginPasswordFragment)
   
}

 

이제 LoginUsernameFragment에서 사용하는 법을 보자

class LoginUsernameFragment: Fragment() {
	// 로그인 그래프로부터 주입되어야하는 필드
    @Inject lateinit var loginViewModel : LoginViewModel
    
     override fun onAttach(context: Context) {
        super.onAttach(context)
        
        // 1. LoginActivity로부터 login그래프 가져오기 
        // 2. 그래프를 사용해서 @Inject 필드들을 초기화하기
        
        (activity as LoginActivity).loginComponent.inject(this)
        
        // 이제 loginViewModel에 접근 가능, onCreateView에서도 접근 가능,

---

Hilt 

Dagger와 Hilt의 차이 

• 코드로 살펴보기

// Dagger

// Hilt