Hilt quiz

Test your Hilt knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.

Why is manual dependency injection (constructing and passing dependencies by hand throughout an app) considered harder to maintain as an Android codebase grows, motivating tools like Hilt?

1. Why is manual dependency injection (constructing and passing dependencies by hand throughout an app) considered harder to maintain as an Android codebase grows, motivating tools like Hilt?
2. What does Hilt's component hierarchy (Application → Activity → Fragment/ViewModel, etc.) reflect about how Android apps are structured?
3. What kind of dependency typically requires a Hilt module with `@Provides` rather than simple constructor injection with `@Inject`?
4. What is the purpose of the `@HiltAndroidApp` annotation in a Hilt-based Android application?
5. Why is Hilt's compile-time code generation approach (as opposed to a runtime reflection-based DI approach) considered advantageous for Android specifically?
6. What does `@AndroidEntryPoint` do when applied to an Activity, Fragment, or other Android component?
7. What is a Hilt "module," typically annotated with `@Module` and `@InstallIn`?
8. What does it mean that Hilt "generates" a Dagger component hierarchy behind the scenes rather than requiring the developer to define their own top-level Dagger components manually?
9. What is Hilt's support for testing (e.g. `@HiltAndroidTest` and test-specific modules) generally used for?
10. What problem does dependency injection (DI) generally solve in application architecture?
11. What is the difference between `@Provides` and `@Binds` in a Hilt module?
12. What is a common reason Google recommends Hilt as the standard DI solution for new Android projects, rather than using raw Dagger directly?

More quizzes