Dagger2 scopes and activity lifecycle

Question

I have an Android Activity that I\'m using Dagger2 to inject a Presenter into. I\'d like my Presenter to be capable of holding state even if a configuration change occurs.

Answer 1

According to this article about Custom Scopes:

http://frogermcs.github.io/dependency-injection-with-dagger-2-custom-scopes/

In short - scopes give us “local singletons” which live as long as scope itself.

Just to be clear - there are no @ActivityScope or @ApplicationScope annotations provided by default in Dagger 2. It’s just most common usage of custom scopes. Only @Singleton scope is available by default (provided by Java itself), and the point is using a scope is not enough(!) and you have to take care of component that contains that scope. This mean keeping a reference to it inside Application class and reuse it when Activity changes.

public class GithubClientApplication extends Application {

    private AppComponent appComponent;
    private UserComponent userComponent;

    //...

    public UserComponent createUserComponent(User user) {
        userComponent = appComponent.plus(new UserModule(user));
        return userComponent;
    }

    public void releaseUserComponent() {
        userComponent = null;
    }

    //...
}

You can take a look at this sample project:

http://github.com/mmirhoseini/marvel

and this article:

https://hackernoon.com/yet-another-mvp-article-part-1-lets-get-to-know-the-project-d3fd553b3e21

to get more familiar with MVP and learn how dagger scope works.

Answer 2

I would strongly advice against trying to implement this approach.

You're effectively trying to use DI framework in order to support Activity specific life-cycle flow, although DI frameworks are not intended to be used like this.

I recently answered another similar question in which OP tried to share state in View-Model between different Activities. Although use cases are not identical, the general pattern is the same - attempt to delegate flow control responsibilities to DI framework, which is not a good idea.

The best approach in your case (IMHO) would be to store the current state before rotation, re-instantiate the presenter upon rotation, and then restore its state.

How you store the state during rotation depends on what exactly you're trying to preserve:

• If you need to preserve UI related state (selections, texts, position of elements, etc.) then you can use the usual onSaveInstanceState() and onRestoreInstanceState() callbacks
• If you need to preserve some business related state (ongoing network requests, data, data modifications, etc.) then encapsulate this logic in a business class (e.g. SomeBusinessUseCaseManager) and inject this class from Application wide component with a scope.

You can find a detailed review of Dagger's scopes here.

More information about DI in Android can be found here.