Working on some best practices documentation for m...

# dagger

[Colton Idle]

Working on some best practices documentation for my team.

Poll

Do you prefer:
1️⃣ field injection
2️⃣ provision methods (@Provides)

[wasyl]

I’m not sure in what context these two are alternatives, can you give an example?

[Colton Idle]

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.

[wasyl]

That’s where I’m confused, how can I use @Provides to inject something? Aren’t @Provides method used to provide dependencies in modules?

[Colton Idle]

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.

[wasyl]

So you mean the alternative between
1)

@Inject lateinit var injectedProperty: SomeClass

vs 2)

fun onCreate() {
  this.property = Injector.get().someClass()

?

[ritesh]

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.

[trevjones]

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.

[Colton Idle]

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."

[trevjones]

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.

[gildor]

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)