android
[todo-mvp-dagger] dropView method in Presenter
In presenters we have the dropView() method which sets the corresponding view to null. Is it possible that in two Fragments (of the same class) the same Presenter will be provided? And then, when one of the fragments will be destroyed, the dropView() call will cause the presenter to loose the connection with the newly created fragment. To prevent that, we could pass the view in dropView(view) and then check if it is that very view that Presenter actually holds like that:
dropView(MainContract.View view) {
if (mView == view) mView = null;
}
So, my question actually can be rephrased whether it is possible that two fragments of the same class could get the same instance of Presenter by dagger and if not - why that situation could not happen?
Can two fragments get the same Presenter instance? It depends entirely on how the Presenter is scoped in Dagger:
If Presenter is unscoped (default in Dagger): Every @Inject creates a new instance → Two fragments (even of the same class) will each get their own presenter.
If Presenter is scoped to a component that lives longer than the fragment (e.g., @Singleton or @ActivityScope while fragments are recreated inside the same activity): Then yes, multiple fragment instances could share the same presenter.
Why does dropView() just set mView = null? In the Google samples, the presenters are typically scoped to the lifecycle of the View (fragment or activity). This means:
When the fragment is destroyed, so is its presenter.
There’s no risk of a new fragment reusing the same presenter instance.
What if they share a presenter accidentally? If you scope the presenter too widely (e.g., @Singleton), then:
Fragment A is destroyed → dropView() sets mView = null
Fragment B (same class) is now active → but Presenter has lost its reference
That’s the bug you’re describing.
How to protect against it? Your proposed approach works:
t void dropView(MainContract.View view) { if (mView == view) { mView = null; } } This ensures that only the fragment that originally attached is the one detaching.
Why the Google sample doesn’t do this Because in the sample:
Each fragment gets its own presenter instance via unscoped or fragment-scoped injection.
Therefore, this collision scenario cannot happen unless the developer changes the Dagger scope. Summary Default sample behavior → Each fragment gets a new presenter → No collision
If presenter is shared via a larger scope → Yes, your safety check is valid
Best practice → Keep presenters scoped to the View’s lifecycle to avoid shared-state issues
