-
Notifications
You must be signed in to change notification settings - Fork 101
Presenters cannot restore instance state after process has died #39
Comments
ThirtyInch can nothing do against process death and has no APIs to restore the state. It was developed by assuming that the process rarely gets killed which is true for modern phones. savedInstanceStateYou can save the state of the presenter in public class MyActivity extends TiActivity<MyPresenter, MyView> implements MyView {
// make it accessible in providePresenter()
private Bundle mSavedInstanceState = null;
@Override
protected void onCreate(final Bundle savedInstanceState) {
mSavedInstanceState = savedInstanceState;
super.onCreate(savedInstanceState);
}
@Override
protected void onSaveInstanceState(final Bundle outState) {
super.onSaveInstanceState(outState);
// using a byte[] here because the presenter should have zero Android dependencies
// Bundle is hard to mock
outState.putByteArray("presenterState", getPresenter().getPersistentState());
}
@NonNull
@Override
public MyPresenter providePresenter() {
// called when the presenter gets first created and
// when the presenter gets created after a process death
byte[] persistentState = null;
if (mSavedInstanceState != null) {
persistentState = mSavedInstanceState.getByteArray("presenterState");
}
return new MyPresenter(persistentState);
}
} app storageYou should really think about your usecase. Often it is not useful to restore a state when the Activity was in background for days. Another solution is to manually save the state as file in the app directory. Or in the SharedPreferences. It could be good practice to also save the timestamp and check if the state is still relevant in the current situation. |
this also could happen in Activity B where it crashed, then activity A (MainActivity) is now being recreated. |
Would you be open for a PR? I have a working solution which looks roughly like this
For recreating the state I see two options. The first would be changing
That's nothing complicated, but would be a nice addition. (I also saw the other issue where someone needs to store the webview state in a bundle, this would fix this issue probably, too) |
@vRallev I fear that the Having a complete standalone way to save the state is much more flexible. It would allow us to have a maximum of X active Presenters while the others will be killed (and save state). Another idea would be to kill all Presenters when the App has been moved to background after X Seconds. So many possibilities which aren't possible when we rely on Nothing has been decided yet and I'd be happy to get more feedback from people like you. Anyways, it's open source and you have all rights to maintain you own fork which could be integrated once a decision has been made. |
I really love seeing what @vRallev suggested, this will save us loads of stuff to do on the activity/fragment, imagine we are saving some state of an expensive API call in the presenter, the activity is being recreated due to some activity in the backstack is being crashed, now the whole activities are being recreated and the presenter lost its state & data. i really appreciate your effort on making this possible @vRallev & @passsy |
@passsy any news about this? |
Work started based on #50. Not finished yet but you can have a look: |
@passsy You might want to create another PR even if it's WIP. I already have a few comments. |
cool, i'm looking forward for it. |
It looks like there's no good way to restore the instance state of a Presenter in ThirtyInch when the process is killed and restarted.
The PresenterSavior handles the case when the process is NOT killed by essentially holding a static map of Presenters, but this map will get cleared when the process dies and the Activity gets restored.
This can be reproduced by running the sample code and taking the following steps:
After following the steps you can see in the logs
11-13 05:49:47.407 909 909 I ThirtyInch: HelloWorldActivity:TiActivity@9cbcc1d: could not recover the Presenter although it's not the first start of the Activity. This is normal when configured as .setRetainPresenterEnabled(false).
As far as I understand setRetainPresenterEnabled is true by default and no one sets it in the sample code.
Is this an oversight or is there a recommended way to take care of this case?
The text was updated successfully, but these errors were encountered: