I'm thinking this is a documentation issue. Advise our users to properly control state in the pause + resume handlers. Check for leaks in their code in these handlers.
Related: can we say with any confidence that our platform implementations + javascript is leak-free across different application states, etc.? On 11/8/12 1:34 PM, "Andrew Grieve" <[email protected]> wrote: >Yeah, I don't think this can be done without putting onus on the JS for >storing & restoring its own state. We could maybe put the callback result >of the exec() call that triggered the activity change in the start-up info >when restoring (e.g. pass the service, action, result to onDeviceReady)? > > >On Thu, Nov 8, 2012 at 2:10 PM, Filip Maj <[email protected]> wrote: > >> function saving/serializing may be gnarly / impossible. How do we >>capture >> all possible closured variables if the JS environment boots up from a >> clean slate? >> >> On 11/8/12 10:37 AM, "Joe Bowser" <[email protected]> wrote: >> >> >OK, further update: >> > >> >After adding this on the CordovaWebView: >> > >> >public WebBackForwardList restoreState(Bundle savedInstanceState) >> >{ >> > WebBackForwardList myList = super.restoreState(savedInstanceState); >> > //Initialize the plugin manager once more >> > this.pluginManager.init(); >> > return myList; >> >} >> > >> >We now have the bridge up and working, but we have no way yet to >> >recover the callback state. Remember that we're starting an activity >> >for a result, and when the result is passed back, it's usually in the >> >extra. We have to figure out how to save the callbacks and restore >> >them, and we have to encapulate this housekeeping. >> > >> >So, should I commit what I now from the branch into this and keep >> >going with this? It's definitely an improvement but it's still not >> >100% yet. >> > >> >Joe >> > >> >On Thu, Nov 8, 2012 at 9:28 AM, Joe Bowser <[email protected]> wrote: >> >> Here's how it plays in WebKit. Below is an example of a test >>activity: >> >> >> >> public class cordovaExample extends DroidGap >> >> { >> >> >> >> @Override >> >> public void onCreate(Bundle savedInstanceState) >> >> { >> >> super.onCreate(savedInstanceState); >> >> super.setBooleanProperty("keepRunning", false); >> >> super.init(); >> >> >> >> if(savedInstanceState != null) >> >> { >> >> Log.d("Test Application", "Restoring the state"); >> >> this.appView.restoreState(savedInstanceState); >> >> } >> >> else >> >> { >> >> super.loadUrl("file:///android_asset/www/index.html"); >> >> } >> >> } >> >> >> >> >> >> >> >> protected void onSaveInstanceState(Bundle outState) >> >> { >> >> super.onSaveInstanceState(outState); >> >> this.appView.saveState(outState); >> >> } >> >> } >> >> >> >> In the example above, the savedInstanceState is being passed in. >>This >> >> is the same bundle that would hold the result from an activity. We >> >> then run restore state on the WebView, which allows us to get our >> >> history, HTML and Javascript back to where it was. This runs through >> >> all the normal loading in the WebView, but this will crash on Cordova >> >> currently because onResume assumes that we have a WebView that's >> >> already populated, which is no longer the case in this scenario. >> >> >> >> I did some work on it, and I'm having trouble getting the bridge >> >> working on the resume. Still, we have to encapsulate this and hide >> >> this from the average Cordova developer so it just works. I think >> >> this will require a refactor to do it, and I think this might break >> >> some things that people may be using. >> >> >> >> Joe >> >>
