-의존성이 Hilt Component에 바인딩이 될 때 Hilt는 어떠한 의존성을 식별 할 수 있는 식별자로 클래스의 패키지 명을 포함하고 있는 시그니처를 식별자로 활용하게 된다.
-어떤 의존성이 Hilt Component에 바인딩이 되었을 때 바인딩 된 의존성을 클라이언트에서 요청하면 , Hilt가 어떠한 의존성을 요청했는지 구분 할 수 있는 이유는 어노테이션이 마킹된 위치에 정확하게 해당 의존성 타입이 명시되어 있기 때문이다.
-Hilt는 타입으로 구분을 해가지고 의존성을 바인딩하고 의존성을 주입하는 것이 가능하다.
중복 바인딩
-그렇다면 만약에 동일한 타입의 의존성이 두번 바인딩 된다면 어떨까 ?? 클라이언트가 Hilt Comoponent에게 의존성을 요청을 할 때 Hilt Component는 어떠한 의존성을 제공해야 할 지 헷갈린다. 그러면 컴파일 타임에서 중복 바인딩 에러가 발생하게 된다.
@Qualifier
-만약 중복 바인딩을 유지한 채로 어떠한 중복 바인딩들을 구분해서 사용하고 싶을 때도 있다. 그럴 때 사용하는 어노테이션이 @Qualifier이다.
-중복 바인딩 된 의존성 타입이 Hilt Component에 존재하더라도 @Qualifier를 통해서 구분을 할 수 있다.
-그렇다고 @Qualifier를 직접적으로 사용하는 것은 아니다. 사용방법은 @Qualifier를 어노테이션으로 가지는 새로운 어노테이션 클래스를 정의해서 사용해야 한다.
-@Qualifier를 어노테이션으로 가지는 새로운 어노테이션 클래스를 생성하였으면 이 새로운 어노테이션 클래스를 바인딩 하고자 하는 영역에 가져다가 붙히고 의존성 주입을 요청하는 데에도 가져다가 붙히면 된다.
-@Qualifier를 통해서 새로운 어노테이션을 생성하는 예시코드
@Qualifier
annotation class CustomQualifier
-아래처럼 Foo를 제공하는 메서드가 중복 바인딩이 되어있음에도 불구하고 provideFoo1()에는 @CustomQualifer가 마킹되어 있기 때문에 컴파일 타임에 오브젝트 그래프를 생성을 할 때 provideFoo1()과 provideFoo2() 이 두가지를 구분을 할 수 있다.
- 새로운 어노테이션 클래스를 바인딩 하고자 하는 영역에 가져다가 붙히는 예시코드(1)
@InsatallIn(SingletonComponent::class)
object AppModule {
@CustomQualifier
@Provides
fun provideFoo1() : Foo {
return Foo()
}
@Provides
fun provideFoo2() : Foo {
return Foo()
}
}- 의존성 주입을 요청하는 부분에 붙히는 경우 예시코드(1)
@AndroidEntryPoint
class MainActivity : ComponentActivity() {
@CustomQualifier
@Inject
lateinit var foo : Foo
}-같은 의존성이라고 하여도 @Qualifier 어노테이션을 사용해서 생성한 어노테이션 클래스이냐 아니냐에 따라 또는 새롭게 생성한 어노테이션 클래스의 이름에 따라 Hilt Component가 구별해서 해당 의존성을 클라이언트에게 주입 할 수 있다.
@Named
-중복 바인딩을 해결 할 때 @Qualifier 어노테이션을 마킹하는 것보다 @Named 어노테이션을 마킹하는 것이 더 간단하다.
-@Named 어노테이션은 이미 정의가 되어 있으므로 @Named()의 파라미터 자리에 내가 지정하고 싶은 이름을 문자열로 넣어주면 된다.
-그럼 해당 문자열을 유니크한 키값으로 갖을 수 있어서 Hilt Component가 구분을 할 수 있다.
