OK, I learned something today. If you do everything right, you too can have an Android App that crashes because the Camera is incapable of passing data when you don't let Background Processes run. Basically, the data passed by the Camera is null in this scenario, and rightfully so Cordova just goes WTF and crashes. Our current approach MUST have background processes running. As far as the other issue with cameras taking up too much memory, I'm tempted to call bullshit on this as well now that we killed the Callback Server. We should have freed up enough memory to not be killed in the background to mitigate this.
I think handling the resume state is one of the things that is beyond our scope. I'm going to commit this in a branch for now and I might resurrect this code later. Here's the branch, BTW: https://github.com/infil00p/callback-android/tree/CordovaActivity On Thu, Nov 8, 2012 at 1:56 PM, Filip Maj <[email protected]> wrote: > 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 >>> >>> >
