Don't keep activities

[kratos23]

Saving presenters doesn't work with enabled don't keep activities flag in developer options.

[SaeedMasoumi]

@kratos23 Can you explain more?

[kratos23]

Easy mvp use loaders to save presenters across configuration chages. But if activity had destroyed, loader had destroyed too, and we can't restore presenter. You can test it by having enabled don't keep activities in the developer options. If you turn on this option, each activity will be destroyed after closing.

[mohamad-amin]

@kratos23 So why would you expect the presenter to maintain its state when the activity is completely destroyed? I think the loader is going to somehow remove the onSavedInstanceState and onRestoreInstanceState boilerplate and in activity's lifecycle you can't recover the state after the onDestroy method is called.
If you want to save the states of an activity/etc after the onDestroy method has been called you should use other ways like SharedPreferences or something else.

[kratos23]

@mohamad-amin I understand that

loader is going to somehow remove the onSavedInstanceState and onRestoreInstanceState boilerplate

Quote from android developers about onDestory()

This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space.

I expect the presenter to maintain its state, because if we save something to bundle in void onSaveInstanceState(Bundle saveInstanceState) and close our activity using home button(it's important) with enabled don't keep activities flag in developer options, bundle in void onRestoreInstanceState(Bundle restoreState) will be not null, but presenter in our activity or fragment will be null. It means that when android framework decided to save screen state(the second case:

the system is temporarily destroying this instance of the activity to save space

system destroyed activity but not completely), EasyMVP didn't.

[mohamad-amin]

@kratos23
Yes, you're right about some cases where onDestroy is called (or sometimes even not called) and the activity gets destroyed but OnRestoreInstanceState is called with a valid bundle next time the activity starts.

But the problem here is that in these cases loaders don't cache the data and will be destroyed completely (as it is mentioned here, Loaders persist and cache results across configuration changes to prevent duplicate queries)

So I think it's ok not to support these buggy cases because EasyMVP is using loaders and loaders are not designed for these cases.

But if you really want to support these cases, you can yourself store some parameters in activity's instanceState bundle using third party libraries or implementing a BaseActivity and providing an interface between the presenter and the activity to save/restore some objects that you need to be saved in these cases.

[MikiZorzo]

@mohamad-amin could you provide a small example? Im kind of new to Android and I have a view pager with 4 tabs. I want the tabs to persist, but whenever I switch tabs or lock the phone, a new instance is created. Thanks.