[Hilt] 10.1 Design Decisions – 설계 개요

https://dagger.dev/hilt/design-overview 10.1 Design Decisions – Design Overview 컴포넌트 생성과 모듈/Entry point 설치 Hilt는 전이 클래스 경로에서 모든 모듈과 Entry point를 찾아 컴포넌트를 생성한다. 모든 모듈의 @InstallIn 어노테이션과 Entry point는 정의된 패키지에서 작은 메타데이터 클래스를 생성하게 된다. @HiltAndroidApp를 처리 할 때 컴포넌트에 설치해야 하는 모든 집계된 항목을 찾기 위해 특수 패키지를 더보기…

[Hilt] 9. Creating Extensions

https://dagger.dev/hilt/creating-extensions 모듈과 Entry point 생성하기 Hilt는 표준 컴포넌트와 클래스 경로에서 모듈 및 Entry point가 선택되는 방식으로 인해 Hilt와 통합하려는 확장(extension) 또는 라이브러리에 특히 적합하다. 그러나, @InstallIn 모듈을 생성하는 확장 또는 Entry point는 Hilt가 올바르게 선택할 수 있도록 생성된 클래스에 추가 정보를 넣어야 한다. @GeneratesRootInput Hilt는 클래스 경로에서 모듈과 Entry point를 더보기…

[Hilt] 8. 컴파일러 옵션

https://dagger.dev/hilt/compiler-options @InstallIn 검사 비활성화 하기 기본적으로 Hilt는 @InstallIn 어노테이션에 대한 @Module 클래스를 검사하고 @InstallIn이 없다면 에러를 나타낸다. 누군가 실수로 모듈에 @InstallIn을 누락시켰을까봐 이러한 기능이 사용되고 있으며, 이는 Hilt가 해당 모듈을 챙기지 못해 디버깅을 어렵게 만들 수 있다. 이런 검사는 때로는 지나치게 광범위 할 수 있다. 특히 마이그레이션 진행중이라면 말이다. 이러한 더보기…

[Hilt] 7.3 Migration – 스코프 별칭

https://dagger.dev/hilt/scope-aliases 7.3 Scope aliases 스코프 별칭은 왜 필요한가? 현재 많은 코드에서 사용중인 스코프 어노테이션 중 Hilt가 제공하는 스코프 어노테이션으로 변경하고 싶다면, 스코프 별칭(Scope alias)는 마이그레이션 할 때 유용하다. 코드베이스에 따라 스코프 어노테이션을 변경하는 것은 많은 작업을 필요로 한다. 스코프 별칭을 추가하는 것으로 이러한 전환 작업을 점진적으로 할 수 있다. 스코프 더보기…

[Hilt] 7.2 Migration – 선택적 주입

https://dagger.dev/hilt/optional-inject 7.2 Migration – Optional Injection 왜 선택적 주입이 필요한가? Hilt를 사용하는 Fragment는 Hilt를 사용하는 Activity에 속해야 하고, Hilt를 사용하는 Activity는 Hilt를 사용하는 Application에 속해 있어야 한다. 이는 순수한 Hilt 코드베이스를 위해서는 자연스러운 제약조건이며, Hilt를 사용하지 않는 Fragment 또는 Activity를 가지고 있다면 마이그레이션 할때 문제가 될 수 있다. 예를 들면, 더보기…

[Hilt] 7.1 Migration – 가이드

https://dagger.dev/hilt/migration-guide 7.1 Migration – Guide Hilt로 마이그레이션 하는 것은 코드베이스 상태와 코드베이스가 따르는 관행 또는 패턴에 따라 매우 다양할 수 있다. 이 페이지는 앱 마이그레이션시 발생할 수 있는 몇가지 일반적인 문제에 대한 권고사항을 제공한다. 이 페이지는 여러분이 이미 기본 Hilt API를 이해하고 있다고 가정한다. 그렇지 않은 경우 Hilt를 위한 ‘Quick 더보기…

[Hilt] 6.3 Testing – Instrumentation Testing

https://dagger.dev/hilt/instrumentation-testing 6.3 Testing – Instrumentation Testing 테스트 Application 설정하기 Hilt의 테스트 API는 특정 테스트 환경에 무관하게 설계되었다. 그러나 테스트에서 Application 클래스를 설정하기 위한 방법은 Robolectric 또는 안드로이드 Instrumentation 테스트를 사용 중인지 여부에 따라 다르다. 안드로이드 Instrumentation 테스트에서 AndroidJUnitRunner를 확장하는 사용자화 테스트 러너(runner)를 사용하여 Application이 설정될 수 있다. 러너를 사용하는 Application을 더보기…

[Hilt] 6.2 Testing – Robolectric Testing

https://dagger.dev/hilt/robolectric-testing 6.2 Testing – Robolectric Testing 테스트 Application 설정하기 Hilt의 테스트 API는 특정 테스트 환경에 무관하게 설계되었다. 그러나 테스트에서 Application 클래스를 설정하기 위한 방법은 Robolectric 또는 안드로이드 Instrumentation 테스트를 사용 중인지 여부에 따라 다르다. Robolectric 테스트에서는 국소적으로 @Config를 사용하거나 전역적으로 robolectric.properties를 사용하여 Application을 설정할 수 있다. Hilt를 위한 테스트에서 Application은 더보기…

[Hilt] 6.1 Testing – Testing 개요

https://dagger.dev/hilt/testing 6.1 Testing – Testing 개요 소개 Note : 현재 Hilt는 안드로이드 Instrumentation 과 Robolectric 테스트만 지원한다. Hilt는 vanilla JVM 테스트에서는 사용할 수 없지만 평소와 같이 이러한 테스트를 작성하지 못하게 막지는 않는다. Hilt는 안드로이드 테스트에 의존성 주입의 기능을 제공하여 테스트를 더 쉽게 만든다. Hilt는 테스트를 통해 Dagger 바인딩에 쉽게 접근하거나 더보기…

[Hilt] 5.6 Core APIs – Custom Components

https://dagger.dev/hilt/custom-components 5.6 Core APIs – Custom Components 사용자화 컴포넌트가 필요한가? Hilt는 개발자를 위해 관리되는 안드로이드용으로 미리 정의된 컴포넌트들을 가지고 있다. 하지만 표준 Hilt 컴포넌트가 객체의 생애와 맞지 않거나 특정 기능을 필요로 하는 상황들이 생기기 마련이다. 이런 경우에는 사용자화 컴포넌트가 필요하다. 그러나 사용자화 컴포넌트를 생성하기 전에 논리적으로 사용자화 컴포넌트가 반드시 필요한 더보기…