Powering up Dagger for Less Code and Cleaner Architecture
summary
Explains that Dagger compiles into real Java objects that generate factory provider classes and a component object that owns all bindings and their lifecycles, shows how @Binds removes boilerplate while multibinding assembles sets and maps at runtime, and demonstrates using scopes and subcomponents to swap graphs for signed‑in vs signed‑out experiences. Warns that re‑instantiating components leaks memory and breaks singletons, and points to Dagger SPIs for custom compile‑time graph checks.
AI-written summary · about
chapters (9)
- 0:00Introduction to Dagger
- 3:38How Dagger magic works
- 12:21Understanding bindings
- 15:31Multibindings for flexible architecture
- 17:57Scoping dependencies in Dagger
- 21:10State-specific experiences with scopes
- 23:16Subcomponents for shared dependencies
- 26:45When not to overuse Dagger
- 29:56Closing and key takeaways
related talks
45mDagger 2 - Back to Basics
48mDemystifying Dagger
38mDagger 2, 2 Years Later
29mForging the Dagger for the modern Android world
41mOptimizing Dagger on Android: Developer Workflow and Runtime Performance
40mFundamentals of Dependency Injection
25mDagger 2 Android : Defeat the Dahaka
27mUsing Dagger2 to Keep Android SDK Dependencies Clean