cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: [Android] - State, Plugins and the Android Lifecycle
Date Thu, 08 Nov 2012 21:56:40 GMT
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" <agrieve@chromium.org> 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 <fil@adobe.com> 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" <bowserj@gmail.com> 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 <bowserj@gmail.com> 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
>>
>>


Mime
View raw message