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
