https://kotlinlang.org logo
#dagger
Title
c

Colton Idle

07/31/2020, 6:59 AM
Working on some best practices documentation for my team. Poll Do you prefer: 1️⃣ field injection 2️⃣ provision methods (
@Provides
)
2️⃣ 4
1️⃣ 4
🤔 3
w

wasyl

07/31/2020, 8:42 AM
I’m not sure in what context these two are alternatives, can you give an example?
c

Colton Idle

07/31/2020, 8:54 AM
Although I know that I really shouldn't be injecting into Activities, Services, etc that's kind of my example scenario a.k.a "I can't do constructor injection, what should I do now?" I can either inject fields, or use provision methods.
w

wasyl

07/31/2020, 9:04 AM
That’s where I’m confused, how can I use
@Provides
to inject something? Aren’t
@Provides
method used to provide dependencies in modules?
c

Colton Idle

07/31/2020, 9:07 AM
https://medium.com/@Zhuinden/that-missing-guide-how-to-use-dagger2-ef116fbea97
Personally I think that field injection scales rather badly, so I prefer to put in a provision method for every dependency I need, and then pass my component around. So it looks like this.
@wasyl I'm still learning so I also don't really know exactly what I'm talking about, but a @Provides method goes into a module, and then is referenced in a component so that a component can use it when needed.
w

wasyl

07/31/2020, 9:09 AM
So you mean the alternative between 1)
Copy code
@Inject lateinit var injectedProperty: SomeClass
vs 2)
Copy code
fun onCreate() {
  this.property = Injector.get().someClass()
?
r

ritesh

07/31/2020, 10:16 AM
For dependencies to be added in the in dagger-graph, i wont go for @provides. unless required. I mostly stick with constructor injection. How you inject it, using filed injection or anything. It doesnt really matter.
1
t

trevjones

07/31/2020, 3:38 PM
I’d take
@Inject
over the component being passed around every time. by using component methods you lose the clear list at the top of a file of “this is what I need to work” and you also couple yourself to the component interface which has an intrinsic implementation so it can cause you to lose a good inversion of control (unless it is an interface that itself isn’t a component, or it is a subcomponent for which you have multiple implementations generated, ie one for scenario a, one for b and one for test, etc…) I expect long term maintenance is likely going to be lower with field injection as well due to the compiler doing more of that upkeep for you.
c

Colton Idle

08/01/2020, 1:47 AM
Thanks for all of the interesting insight. It doesn't seem like there's a clear winner here. I do agree with the article I posted above of "Personally I think that field injection scales rather badly, so I prefer to put in a provision method for every dependency I need, and then pass my component around. So it looks like this."
t

trevjones

08/01/2020, 2:18 AM
main problem IMO with Zhuinden’s cute example blog is the lack of inversion of control at the injector lookup. the whole point of DI in my mind is to not know where you dependencies come from so you can more easily do things like….. testing. its a magical thing to just start an activity run some test steps and kill it. even in just an aar project. but I am just a stranger on the internet, not the one yelling into it 😉 everyone like to complain about dagger-android, but IMO the only thing they got wrong was not making it obvious that you don’t have to use their base classes that dictate how the service location of your injector works. you throw those out and do it on your own, then using
@Contrib
to cut down the code you have to write and it is actually a really great system to work with. so we really only needed the
@Contrib
+ processor +
AndroidInjector<T>
and really it could be
PlatformInjector<T>
at that point. nothing android specific is left.
g

gildor

08/01/2020, 2:52 AM
I think that both ways: inject() method and provision method in interface (excluding case for component dependencies of course) are bad if you have only one single component, and exposing provision method for every dependency (sic!) is the worst I'm completely agree with Trevor, dagger-android approach is better and much more scalable (especially with @ContribAndroidInjector)
❤️ 1
5 Views