BookNest DI

Wiring Dependency Injection into BookNest

Moving BookNest to Hilt changed no screen. BookRepository became an interface implemented by AssetBookRepository, which Room 234 and Retrofit 43,944 can replace later; the rest is the annotations and module shown above, and CatalogViewModel.Factory is gone.

The repository logs its identity hash when created, and each consumer logs the instance it received. A cold start, then a rotation:

Output of 141
D/BookNestDI: AssetBookRepository created #5f58670
D/BookNestVM: MainActivity onCreate, restored=false
D/BookNestDI: MainActivity got repository #5f58670
D/BookNestVM: CartViewModel created, cart=[]
D/BookNestVM: CatalogViewModel created
D/BookNestDI: CatalogViewModel got repository #5f58670
...
D/BookNestVM: MainActivity onCreate, restored=true
D/BookNestDI: MainActivity got repository #5f58670

One repository serves the activity and the ViewModel, and the recreated activity received the same #5f58670, while the ViewModels survived untouched. Without @Singleton, each would get its own repository: harmless here, a real bug for a database or a cache.

Hilt costs build time: four tasks (kspDebugKotlin, hiltCollectClassesDebug, hiltAggregateDepsDebug, hiltJavaCompileDebug) join every build. The first build with Hilt, the failing one in Hilt vs Koin, ran 6 minutes 22 seconds on a busy four-core machine; the fixed rebuild, unit tests included, took 1 minute 29.