Presenter lifecycle tied to Activity's

[cxzhang2]

Hi guys,

It looks to me as though the presenters' lifecycles are coupled to their instantiating activity's. Please let me know if I missed something, and whether or not this is a conscious design choice.

Thank you!

[IgorGanapolsky]

@cxzhang2 What is your other proposal? Presenters need to be notified during activity lifecycle changes...

[cxzhang2]

@IgorGanapolsky

Sorry, clarification:

As you said, presenters should be notified of activity / fragment lifecycle events, but they should also survive configuration change.

I have seen so far two general approaches to this problem (there are also external libraries that are explicitly for this purpose but I'm not too familiar with them):

1. With a custom singleton to hold and manage presenters. This example uses an actual singleton, and this example uses the NonConfigurationInstance of an activity.
2. With dagger @subcomponents, as illustrated here

As far as I can tell, the presenters in this project are destroyed and re-instantiated on configuration change. Just wondering if I'm missing something or maybe this is a special case where such considerations do not apply.

Thanks!

[kboyarshinov]

@cxzhang2 Yes, presenters are re-instantiated on every configuration change. There was no purpose to make them survive it initially. You can expose onSaveState and onRestoreState callbacks to save presenters state if you want.
Btw second example you mentioned with dagger subcomponents re-instantiates presenter too. Each time subcomponent is build QualityMattersApp.get(getContext()).applicationComponent().plus(new ItemsFragmentModule()).inject(this) new presenter is injected in fragment.

[cxzhang2]

Thank you @kboyarshinov , and yes you are right about the second example. I originally thought that Instances of parent components held references to instances of subcomponents. Thinking about this now it makes no sense in terms of scoping. Doh.