Cordova Activity Code Changes

[Joe Bowser <bo...@gmail.com>]

Hey

I'm wanting to merge some of the state code that I was working on
before the break in.  Are people still cool with this?

https://github.com/infil00p/cordova-android/tree/CordovaActivity

Basically, this lets us restore our state if we got the app killed
while we were in Camera.  Assuming that the Camera can store the data,
this should get around the Camera issue.  It was called
CordovaActivity because I thought we were going to implement the
Activity.  This turned out not to be the case.

Thoughts?

Joe

Re: Cordova Activity Code Changes

[Joe Bowser <bo...@gmail.com>]

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 <bo...@gmail.com> wrote:
> On Thu, Jan 10, 2013 at 6:31 PM, Andrew Grieve <ag...@chromium.org> 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

Re: Cordova Activity Code Changes

[Joe Bowser <bo...@gmail.com>]

On Thu, Jan 10, 2013 at 6:31 PM, Andrew Grieve <ag...@chromium.org> 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

Re: Cordova Activity Code Changes

[Andrew Grieve <ag...@chromium.org>]

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

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?
2. Upon re-launch, can we signal to the JS that it is "restarting" instead
of starting from scratch?






On Thu, Jan 10, 2013 at 8:18 PM, Joe Bowser <bo...@gmail.com> wrote:

