Dagger: How about activity's retained scope with dagger.android ?

[oldergod]

In Android, an activity is destroyed and recreated on every configuration change. One common pattern to hold certain injected fields over this process is to instantiate a component inside the activity the first time it gets created and then to use Activity#onRetainNonConfigurationInstance to return a dagger component that would be accessible on the same newly created activity. By doing so, the component's lifecycle is now bound to the activity's _real_ lifecycle, i.e. ignoring configuration changes.

I feel the two problems dagger.android was meant to address―boilerplate code and "a class shouldn’t know anything about how it is injected"―also apply to this pattern.

I don't know if this question has already been taken into consideration. This is, in my case, a showstopper when I considered using the new AndroidInjector. I also don't have any proposition for good APIs but I thought it would be worth looking into it.
Is it something we could expect from the future releases?

[ronshapiro]

The main problem with retaining an instance of one of these components is that many graphs have a binding for the Activity itself. This is bound to be a source of leaked activities, plus you could bindings that depend on the previous Activity instance which are just totally wrong.

What exactly do you want/need to retain from your component when an activity goes through configuration change? Should those bindings perhaps be scoped differently?

[oldergod]

I have an in-the-middle component to avoid leaks.

@Singleton AppComponent > @ScreenScope ScreenComponent > @ActivityScope ActivityComponent

The screen component is created inside the Activity only once at the very beginning and is retained as explained above. It contains data about the state of the View but has no reference to it, @ScreenScope.
The activity component is created on every new instance of Activity. It injects everything bound to the activity: adapters, presenters, etc, all @ActivityScope. The activity then uses the state from the screen component to rebuild itself.

[ashdavies]

I'm trying to find a solution that facilitates persistence through orientation change with components, one idea I had was similar to what @oldergod mentioned, but it'd be nice to be able to use an Android component capable of acting as a dispatcher in the same way that a fragment component can be a subcomponent of it's parent activity component rather than the application

[ronshapiro]

@oldergod you could implement HasActivityInjector yourself and return screenComponent.activityComponent().

Have you benchmarked any of this? Are you sure that this intermediate component is saving time?

[oldergod]

Ron, thanks for the tip, I will have a look at it then.

Although I did not benchmark it because my goal is not here to save time. I don't think it Is the goal of the AndroidInjector either, is it?
I just want to hold needed data for an activity's functional lifecycle for the shortest period of time.

[oldergod]

I guess the recently announced Android Architecture Components is the right solution.