[Hilt] 컴파일 타임에 @InstallIn 체크 무시하기

Hilt를 사용할 경우 모듈 클래스에 반드시 @InstallIn을 추가해야 한다. 그렇지 않으면 컴파일 타임에 오류가 발생한다. 하지만 Dagger2에서 Hilt로 마이그레이션을 하거나 특별한 사유가 있는 경우 모든 모듈 클래스에 @InstallIn을 추가하기 어려운 경우가 있다. 이때 다음 예제코드 처럼, 해당 모듈의 그레이들 스크립트에 disableModulesHaveInstallInCheck 옵션을 추가 할 수 있다. gradle 명령어를 사용하여 컴파일(빌드)하는 더보기…

Dagger2를 알아보자 – Dynamic Feature Module에 적용하기

Dagger2를 알아보자 – 기본편 Dagger2를 알아보자 – Scope  Dagger2를 알아보자 – Injection의 종류  Dagger2를 알아보자 – Qualifier  Dagger2를 알아보자 – Binding  Dagger2를 알아보자 – Multibinding  Dagger2를 알아보자 – SubComponent  Dagger2를 알아보자 – Android Dagger2를 알아보자 – Testing(준비중) Dagger2를 알아보자 – Dynamic Feature에 적용하기(You’re here) Dynamic Feature Module에 Dagger 적용하기 위의 더보기…

글쓴이 Charlezz,

[Hilt] 공식 문서 번역본

https://dagger.dev/hilt/ Hilt 공식 문서를 번역한 내용입니다 Hilt 공식 문서 번역본 v1.1 by Charlezz 안녕하세요. 찰스입니다. 패스트캠퍼스와 함께 안드로이드 의존성 주입 강의를 제작했습니다. [Android 의존성 주입 완전정복 : Hilt로 확장성 높은 앱 완성하기] 강의 링크 : https://abit.ly/zaylhy Hilt 도입 단계, 혹은 사용을 고려하는 개발자를 위해 만든 실전 프로젝트형 강의로 의존성 주입에 대한 더보기…

[Hilt] 10.4 Design Decisions – 서브 컴포넌트 vs 컴포넌트 의존성

https://dagger.dev/hilt/subcomponents-vs-deps 10.4 Design Decisions – Subcomponents vs Component dependencies 개요 Hilt는 컴포넌트 의존성과 대조적으로 Dagger의 서브컴포넌트를 기본적으로 사용한다. 이 페이지에서는 Hilt가 왜 이러한 방식으로 설계되었는지 설명한다. 단일 바인딩 키 공간 서브 컴포넌트는 기본적으로 모든 바인딩을 전파한다. 여기에는 컴포넌트 의존성을 통해 전파하기 어려운 멀티 바인딩도 포함된다. 멀티 바인딩은 병합된 바인딩 키 더보기…

[Hilt] 10.3 Design Decisions – 단일 컴포넌트

https://dagger.dev/hilt/monolithic 10.3 Design Decisions – Monolithic Components 개요 Hilt는 단일 컴포넌트 체제를 사용한다. 이것이 의미하는 점은 모든 Activity 클래스들에 의존성 주입을 하는 것에 대해 단일 Activity 컴포넌트의 정의가 사용된다는 것이다. Fragment와 다른 안드로이드 타입들도 같은 맥락이다. 각 Activity는 분리된 컴포넌트 인스턴스를 갖지만, 정의된 컴포넌트 클래스는 공용된다. 이는 각 Activity가 분리된 더보기…

글쓴이 Charlezz,

[Hilt] 10.2 Design Decisions – 테스트 철학

https://dagger.dev/hilt/testing-philosophy 10.2 Design Decisions – Testing Philosophy 개요 이 페이지는 Hilt를 사용하는 테스트 사례를 설명하는 것을 목표로 한다. Hilt의 많은 API와 기능 ( 그리고 특정 기능의 부족함)은 좋은 테스트를 만드는 것에 대한 무언의 철학을 바탕으로 만들어졌다. 좋은 테스트의 개념은 보편적으로 합의 된 것은 아니기 때문에 이 문서는 Hilt 팀의 테스트 더보기…

글쓴이 Charlezz,

[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가 해당 모듈을 챙기지 못해 디버깅을 어렵게 만들 수 있다. 이런 검사는 때로는 지나치게 광범위 할 수 있다. 특히 마이그레이션 진행중이라면 말이다. 이러한 더보기…

글쓴이 Charlezz,

[Hilt] 7.3 Migration – 스코프 별칭

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

글쓴이 Charlezz,