Thread
#dagger
    Colton Idle

    Colton Idle

    2 years ago
    Working on some best practices documentation for my team. Poll Do you prefer:1️⃣ field injection2️⃣ provision methods (
    @Provides
    )
    wasyl

    wasyl

    2 years ago
    I’m not sure in what context these two are alternatives, can you give an example?
    Colton Idle

    Colton Idle

    2 years ago
    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

    wasyl

    2 years ago
    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

    Colton Idle

    2 years ago
    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

    wasyl

    2 years ago
    So you mean the alternative between 1)
    @Inject lateinit var injectedProperty: SomeClass
    vs 2)
    fun onCreate() {
      this.property = Injector.get().someClass()
    ?
    ritesh

    ritesh

    2 years ago
    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.
    t

    trevjones

    2 years ago
    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

    Colton Idle

    2 years ago
    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

    2 years ago
    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

    gildor

    2 years ago
    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)