# dagger-android Published articles for dagger-android. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From Dagger to Metro DevFeed: [From Dagger to Metro]() Original publisher: [Read original article]() Author: Andrius Semionovas Published: 2026-02-12T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Dagger](), [dagger-hilt](), [Kotlin]() Tags: [android](), [anvil](), [dagger](), [dagger-android](), [dependency-injection](), [di](), [hilt](), [kotlin](), [metro](), [migration]() ### AI overview Vinted migrated its Android codebase, spanning a few hundred Gradle modules, from Dagger and Anvil to Metro as Anvil's Kotlin compiler plugin support left the team on Kotlin 1.9/K1 without incremental compilation while Kotlin 2.x and K2 adoption became pressing. The excerpt presents Metro's interoperability with Dagger, Anvil, and kotlin-inject as the key migration advantage: it let the team adopt K2 with less business-code migration than other options, reducing the time and risk of the change. The account describes the migration as bumpy; the excerpt does not provide its implementation steps or full results. ### Source excerpt Metro - modern and kotlin injection framework created by Zac Sweers. And we, Android developers at Vinted, officially and fully migrated to it! It was quite a bumpy ride for our huge codebase. Our story begins... ## Dagger Tips: Guide to using Dagger-Android effectively DevFeed: [Dagger Tips: Guide to using Dagger-Android effectively]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2021-02-13T05:05:50Z Content type: article Language: en Sources: [Gabor Varadi]() Topics: [Dagger](), [Dependency injection](), [dagger-hilt](), [software-architecture](), [software-development]() Tags: [android](), [dagger](), [dagger-2](), [dagger-android](), [dependency-injection](), [fragment](), [hilt](), [modularization](), [module](), [scalability](), [type-safe](), [viewmodel](), [worker]() ### AI overview Dagger-Android uses map multibinding to dispatch field injection when feature modules cannot call inject on an application component directly. With AndroidInjectionModule and @ContributesAndroidInjector, Dagger generates injector factories; DispatchingAndroidInjector looks up a factory by the target class, creates an injector, and injects the instance. For maintainability, the excerpt recommends defining a module per screen, aggregating screen modules within each feature module, then including feature aggregates in the app component, instead of collecting all screens in global activity, fragment, and ViewModel modules. Dagger-Android is superseded by Hilt, which handles common Android types through @AndroidEntryPoint, @HiltViewModel, and @HiltWorker; the article frames Dagger-Android's dynamic injection as mainly useful for legacy or modularized cases. The text is an excerpt, so it may not cover the article in full. ### Source excerpt Something people could ask me as they're reading this title: "Hold on a second, isn't Dagger-Android no longer in active development? Isn't it made obsolete with the introduction of Hilt?" Technically, yes. Dagger-Android is superseded by Hilt. So there is a good chance that if you are already using Hilt, then for the most common cases (injecting Activity, Fragment, ViewModel, Worker), you don't need to think about Dagger-Android whatsoever. However, as I still see @ContributesAndroidInjector popping up every now and then, I feel that it's best if I write an article on how it works, what it intended to solve, how to use it, and how NOT to use it (for better scalability). What was Dagger-Android? Dagger-Android was a way to field-inject classes (not necessarily just Android classes since Dagger 2.20+) without having to define a fun inject(target: MyConcreteClassTarget) injector method on the component -- as we don't know the class itself. When do you want to avoid creating fun inject(t: T) in a component? After all, this is what normally allows field injection to be type-safe. The answer is, when you can't. If you use a modularization pattern where :app contains the ApplicationComponent(or SingletonComponent), then while ApplicationComponent can see any Activity or Fragment within the app, the submodules don't see :app and therefore don't see ApplicationComponent. Therefore, they can't call component.inject(this)! On the other hand, if you were to define an Application.ActivityLifecycleCallbacks to do it automatically, that wouldn't work with the standard approach -- as you see only the superclass, but not the concrete class! So if one wants to use field injection with our provided restrictions, there are two options: Expose an interface from the child module that defines the injection targets, and implement that on the ApplicationComponent -- then make it possible to access it (for example, using the ApplicationContext for lookup) and cast it to the interface to be abl