search

6thsolution / EasyMVP

A full-featured framework that allows building android applications following the principles of Clean Architecture.
http://6thsolution.github.io/EasyMVP
Apache License 2.0
1.3k stars 129 forks source link

Don't keep activities #25

Closed k4k7us23 closed 3 months ago

k4k7us23 commented 7 years ago

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

SaeedMasoumi commented 7 years ago

@kratos23 Can you explain more?

k4k7us23 commented 7 years ago

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 commented 7 years ago

@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.

k4k7us23 commented 7 years ago

@mohamad-amin I understand that

loader is going to somehow remove the onSavedInstanceState and onRestoreInstanceState boilerplate

Quote from [android developers](https://developer.android.com/reference/android/app/Activity.html#onDestroy()) 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 commented 7 years ago

@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 commented 6 years ago

@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.