I've added this master. Even with the uncertainty, it's better to have this code than not.
On Thu, Jan 10, 2013 at 6:50 PM, Joe Bowser <[email protected]> wrote: > On Thu, Jan 10, 2013 at 6:31 PM, Andrew Grieve <[email protected]> wrote: >> I'd like to verify if this is the scenario: >> 1. We invoke an intent that causes another app to take the foreground. >> 2. Our app is forced to close by the OS due to memory pressures >> 3. The other app finishes and sends an intent back to us >> 4. Our app re-initializes, finds the plugin that started the request, and >> gives it the result >> > > That's the exact scenario! In theory this should work. In practice, > it sort-of works, except that the Camera doesn't pass data back if you > don't allow background processes (I tested it by restricting the > background processes). > >> Assuming I've got this straight, I think there is value in adding in this >> code. *if* apps design themselves such that their state is always stored, >> then they should have a chance at restoring their state when they >> re-launch. >> >> Uncertainties I have: >> 1. Do we have a chance to give JS some time to run >> within onSaveInstanceState? Perhaps we can send a message to the webkit >> thread and then just sleep for a second? Perhaps even let it store things >> in the Bundle? > > I don't know. I'm hoping that this stops when we save the WebKit > state, but I'd have to go spelunking in the Android WebKit code to > figure this out. > >> 2. Upon re-launch, can we signal to the JS that it is "restarting" instead >> of starting from scratch? > > We could easily do this, since we have to watch for the bundle in the > activity in the first place. From my tests, restoring the state is > the same as hitting the refresh button on the page. I have no idea > what happens to session variables or anything else that is present at > that time. > > Joe
