Dagger: Injection not working from within super class.

Created on 13 Jan 2015  路  10Comments  路  Source: google/dagger

In the android-simple example a parent class (https://github.com/google/dagger/blob/master/examples/android-simple/src/main/java/com/example/dagger/simple/DemoActivity.java) is doing the injection and the children class (https://github.com/google/dagger/blob/master/examples/android-simple/src/main/java/com/example/dagger/simple/ui/HomeActivity.java) is expected to de injected after the call to super.

It does not seem to work as the inject method from the component called is the one from the parent class skipping any member injection for the child class.

bug

Most helpful comment

@gk5885 Now both #73 and #102 are closed. Where do we further discuss this issue?

All 10 comments

Yep, always faced it, but somehow blindly accepted it.

Worth mentioning, that in Child->Parent direction it works. In your component you only need inject(ChildActivity). Then, you can call inject from child activity only and parent activity's fields would also be injected.

Samples: ChildActivity and ParentActivity and Component

@mgrzechocinski Yeah it works fine on the Child -> Parent direction.
Unfortunately I find the Parent -> Child situation a lot more common (ie Parent Activity define Injection and Children can use the @Inject if needed.)

I'm now using the Parent Activity as a hub and provide accessors to the injected fields. It seems to be the less boilerplate I can find for that situation.

In the short term if this cannot be resolved the example should be changed as it is not working.

This is an old thing from Dagger 1...

My dirty solution: use some static DIContainer inner class in super class which holds injected things required for children.

But it will be great if issue will be resolved

This is a dupe of #73

@Dorvaryn I expose an protected abstract Inject() method on the parent which the child has to implement, this is to encourage the correct implementation in your children.

I guess there could be a warning here?

We'll take a look at the examples - it's entirely possible that it's not a valid example anymore, as it was raw-ported without a lot of thought.

You're right, this solution is quick and dirty just to show how this could be done. It does not throw informative exceptions and does not have tests. Naming and architecture could be better.

IIUC, @tbroyer was correct and that this is a dup. So, I think we can just call this closed.

@gk5885 Now both #73 and #102 are closed. Where do we further discuss this issue?

Was this page helpful?
0 / 5 - 0 ratings