Allow the Store to handle process death.

[CodyEngel]

Since Android is unpredictable it would probably be a good idea to allow the Store to survive process death: https://medium.com/inloop/android-process-kill-and-the-big-implications-for-your-app-1ecbed4921cb

Currently device rotation works fine, however if the application is killed and you return none of the data remains, even worse if you are in an area of the app expecting data to be there the application will crash.

There are a few options out there:

1. Allow each responder notify the model when the activity has been paused, at that time the developer can decide if they need to persist that model through process death (as in they should store the data on disk).
2. Handle this automatically for the developer, this can be done through the Application class and registering ActivityLifecycleCallbacks to notify the Store of changes in the application state.

In either case these are the important callbacks in order of when they are called:

1. onActivityPaused
2. onActivitySaveInstanceState
3. onActivityStopped
4. onTrimMemory

onActivitySaveInstanceState would probably make the most sense since that's traditionally where you would want to save state.

[Zhuinden]

You can see in HelloFlax that if you put app in background and terminate, then the integer gets cleared.

But that disobeys Activity contract. Some libraries claim handling process death is unnecessary, but they've clearly never used an Android phone to take a screenshot and share it through Skype.

[CodyEngel]

Thanks @Zhuinden, as this issue outlines that's something which is going to be addressed better in a future release.

[Zhuinden]

Yes I know, I just figured I'd mention a real life use-case that bugs the hell out of me, ain't that right Pokemon Go restarting and then i lose my eevee 🌪️