`Bridge.clear(this)` called during `onDestroy` is erasing the saved data.

[Elye]

In the document, it recommends to use Bridge.clear(this) during onDestroy.

    @Override
    public void onDestroy() {
        super.onDestroy();
        Bridge.clear(this);
    }

I tried it, and it clear the saved data as onDestroy is called when the system kill the Activity. So when restoring, the saved data is no longer available.

[Brian Yencho]

Can you be a bit more explicit on the exact scenario you are talking about? For a standard Activity / Fragment, onDestroy should only only be called under two main scenarios:

1. The app is undergoing a configuration changes, like a rotation. Bridge detects this and does nothing in these cases to ensure the saved state data isn't accidentally removed.
2. The Activity is "finishing" (i.e. finish() was manually called somewhere.) Bridge will clear the saved data for this screen because it is no longer needed.

Note that these cases are alluded to in the documentation on the README:

This method is typically safe to call without any additional logic, as it will only clear data when the current Activity is not undergoing a configuration change. Note that in some unique cases (such as when using a FragmentStatePagerAdapter) the OS will "destroy" a Fragment but retain its saved state Bundle in case it needs to reconstruct that Fragment from scratch later. In these cases calls to Bridge.clear() should be omitted.

As far as I know, onDestroy should not be called when the app is simply backgrounded and is killed by OS for memory reasons. Do you have logs to show that has happened in your case?

I'll note that your article talks about how the saved state data saved in SharedPreferences keeps accumulating, but the whole reason to call Bridge.clear(this) is to make sure that doesn't happen. The data is also cleared the first time the app is started killed and restarted normally (rather than being killed by the OS).

[Brian Yencho]

Are you testing with "Don't Keep Activites" on? If so that's going to give you misleading results. It's similar to---but not the same as---the OS killing the app. If so, you should test with something like this instead : https://github.com/livefront/process-killer-android

[Elye]

There's no guaranteed that onDestroy will not be called when the system kills the activity and fragment. The document stated https://developer.android.com/reference/android/app/Activity#onDestroy%28%29

The final call you receive before your activity is destroyed. 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. You can distinguish between these two scenarios with the isFinishing() method.

Perhaps we should consider using isFinishing for checking it

    @Override
    public void onDestroy() {
        super.onDestroy();
       if (isFinishing()) Bridge.clear(this);
    }

But this only works for activity, and not fragment :(

[Brian Yencho]

@elye Yeah, I had some thoughts about how I could make this work where internally we check if there is a host Activity with onDestroy called but where isFinishing() is not true; if so, just ignore all clear events during this time. This is similar to how we ignore clear() calls during configuration changes and could replace the logic used for that as well. So I'll look into making an update for this to be on the safe side of things.

However, again I'll point out that I don't think I've ever once seen onDestroy called as a result of the OS killing an application. I could be wrong about this but I have a feeling that the docs for onDestroy are just out of date. So back to my original question : have you actually seen onDestroy being called when the OS kills an application? Do you have an logs for this? (And again, this needs to be tested with "Don't Keep Activities" off since I think that does call onDestroy but doesn't actually mimic a real user scenario).

[Brian Yencho]

@elye The new release should fix this issue.

[Brian Yencho]

@elye I'm going to close this issue now. If you still seem to have problems, feel free to re-open it.