> BTW: This isn't a JS API change at all.
>
> On Thu, Jan 10, 2013 at 5:18 PM, Joe Bowser <bo...@gmail.com> wrote:
> > Blargh! Making things merge cleanly has reduced readibility:
> >
> >
> https://github.com/infil00p/cordova-android/commit/5ca233779d11177ec2bef97afa2910d383d6d4a2
> >
> > That's the meat of it.  I'm sure there's more in here, but I mostly
> > want to get the state change code working.  For CordovaWebView, we're
> > probably going to figure out some helper methods to allow users to
> > restore their states, but when you're working on your own Android App
> > with custom views, I think it's safe to say that your intents and
> > states are your own responsibility.
> >
> > On Thu, Jan 10, 2013 at 4:48 PM, Brian LeRoux <b...@brian.io> wrote:
> >> Love the functionality conceptually speaking but where is this code
> >> exactly so I can have a look Joe? (There's like a 1000 commits on that
> >> branch and I'm abjectly lazy.)
> >>
> >> On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
> >>> If it works, don't see why not!
> >>>
> >>> On 1/10/13 4:29 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> >>>
> >>>>Hey
> >>>>
> >>>>I'm wanting to merge some of the state code that I was working on
> >>>>before the break in.  Are people still cool with this?
> >>>>
> >>>>https://github.com/infil00p/cordova-android/tree/CordovaActivity
> >>>>
> >>>>Basically, this lets us restore our state if we got the app killed
> >>>>while we were in Camera.  Assuming that the Camera can store the data,
> >>>>this should get around the Camera issue.  It was called
> >>>>CordovaActivity because I thought we were going to implement the
> >>>>Activity.  This turned out not to be the case.
> >>>>
> >>>>Thoughts?
> >>>>
> >>>>Joe
> >>>
>

Re: Cordova Activity Code Changes

[Joe Bowser <bo...@gmail.com>]

BTW: This isn't a JS API change at all.

On Thu, Jan 10, 2013 at 5:18 PM, Joe Bowser <bo...@gmail.com> wrote:
> Blargh! Making things merge cleanly has reduced readibility:
>
> https://github.com/infil00p/cordova-android/commit/5ca233779d11177ec2bef97afa2910d383d6d4a2
>
> That's the meat of it.  I'm sure there's more in here, but I mostly
> want to get the state change code working.  For CordovaWebView, we're
> probably going to figure out some helper methods to allow users to
> restore their states, but when you're working on your own Android App
> with custom views, I think it's safe to say that your intents and
> states are your own responsibility.
>
> On Thu, Jan 10, 2013 at 4:48 PM, Brian LeRoux <b...@brian.io> wrote:
>> Love the functionality conceptually speaking but where is this code
>> exactly so I can have a look Joe? (There's like a 1000 commits on that
>> branch and I'm abjectly lazy.)
>>
>> On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
>>> If it works, don't see why not!
>>>
>>> On 1/10/13 4:29 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>>>
>>>>Hey
>>>>
>>>>I'm wanting to merge some of the state code that I was working on
>>>>before the break in.  Are people still cool with this?
>>>>
>>>>https://github.com/infil00p/cordova-android/tree/CordovaActivity
>>>>
>>>>Basically, this lets us restore our state if we got the app killed
>>>>while we were in Camera.  Assuming that the Camera can store the data,
>>>>this should get around the Camera issue.  It was called
>>>>CordovaActivity because I thought we were going to implement the
>>>>Activity.  This turned out not to be the case.
>>>>
>>>>Thoughts?
>>>>
>>>>Joe
>>>

Re: Cordova Activity Code Changes

[Joe Bowser <bo...@gmail.com>]

Blargh! Making things merge cleanly has reduced readibility:

https://github.com/infil00p/cordova-android/commit/5ca233779d11177ec2bef97afa2910d383d6d4a2

That's the meat of it.  I'm sure there's more in here, but I mostly
want to get the state change code working.  For CordovaWebView, we're
probably going to figure out some helper methods to allow users to
restore their states, but when you're working on your own Android App
with custom views, I think it's safe to say that your intents and
states are your own responsibility.

On Thu, Jan 10, 2013 at 4:48 PM, Brian LeRoux <b...@brian.io> wrote:
> Love the functionality conceptually speaking but where is this code
> exactly so I can have a look Joe? (There's like a 1000 commits on that
> branch and I'm abjectly lazy.)
>
> On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
>> If it works, don't see why not!
>>
>> On 1/10/13 4:29 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>>
>>>Hey
>>>
>>>I'm wanting to merge some of the state code that I was working on
>>>before the break in.  Are people still cool with this?
>>>
>>>https://github.com/infil00p/cordova-android/tree/CordovaActivity
>>>
>>>Basically, this lets us restore our state if we got the app killed
>>>while we were in Camera.  Assuming that the Camera can store the data,
>>>this should get around the Camera issue.  It was called
>>>CordovaActivity because I thought we were going to implement the
>>>Activity.  This turned out not to be the case.
>>>
>>>Thoughts?
>>>
>>>Joe
>>

Re: Cordova Activity Code Changes

[Brian LeRoux <b...@brian.io>]

Love the functionality conceptually speaking but where is this code
exactly so I can have a look Joe? (There's like a 1000 commits on that
branch and I'm abjectly lazy.)

On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
> If it works, don't see why not!
>
> On 1/10/13 4:29 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>
>>Hey
>>
>>I'm wanting to merge some of the state code that I was working on
>>before the break in.  Are people still cool with this?
>>
>>https://github.com/infil00p/cordova-android/tree/CordovaActivity
>>
>>Basically, this lets us restore our state if we got the app killed
>>while we were in Camera.  Assuming that the Camera can store the data,
>>this should get around the Camera issue.  It was called
>>CordovaActivity because I thought we were going to implement the
>>Activity.  This turned out not to be the case.
>>
>>Thoughts?
>>
>>Joe
>

Re: Cordova Activity Code Changes

[Filip Maj <fi...@adobe.com>]

If it works, don't see why not!

On 1/10/13 4:29 PM, "Joe Bowser" <bo...@gmail.com> wrote:

>Hey
>
>I'm wanting to merge some of the state code that I was working on
>before the break in.  Are people still cool with this?
>
>https://github.com/infil00p/cordova-android/tree/CordovaActivity
>
>Basically, this lets us restore our state if we got the app killed
>while we were in Camera.  Assuming that the Camera can store the data,
>this should get around the Camera issue.  It was called
>CordovaActivity because I thought we were going to implement the
>Activity.  This turned out not to be the case.
>
>Thoughts?
>
>Joe