Restoring Crosswalk App after OS kill

[Andrea_C_]

Dear ones,

I have built an app that has many panels with XDK. Suppose an user leaves the app for a while, maybe takes a picture and later wants to use again my app. What can happen is that the app can be killed by Android because of the way Android it works.

On real apps (not webviews), we can implement :

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState); // Always call the superclass first
   
    // Check whether we're recreating a previously destroyed instance
    if (savedInstanceState != null) {
        // Restore value of members from saved state
        mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
        mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
    } else {
        // Probably initialize members with default values for a new instance
    }
    ...
}

Is there a way on XDK/Cordova to implement such a thing in order to restore the state of my app?

Notice that the pause/resume callbacks on Cordova most probably don't solve my problem since they assume the app is not killed.

Regards.

[Stan_W_]

Hello,

I have the same problem and I'd love to get some tips how to solve this issue. Currently every time I leave my app and come back, my XWalk view reloads. I loose form data, scroll position and so on. Is there a way to prevent loosing state and shorten loading time when coming back to app with XWalk view?

Side note: to prevent "leaked IntentReceiver" errors in my Activity I must call appView.loadUrl('about:blank') and appView.handleDestroy() in onDestroy function. Maybe this is part of a problem.

[PaulF_IntelCorp]

The Cordova pause and resume events are what you need to use, I don't have a good example to point you to, but I suspect there is a Cordova or PhoneGap example out there. You don't get an event for onStop... It's possible someone has written a plugin to deal with this issue, you might search the web to see if such a thing exists.

As I understand the lifecycle, you need to store away any important data during the pause event, in case you get stopped. If you are resumed you may not need to do much, other than undo what you saved in the pause state. The bigger part would be determining after a restart that you paused and should not return to the state at the last pause.

Let me see if I can find someone with some deeper experience on this subject.

[Andrea_C_]

Hi Paul,

if you look at documentation:

The pause event fires when the native platform puts the application into the background, typically when the user switches to a different application

The resume event fires when an application is retrieved from the background.

They both assume that the app is not killed.

Maybe an option could be to save the "state" on "pause" and, in case the app is killed,

look if there are some information concerning the saved state and then do the right thing.

But the resume event I think is not suitable (the app actually is still running in the background).

[PaulF_IntelCorp]

Take a look at this Android developers doc page regarding the Android resume feature. I'm pretty sure the resume event mimics this resume event, meaning that you will see the event even on a restart (which means even after the app is killed). Notice also the transition from "Started" to "Resumed" in the state diagram at the top of the article, the Android onResume() activity is called.

Assuming the Cordova event is able to follow this state transition, it should generate that event. If the Cordova framework does not, or cannot, track that specific state transition (which may be the case) you could still generate your own version of it by kicking off a custom event of your own, following app initialization. Then that event handler would have to look to see if you saved a state during the pause event and do the right thing. Notice in the state diagram that you will go through the paused state before going to the stopped state. I believe you may get no warning if a user removes you from the running queue, but that is an Android issue, not a Cordova issue (although, even in that case, you may get a pause event since your app would be removed from focus).

I have not had time to test the above theory, and will try to get some time next week.

[PaulF_IntelCorp]

Hi Andrea,

There's a very old article (http://simonmacdonald.blogspot.com/2011/04/phonegap-lifecycle-events.html) that was written by an early user of PhoneGap. I believe he is still a contributor to the Cordova project, not sure. Regardless, some comments from the cordova.js files used in Cordova 3.x frameworks hold out hope that the events that Simon outlines in his blog are still correct (he wrote that for the original PhoneGap framework, which was revised heavily with the 3.0 release).

In particular, the load and unload events should do what you're looking for, as far as detecting a "cold start" and a "I'm leaving this world" event that you could then use to do some app state bookkeeping (save and restore).

I still have not had time to try this out myself, but I thought I'd offer it up to you as something to investigate with your app, if time allows. See the comments below taken from a version 3.3 cordova.js file.

Paul

/*
 * The following is an excerpt from the 3.3.0 cordova.js file and is useful for understanding
 * Cordova events. The order of events during page load and Cordova startup is as follows:
 *
 * onDOMContentLoaded*         Internal event that is received when the web page is loaded and parsed.
 * onNativeReady*              Internal event that indicates the Cordova native side is ready.
 * onCordovaReady*             Internal event fired when all Cordova JavaScript objects have been created.
 * onDeviceReady*              User event fired to indicate that Cordova is ready
 * onResume                    User event fired to indicate a start/resume lifecycle event
 * onPause                     User event fired to indicate a pause lifecycle event
 * onDestroy*                  Internal event fired when app is being destroyed (User should use window.onunload event, not this one).
 *
 * The events marked with an * are sticky. Once they have fired, they will stay in the fired state.
 * All listeners that subscribe after the event is fired will be executed right away.
 *
 * The only Cordova events that user code should register for are:
 *      deviceready           Cordova native code is initialized and Cordova APIs can be called from JavaScript
 *      pause                 App has moved to background
 *      resume                App has returned to foreground
 *
 * Listeners can be registered as:
 *      document.addEventListener("deviceready", myDeviceReadyListener, false);
 *      document.addEventListener("resume", myResumeListener, false);
 *      document.addEventListener("pause", myPauseListener, false);
 *
 * The DOM lifecycle events should be used for saving and restoring state
 *      window.onload
 *      window.onunload
 *
 */

xyz

[Pamela_H_Intel]

Another thought . . . if, on pause, you store data AND a state variable, you could check that state variable in any place where the app starts to see if there is data that should be retrieved/reset.

[Andrea_C_]

Thanks John and Pamela for your hints,

I will try to experiment both your suggestions and see if I can manage to get this properly implemented in my app :-)

Have a nice day and (most probably) nice holidays!

Andrea