Definicja #
Dagger (aktualnie Dagger 2) to framework Dependency Injection (DI) dla Javy i Kotlina, oparty na generowaniu kodu w czasie kompilacji (annotation processor). W przeciwieństwie do frameworków refleksyjnych (Spring, Guice), Dagger generuje konkretny kod Java/Kotlin podczas kompilacji — błędy konfiguracji DI są wykrywane w compile-time, nie runtime.
Kluczowe koncepty: @Inject (oznaczenie zależności), @Module (provider zależności), @Component (graf zależności łączący konsumentów z providerami), @Scope (cykl życia obiektów — Singleton, ActivityScope). Subcomponents pozwalają na hierarchiczne zakresy.
Hilt to oficjalna nakładka Google na Dagger, upraszczająca konfigurację dla Androida — predefiniowane komponenty (SingletonComponent, ActivityComponent, ViewModelComponent) i automatyczna integracja z cyklem życia Androida. Hilt jest rekomendowanym podejściem dla nowych projektów Android.
Zastosowania #
- Wstrzykiwanie zależności w aplikacjach Android (Hilt jako oficjalne rekomendowane rozwiązanie)
- Zarządzanie cyklem życia obiektów — Singleton, per-Activity, per-Fragment
- Testowanie — łatwa podmiana implementacji na mocki przez moduły testowe
- Wielomodułowe projekty Android — Dagger subcomponents dla feature modułów
- Projekty Java backend (starsze) — Dagger jako alternatywa dla Spring DI
Ścieżka nauki #
Dla developerów Android naukę DI warto zacząć od Hilt zamiast bezpośrednio od Dagger 2 — jest prostszy i ma pełne wsparcie Google. Oficjalny kurs Hilt: developer.android.com/training/dependency-injection/hilt-android.
Kluczowe zagadnienia: @HiltAndroidApp, @AndroidEntryPoint, @Inject, @HiltViewModel, definiowanie modułów (@Module, @Provides, @Binds). Warto też rozumieć czym Hilt różni się od Dagger 2 i kiedy sięgnąć po Dagger bezpośrednio (multi-moduł, specyficzne zakresy). Alternatywa: Koin — czysty Kotlin DI framework, prostszy niż Dagger, ale wolniejszy (runtime DSL). Praktyczne ćwiczenie: refaktoryzacja aplikacji Android z manualnego DI na Hilt.
FAQ #
- Czym różni się Dagger od Hilt?
- Hilt to nakładka na Dagger 2 stworzona przez Google specjalnie dla Androida — upraszcza konfigurację przez predefiniowane komponenty i automatyczną integrację z cyklem życia Androida. Dagger 2 to ogólny framework DI dla Java/Kotlin wymagający ręcznej konfiguracji komponentów. Dla nowych projektów Android Google rekomenduje Hilt.
- Dlaczego Dagger generuje kod w compile-time?
- Generowanie kodu w compile-time (przez annotation processor) ma dwie korzyści: błędy konfiguracji DI są wykrywane podczas kompilacji (nie w runtime), a wygenerowany kod jest tak samo wydajny jak ręcznie napisany (brak refleksji). To ważne szczególnie na Androidzie, gdzie wydajność ma duże znaczenie.
- Dagger czy Koin — co wybrać?
- Dagger/Hilt: bezpieczny compile-time, wydajny, rekomendowany przez Google, bardziej złożony w konfiguracji. Koin: prostszy w nauce, DSL Kotlin, runtime (wolniejszy, błędy w runtime), dobry dla mniejszych projektów. W dużych projektach Android Hilt jest standardem; Koin popularny w KMM (Kotlin Multiplatform).
- Czy Dagger 2 jest używany poza Androidem?
- Tak, ale rzadko — w środowiskach Java backend dominuje Spring (który ma własny kontener DI). Dagger 2 na backendzie pojawia się głównie w projektach Google (np. Bazel) lub gdy zależy na compile-time safety bez Spring. W praktyce Dagger jest silnie kojarzony z ekosystemem Android.