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
