You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2014/10/16 20:29:50 UTC
Re: Android: activityResultKeepRunning
So, what's going on with this? Did this land in any release of Cordova?
On Fri, Sep 12, 2014 at 12:24 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>
> On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik <na...@gmail.com>
> wrote:
>
>> We have tested this behavior and in fact AmazonWebView which was and is
>> always based on chromium, we recommend to pause/resume timers in order to
>> manage resources.
>>
>
> So, it works on the Amazon Chromium build?
>
> The more things change, the more they stay the same! We should probably
> adopt the changes that Andrew did, and the patch from Crosswalk, since I'd
> rather have it be our problem than it being all over the place.
>
>
>>
>> On Fri, Sep 12, 2014 at 10:21 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser <bo...@gmail.com> wrote:
>> > > After testing this again for sanity, we should probably kill this
>> option.
>> > > I don't like it (in fact I hate it), but resumeTimers doesn't
>> actually
>> > > resume the timers on KitKat, and since other browsers may not even
>> > support
>> > > this, we have to add a bunch of buggy Javascript that will be prone to
>> > > breaking instead of buggy Chromium code that's prone to breaking.
>> >
>> > Which part did you test (what do you mean by "this")? I've not seen
>> > resumeTimers() fail to work.
>> >
>> > >
>> > > I still wish someone other than me actually bothered testing this and
>> > > showing what they had.
>> > >
>> > > On Fri, Sep 12, 2014 at 5:10 AM, Ian Clelland <iclelland@chromium.org
>> >
>> > > wrote:
>> > >
>> > >> The patch that they applied was actually taken from the
>> > >> Cordova-crosswalk-engine plugin, so in this case, they're keeping up
>> > with
>> > >> us :)
>> > >>
>> > >> And yeah, once we get this all sorted out, it should be documented.
>> > >>
>> > >> On Fri, Sep 12, 2014 at 1:55 AM, Andrey Kurdumov <
>> > kant2002@googlemail.com>
>> > >> wrote:
>> > >>
>> > >> > Hi,
>> > >> >
>> > >> > I periodically check how Crosswalk engine developed and seen that
>> they
>> > >> land
>> > >> > functionality which you are discussing today/yesterday
>> > >> >
>> > https://github.com/crosswalk-project/crosswalk-cordova-android/pull/136
>> > >> >
>> > >> > Maybe there make sense keep compatibility with them too. Or at
>> least
>> > if
>> > >> > timers would be paused, this should be documented.
>> > >> > Would be good if alternative engines have compatible lifecycle as
>> > much as
>> > >> > possible.
>> > >> >
>> > >> > Best regargs,
>> > >> > Andrey Kurdyumov
>> > >> >
>> > >> >
>> > >> > 2014-09-12 0:58 GMT+06:00 Andrew Grieve <ag...@chromium.org>:
>> > >> >
>> > >> > > I guess I can see the value of providing a safety option for
>> "pause
>> > my
>> > >> > > app in the background", but in general I think it's better
>> practice
>> > to
>> > >> > > not pause forcefully, and instead have apps listen to the "pause"
>> > >> > > event, and stop battery-draining activity there instead. So...
>> let's
>> > >> > > keep the option in, and keep it off by default.
>> > >> > >
>> > >> > > Joe / Tommy - not sure from your comments as to whether they were
>> > >> > > directed at the idea of removing the option completely, or to the
>> > >> > > patch I sent that gets rid of unconditionally pausing timers
>> during
>> > >> > > startActivityForResult flows. Really can't see why you'd want
>> that,
>> > >> > > and I think it would just cause subtle bugs.
>> > >> > >
>> > >> > > On Wed, Sep 10, 2014 at 8:42 PM, Tommy Williams <
>> tommy@devgeeks.org
>> > >
>> > >> > > wrote:
>> > >> > > > Biiiiig -1 for breaking current background behaviour.
>> > >> > > >
>> > >> > > > Or am I misunderstanding?
>> > >> > > > On 11 Sep 2014 10:34, "Joe Bowser" <bo...@gmail.com> wrote:
>> > >> > > >
>> > >> > > >> Pausing timers means that the JS isn't running in the
>> background
>> > at
>> > >> > all.
>> > >> > > >> This now means that the Javascript is running constantly,
>> > >> regardless
>> > >> > of
>> > >> > > >> whether it's an event. This means that setInterval is still
>> > >> running.
>> > >> > > This
>> > >> > > >> could break people's applications.
>> > >> > > >>
>> > >> > > >> On Wed, Sep 10, 2014 at 5:29 PM, Andrew Grieve <
>> > >> agrieve@chromium.org>
>> > >> > > >> wrote:
>> > >> > > >>
>> > >> > > >> > Getting off track here a bit.
>> > >> > > >> >
>> > >> > > >> > Here's what I'm suggesting with my original email:
>> > >> > > >> >
>> > >> > > >> >
>> > >> > > >>
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://github.com/agrieve/cordova-android/compare/apache:4.0.x...no_disable_timers?expand=1
>> > >> > > >> >
>> > >> > > >> > I was further asking if there was any use in ever pausing
>> > timers
>> > >> > (aka,
>> > >> > > >> > removing the KeepRunning preference).
>> > >> > > >> >
>> > >> > > >> >
>> > >> > > >> >
>> > >> > > >> > On Wed, Sep 10, 2014 at 4:56 PM, Brian LeRoux <b...@brian.io>
>> > wrote:
>> > >> > > >> > > I consider 4 a release branch. Merge in tested green lit
>> > code to
>> > >> > > your
>> > >> > > >> > > hearts desire but 4.0 is definitely not a feature. It
>> should
>> > be
>> > >> > > always
>> > >> > > >> > in a
>> > >> > > >> > > releasable state.
>> > >> > > >> > > On Sep 10, 2014 1:53 PM, "Michal Mocny" <
>> mmocny@chromium.org
>> > >
>> > >> > > wrote:
>> > >> > > >> > >
>> > >> > > >> > >> Question is, do you consider the fact that bugs are
>> > introduced
>> > >> &
>> > >> > > >> > discovered
>> > >> > > >> > >> (possibly with pain) a sign that the system is broken,
>> or a
>> > >> sign
>> > >> > > that
>> > >> > > >> > the
>> > >> > > >> > >> system is working?
>> > >> > > >> > >>
>> > >> > > >> > >> I sense that Andrew worries that if work has to land on a
>> > >> feature
>> > >> > > >> > branch of
>> > >> > > >> > >> this feature branch, it won't get eyeballs.
>> > >> > > >> > >>
>> > >> > > >> > >> I sense that Joe worries that if we land
>> > everything/anything in
>> > >> > > >> > Android-4.0
>> > >> > > >> > >> it will become unstable, as mistakes are prone to happen
>> > (see
>> > >> > i.e.
>> > >> > > >> > recent
>> > >> > > >> > >> issue with black background).
>> > >> > > >> > >>
>> > >> > > >> > >> Personally, I prefer eyeballs and instability to delayed
>> > >> > discovery
>> > >> > > >> and a
>> > >> > > >> > >> sense of stability, especially for a feature branch like
>> > >> > > Android-4.0.
>> > >> > > >> > >> There are workarounds for demos (i.e. create your own
>> > branch
>> > >> off
>> > >> > > of a
>> > >> > > >> > >> known working version), but its not as easy to solve the
>> > >> eyeball
>> > >> > > >> > problem.
>> > >> > > >> > >>
>> > >> > > >> > >> -Michal
>> > >> > > >> > >>
>> > >> > > >> > >> On Wed, Sep 10, 2014 at 3:50 PM, Joe Bowser <
>> > bowserj@gmail.com
>> > >> >
>> > >> > > >> wrote:
>> > >> > > >> > >>
>> > >> > > >> > >> > I think this needs to be thought through more, and I'm
>> > >> > extremely
>> > >> > > >> wary
>> > >> > > >> > >> when
>> > >> > > >> > >> > you say this is a single commit, especially based on
>> the
>> > last
>> > >> > > couple
>> > >> > > >> > of
>> > >> > > >> > >> > months and how long it took 3.6 to go through. Given
>> > that we
>> > >> > > have
>> > >> > > >> > people
>> > >> > > >> > >> > travelling halfway across the planet who intend to show
>> > >> people
>> > >> > > their
>> > >> > > >> > work
>> > >> > > >> > >> > in less than two weeks, I would definitely like it if
>> you
>> > >> were
>> > >> > to
>> > >> > > >> put
>> > >> > > >> > >> this
>> > >> > > >> > >> > in your own branch for testing.
>> > >> > > >> > >> >
>> > >> > > >> > >> > On Wed, Sep 10, 2014 at 12:41 PM, Andrew Grieve <
>> > >> > > >> agrieve@chromium.org
>> > >> > > >> > >
>> > >> > > >> > >> > wrote:
>> > >> > > >> > >> >
>> > >> > > >> > >> > > I don't think there'd be much value in that. It'll
>> be a
>> > >> > single
>> > >> > > >> > commit
>> > >> > > >> > >> > > that almost entirely just deletes lines.
>> > >> > > >> > >> > >
>> > >> > > >> > >> > > What do you think about the never auto-pausing on
>> > >> > > backgrounding?
>> > >> > > >> or
>> > >> > > >> > >> > > about auto-pausing when intent sending?
>> > >> > > >> > >> > >
>> > >> > > >> > >> > > On Wed, Sep 10, 2014 at 12:32 PM, Joe Bowser <
>> > >> > > bowserj@gmail.com>
>> > >> > > >> > >> wrote:
>> > >> > > >> > >> > > > Can you put this on its own branch before it lands
>> in
>> > >> > 4.0.x?
>> > >> > > >> > That'd
>> > >> > > >> > >> be
>> > >> > > >> > >> > > > awesome!
>> > >> > > >> > >> > > >
>> > >> > > >> > >> > > > On Tue, Sep 9, 2014 at 5:32 PM, Andrew Grieve <
>> > >> > > >> > agrieve@chromium.org>
>> > >> > > >> > >> > > wrote:
>> > >> > > >> > >> > > >>
>> > >> > > >> > >> > > >> For cordova-android 4.0, I'd like to go as far as
>> > just
>> > >> > > deleting
>> > >> > > >> > the
>> > >> > > >> > >> > > >> "KeepRunning" <preference>.
>> > >> > > >> > >> > > >>
>> > >> > > >> > >> > > >> Apps get a "pause" event when they are
>> backgrounded,
>> > and
>> > >> > > they
>> > >> > > >> > can do
>> > >> > > >> > >> > > >> any pause-type logic there (e.g. unlisten to
>> > >> accelerometer
>> > >> > > >> > events or
>> > >> > > >> > >> > > >> pausing audio).
>> > >> > > >> > >> > > >>
>> > >> > > >> > >> > > >> Any strong objections?
>> > >> > > >> > >> > > >>
>> > >> > > >> > >> > > >> On Tue, Sep 9, 2014 at 4:27 PM, Andrew Grieve <
>> > >> > > >> > agrieve@chromium.org
>> > >> > > >> > >> >
>> > >> > > >> > >> > > >> wrote:
>> > >> > > >> > >> > > >> > Commit description: If multitasking is turned on
>> > >> > > >> > >> (keepRunning=true),
>> > >> > > >> > >> > > >> > then temporarily disable it when starting a new
>> > >> activity
>> > >> > > that
>> > >> > > >> > >> > returns
>> > >> > > >> > >> > > >> > a result - such as camera.
>> > >> > > >> > >> > > >> >
>> > >> > > >> > >> > > >> >
>> > >> > > >> > >> > > >> >
>> > >> > > >> > >> > >
>> > >> > > >> > >> >
>> > >> > > >> > >>
>> > >> > > >> >
>> > >> > > >>
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://github.com/apache/cordova-android/commit/26adfb634651196106fb5b66f15eecb535a06d82
>> > >> > > >> > >> > > >> >
>> > >> > > >> > >> > > >> > Bryce / anyone - clues as to *why* we'd want to
>> > >> disable
>> > >> > JS
>> > >> > > >> > timers
>> > >> > > >> > >> > when
>> > >> > > >> > >> > > >> > firing off an intent?
>> > >> > > >> > >> > > >
>> > >> > > >> > >> > > >
>> > >> > > >> > >> > >
>> > >> > > >> > >> >
>> > >> > > >> > >>
>> > >> > > >> >
>> > >> > > >>
>> > >> > >
>> > >> >
>> > >>
>> >
>>
>
>
Re: Android: activityResultKeepRunning
Posted by Andrew Grieve <ag...@chromium.org>.
Created an issue with proposed changes:
https://issues.apache.org/jira/browse/CB-7947. Let's move discussion there.
On Tue, Oct 21, 2014 at 12:03 PM, Andrew Grieve <ag...@chromium.org>
wrote:
> I don't think there's even been an issue opened for it. Seems like maybe
> the proper thing to do here though, is to move the pause/resumeTimers logic
> into CordovaActivity since they apply to all webviews.
>
> On Thu, Oct 16, 2014 at 2:29 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> So, what's going on with this? Did this land in any release of Cordova?
>>
>> On Fri, Sep 12, 2014 at 12:24 PM, Joe Bowser <bo...@gmail.com> wrote:
>>
>> >
>> >
>> > On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik <na...@gmail.com>
>> > wrote:
>> >
>> >> We have tested this behavior and in fact AmazonWebView which was and is
>> >> always based on chromium, we recommend to pause/resume timers in order
>> to
>> >> manage resources.
>> >>
>> >
>> > So, it works on the Amazon Chromium build?
>> >
>> > The more things change, the more they stay the same! We should probably
>> > adopt the changes that Andrew did, and the patch from Crosswalk, since
>> I'd
>> > rather have it be our problem than it being all over the place.
>> >
>> >
>> >>
>> >> On Fri, Sep 12, 2014 at 10:21 AM, Andrew Grieve <ag...@chromium.org>
>> >> wrote:
>> >>
>> >> > On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser <bo...@gmail.com>
>> wrote:
>> >> > > After testing this again for sanity, we should probably kill this
>> >> option.
>> >> > > I don't like it (in fact I hate it), but resumeTimers doesn't
>> >> actually
>> >> > > resume the timers on KitKat, and since other browsers may not even
>> >> > support
>> >> > > this, we have to add a bunch of buggy Javascript that will be
>> prone to
>> >> > > breaking instead of buggy Chromium code that's prone to breaking.
>> >> >
>> >> > Which part did you test (what do you mean by "this")? I've not seen
>> >> > resumeTimers() fail to work.
>> >> >
>> >> > >
>> >> > > I still wish someone other than me actually bothered testing this
>> and
>> >> > > showing what they had.
>> >> > >
>> >> > > On Fri, Sep 12, 2014 at 5:10 AM, Ian Clelland <
>> iclelland@chromium.org
>> >> >
>> >> > > wrote:
>> >> > >
>> >> > >> The patch that they applied was actually taken from the
>> >> > >> Cordova-crosswalk-engine plugin, so in this case, they're keeping
>> up
>> >> > with
>> >> > >> us :)
>> >> > >>
>> >> > >> And yeah, once we get this all sorted out, it should be
>> documented.
>> >> > >>
>> >> > >> On Fri, Sep 12, 2014 at 1:55 AM, Andrey Kurdumov <
>> >> > kant2002@googlemail.com>
>> >> > >> wrote:
>> >> > >>
>> >> > >> > Hi,
>> >> > >> >
>> >> > >> > I periodically check how Crosswalk engine developed and seen
>> that
>> >> they
>> >> > >> land
>> >> > >> > functionality which you are discussing today/yesterday
>> >> > >> >
>> >> >
>> https://github.com/crosswalk-project/crosswalk-cordova-android/pull/136
>> >> > >> >
>> >> > >> > Maybe there make sense keep compatibility with them too. Or at
>> >> least
>> >> > if
>> >> > >> > timers would be paused, this should be documented.
>> >> > >> > Would be good if alternative engines have compatible lifecycle
>> as
>> >> > much as
>> >> > >> > possible.
>> >> > >> >
>> >> > >> > Best regargs,
>> >> > >> > Andrey Kurdyumov
>> >> > >> >
>> >> > >> >
>> >> > >> > 2014-09-12 0:58 GMT+06:00 Andrew Grieve <ag...@chromium.org>:
>> >> > >> >
>> >> > >> > > I guess I can see the value of providing a safety option for
>> >> "pause
>> >> > my
>> >> > >> > > app in the background", but in general I think it's better
>> >> practice
>> >> > to
>> >> > >> > > not pause forcefully, and instead have apps listen to the
>> "pause"
>> >> > >> > > event, and stop battery-draining activity there instead. So...
>> >> let's
>> >> > >> > > keep the option in, and keep it off by default.
>> >> > >> > >
>> >> > >> > > Joe / Tommy - not sure from your comments as to whether they
>> were
>> >> > >> > > directed at the idea of removing the option completely, or to
>> the
>> >> > >> > > patch I sent that gets rid of unconditionally pausing timers
>> >> during
>> >> > >> > > startActivityForResult flows. Really can't see why you'd want
>> >> that,
>> >> > >> > > and I think it would just cause subtle bugs.
>> >> > >> > >
>> >> > >> > > On Wed, Sep 10, 2014 at 8:42 PM, Tommy Williams <
>> >> tommy@devgeeks.org
>> >> > >
>> >> > >> > > wrote:
>> >> > >> > > > Biiiiig -1 for breaking current background behaviour.
>> >> > >> > > >
>> >> > >> > > > Or am I misunderstanding?
>> >> > >> > > > On 11 Sep 2014 10:34, "Joe Bowser" <bo...@gmail.com>
>> wrote:
>> >> > >> > > >
>> >> > >> > > >> Pausing timers means that the JS isn't running in the
>> >> background
>> >> > at
>> >> > >> > all.
>> >> > >> > > >> This now means that the Javascript is running constantly,
>> >> > >> regardless
>> >> > >> > of
>> >> > >> > > >> whether it's an event. This means that setInterval is
>> still
>> >> > >> running.
>> >> > >> > > This
>> >> > >> > > >> could break people's applications.
>> >> > >> > > >>
>> >> > >> > > >> On Wed, Sep 10, 2014 at 5:29 PM, Andrew Grieve <
>> >> > >> agrieve@chromium.org>
>> >> > >> > > >> wrote:
>> >> > >> > > >>
>> >> > >> > > >> > Getting off track here a bit.
>> >> > >> > > >> >
>> >> > >> > > >> > Here's what I'm suggesting with my original email:
>> >> > >> > > >> >
>> >> > >> > > >> >
>> >> > >> > > >>
>> >> > >> > >
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>> https://github.com/agrieve/cordova-android/compare/apache:4.0.x...no_disable_timers?expand=1
>> >> > >> > > >> >
>> >> > >> > > >> > I was further asking if there was any use in ever pausing
>> >> > timers
>> >> > >> > (aka,
>> >> > >> > > >> > removing the KeepRunning preference).
>> >> > >> > > >> >
>> >> > >> > > >> >
>> >> > >> > > >> >
>> >> > >> > > >> > On Wed, Sep 10, 2014 at 4:56 PM, Brian LeRoux <
>> b@brian.io>
>> >> > wrote:
>> >> > >> > > >> > > I consider 4 a release branch. Merge in tested green
>> lit
>> >> > code to
>> >> > >> > > your
>> >> > >> > > >> > > hearts desire but 4.0 is definitely not a feature. It
>> >> should
>> >> > be
>> >> > >> > > always
>> >> > >> > > >> > in a
>> >> > >> > > >> > > releasable state.
>> >> > >> > > >> > > On Sep 10, 2014 1:53 PM, "Michal Mocny" <
>> >> mmocny@chromium.org
>> >> > >
>> >> > >> > > wrote:
>> >> > >> > > >> > >
>> >> > >> > > >> > >> Question is, do you consider the fact that bugs are
>> >> > introduced
>> >> > >> &
>> >> > >> > > >> > discovered
>> >> > >> > > >> > >> (possibly with pain) a sign that the system is broken,
>> >> or a
>> >> > >> sign
>> >> > >> > > that
>> >> > >> > > >> > the
>> >> > >> > > >> > >> system is working?
>> >> > >> > > >> > >>
>> >> > >> > > >> > >> I sense that Andrew worries that if work has to land
>> on a
>> >> > >> feature
>> >> > >> > > >> > branch of
>> >> > >> > > >> > >> this feature branch, it won't get eyeballs.
>> >> > >> > > >> > >>
>> >> > >> > > >> > >> I sense that Joe worries that if we land
>> >> > everything/anything in
>> >> > >> > > >> > Android-4.0
>> >> > >> > > >> > >> it will become unstable, as mistakes are prone to
>> happen
>> >> > (see
>> >> > >> > i.e.
>> >> > >> > > >> > recent
>> >> > >> > > >> > >> issue with black background).
>> >> > >> > > >> > >>
>> >> > >> > > >> > >> Personally, I prefer eyeballs and instability to
>> delayed
>> >> > >> > discovery
>> >> > >> > > >> and a
>> >> > >> > > >> > >> sense of stability, especially for a feature branch
>> like
>> >> > >> > > Android-4.0.
>> >> > >> > > >> > >> There are workarounds for demos (i.e. create your own
>> >> > branch
>> >> > >> off
>> >> > >> > > of a
>> >> > >> > > >> > >> known working version), but its not as easy to solve
>> the
>> >> > >> eyeball
>> >> > >> > > >> > problem.
>> >> > >> > > >> > >>
>> >> > >> > > >> > >> -Michal
>> >> > >> > > >> > >>
>> >> > >> > > >> > >> On Wed, Sep 10, 2014 at 3:50 PM, Joe Bowser <
>> >> > bowserj@gmail.com
>> >> > >> >
>> >> > >> > > >> wrote:
>> >> > >> > > >> > >>
>> >> > >> > > >> > >> > I think this needs to be thought through more, and
>> I'm
>> >> > >> > extremely
>> >> > >> > > >> wary
>> >> > >> > > >> > >> when
>> >> > >> > > >> > >> > you say this is a single commit, especially based on
>> >> the
>> >> > last
>> >> > >> > > couple
>> >> > >> > > >> > of
>> >> > >> > > >> > >> > months and how long it took 3.6 to go through.
>> Given
>> >> > that we
>> >> > >> > > have
>> >> > >> > > >> > people
>> >> > >> > > >> > >> > travelling halfway across the planet who intend to
>> show
>> >> > >> people
>> >> > >> > > their
>> >> > >> > > >> > work
>> >> > >> > > >> > >> > in less than two weeks, I would definitely like it
>> if
>> >> you
>> >> > >> were
>> >> > >> > to
>> >> > >> > > >> put
>> >> > >> > > >> > >> this
>> >> > >> > > >> > >> > in your own branch for testing.
>> >> > >> > > >> > >> >
>> >> > >> > > >> > >> > On Wed, Sep 10, 2014 at 12:41 PM, Andrew Grieve <
>> >> > >> > > >> agrieve@chromium.org
>> >> > >> > > >> > >
>> >> > >> > > >> > >> > wrote:
>> >> > >> > > >> > >> >
>> >> > >> > > >> > >> > > I don't think there'd be much value in that. It'll
>> >> be a
>> >> > >> > single
>> >> > >> > > >> > commit
>> >> > >> > > >> > >> > > that almost entirely just deletes lines.
>> >> > >> > > >> > >> > >
>> >> > >> > > >> > >> > > What do you think about the never auto-pausing on
>> >> > >> > > backgrounding?
>> >> > >> > > >> or
>> >> > >> > > >> > >> > > about auto-pausing when intent sending?
>> >> > >> > > >> > >> > >
>> >> > >> > > >> > >> > > On Wed, Sep 10, 2014 at 12:32 PM, Joe Bowser <
>> >> > >> > > bowserj@gmail.com>
>> >> > >> > > >> > >> wrote:
>> >> > >> > > >> > >> > > > Can you put this on its own branch before it
>> lands
>> >> in
>> >> > >> > 4.0.x?
>> >> > >> > > >> > That'd
>> >> > >> > > >> > >> be
>> >> > >> > > >> > >> > > > awesome!
>> >> > >> > > >> > >> > > >
>> >> > >> > > >> > >> > > > On Tue, Sep 9, 2014 at 5:32 PM, Andrew Grieve <
>> >> > >> > > >> > agrieve@chromium.org>
>> >> > >> > > >> > >> > > wrote:
>> >> > >> > > >> > >> > > >>
>> >> > >> > > >> > >> > > >> For cordova-android 4.0, I'd like to go as far
>> as
>> >> > just
>> >> > >> > > deleting
>> >> > >> > > >> > the
>> >> > >> > > >> > >> > > >> "KeepRunning" <preference>.
>> >> > >> > > >> > >> > > >>
>> >> > >> > > >> > >> > > >> Apps get a "pause" event when they are
>> >> backgrounded,
>> >> > and
>> >> > >> > > they
>> >> > >> > > >> > can do
>> >> > >> > > >> > >> > > >> any pause-type logic there (e.g. unlisten to
>> >> > >> accelerometer
>> >> > >> > > >> > events or
>> >> > >> > > >> > >> > > >> pausing audio).
>> >> > >> > > >> > >> > > >>
>> >> > >> > > >> > >> > > >> Any strong objections?
>> >> > >> > > >> > >> > > >>
>> >> > >> > > >> > >> > > >> On Tue, Sep 9, 2014 at 4:27 PM, Andrew Grieve <
>> >> > >> > > >> > agrieve@chromium.org
>> >> > >> > > >> > >> >
>> >> > >> > > >> > >> > > >> wrote:
>> >> > >> > > >> > >> > > >> > Commit description: If multitasking is
>> turned on
>> >> > >> > > >> > >> (keepRunning=true),
>> >> > >> > > >> > >> > > >> > then temporarily disable it when starting a
>> new
>> >> > >> activity
>> >> > >> > > that
>> >> > >> > > >> > >> > returns
>> >> > >> > > >> > >> > > >> > a result - such as camera.
>> >> > >> > > >> > >> > > >> >
>> >> > >> > > >> > >> > > >> >
>> >> > >> > > >> > >> > > >> >
>> >> > >> > > >> > >> > >
>> >> > >> > > >> > >> >
>> >> > >> > > >> > >>
>> >> > >> > > >> >
>> >> > >> > > >>
>> >> > >> > >
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>> https://github.com/apache/cordova-android/commit/26adfb634651196106fb5b66f15eecb535a06d82
>> >> > >> > > >> > >> > > >> >
>> >> > >> > > >> > >> > > >> > Bryce / anyone - clues as to *why* we'd want
>> to
>> >> > >> disable
>> >> > >> > JS
>> >> > >> > > >> > timers
>> >> > >> > > >> > >> > when
>> >> > >> > > >> > >> > > >> > firing off an intent?
>> >> > >> > > >> > >> > > >
>> >> > >> > > >> > >> > > >
>> >> > >> > > >> > >> > >
>> >> > >> > > >> > >> >
>> >> > >> > > >> > >>
>> >> > >> > > >> >
>> >> > >> > > >>
>> >> > >> > >
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: Android: activityResultKeepRunning
Posted by Andrew Grieve <ag...@chromium.org>.
I don't think there's even been an issue opened for it. Seems like maybe
the proper thing to do here though, is to move the pause/resumeTimers logic
into CordovaActivity since they apply to all webviews.
On Thu, Oct 16, 2014 at 2:29 PM, Joe Bowser <bo...@gmail.com> wrote:
> So, what's going on with this? Did this land in any release of Cordova?
>
> On Fri, Sep 12, 2014 at 12:24 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> >
> >
> > On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik <na...@gmail.com>
> > wrote:
> >
> >> We have tested this behavior and in fact AmazonWebView which was and is
> >> always based on chromium, we recommend to pause/resume timers in order
> to
> >> manage resources.
> >>
> >
> > So, it works on the Amazon Chromium build?
> >
> > The more things change, the more they stay the same! We should probably
> > adopt the changes that Andrew did, and the patch from Crosswalk, since
> I'd
> > rather have it be our problem than it being all over the place.
> >
> >
> >>
> >> On Fri, Sep 12, 2014 at 10:21 AM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >>
> >> > On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> >> > > After testing this again for sanity, we should probably kill this
> >> option.
> >> > > I don't like it (in fact I hate it), but resumeTimers doesn't
> >> actually
> >> > > resume the timers on KitKat, and since other browsers may not even
> >> > support
> >> > > this, we have to add a bunch of buggy Javascript that will be prone
> to
> >> > > breaking instead of buggy Chromium code that's prone to breaking.
> >> >
> >> > Which part did you test (what do you mean by "this")? I've not seen
> >> > resumeTimers() fail to work.
> >> >
> >> > >
> >> > > I still wish someone other than me actually bothered testing this
> and
> >> > > showing what they had.
> >> > >
> >> > > On Fri, Sep 12, 2014 at 5:10 AM, Ian Clelland <
> iclelland@chromium.org
> >> >
> >> > > wrote:
> >> > >
> >> > >> The patch that they applied was actually taken from the
> >> > >> Cordova-crosswalk-engine plugin, so in this case, they're keeping
> up
> >> > with
> >> > >> us :)
> >> > >>
> >> > >> And yeah, once we get this all sorted out, it should be documented.
> >> > >>
> >> > >> On Fri, Sep 12, 2014 at 1:55 AM, Andrey Kurdumov <
> >> > kant2002@googlemail.com>
> >> > >> wrote:
> >> > >>
> >> > >> > Hi,
> >> > >> >
> >> > >> > I periodically check how Crosswalk engine developed and seen that
> >> they
> >> > >> land
> >> > >> > functionality which you are discussing today/yesterday
> >> > >> >
> >> >
> https://github.com/crosswalk-project/crosswalk-cordova-android/pull/136
> >> > >> >
> >> > >> > Maybe there make sense keep compatibility with them too. Or at
> >> least
> >> > if
> >> > >> > timers would be paused, this should be documented.
> >> > >> > Would be good if alternative engines have compatible lifecycle as
> >> > much as
> >> > >> > possible.
> >> > >> >
> >> > >> > Best regargs,
> >> > >> > Andrey Kurdyumov
> >> > >> >
> >> > >> >
> >> > >> > 2014-09-12 0:58 GMT+06:00 Andrew Grieve <ag...@chromium.org>:
> >> > >> >
> >> > >> > > I guess I can see the value of providing a safety option for
> >> "pause
> >> > my
> >> > >> > > app in the background", but in general I think it's better
> >> practice
> >> > to
> >> > >> > > not pause forcefully, and instead have apps listen to the
> "pause"
> >> > >> > > event, and stop battery-draining activity there instead. So...
> >> let's
> >> > >> > > keep the option in, and keep it off by default.
> >> > >> > >
> >> > >> > > Joe / Tommy - not sure from your comments as to whether they
> were
> >> > >> > > directed at the idea of removing the option completely, or to
> the
> >> > >> > > patch I sent that gets rid of unconditionally pausing timers
> >> during
> >> > >> > > startActivityForResult flows. Really can't see why you'd want
> >> that,
> >> > >> > > and I think it would just cause subtle bugs.
> >> > >> > >
> >> > >> > > On Wed, Sep 10, 2014 at 8:42 PM, Tommy Williams <
> >> tommy@devgeeks.org
> >> > >
> >> > >> > > wrote:
> >> > >> > > > Biiiiig -1 for breaking current background behaviour.
> >> > >> > > >
> >> > >> > > > Or am I misunderstanding?
> >> > >> > > > On 11 Sep 2014 10:34, "Joe Bowser" <bo...@gmail.com>
> wrote:
> >> > >> > > >
> >> > >> > > >> Pausing timers means that the JS isn't running in the
> >> background
> >> > at
> >> > >> > all.
> >> > >> > > >> This now means that the Javascript is running constantly,
> >> > >> regardless
> >> > >> > of
> >> > >> > > >> whether it's an event. This means that setInterval is still
> >> > >> running.
> >> > >> > > This
> >> > >> > > >> could break people's applications.
> >> > >> > > >>
> >> > >> > > >> On Wed, Sep 10, 2014 at 5:29 PM, Andrew Grieve <
> >> > >> agrieve@chromium.org>
> >> > >> > > >> wrote:
> >> > >> > > >>
> >> > >> > > >> > Getting off track here a bit.
> >> > >> > > >> >
> >> > >> > > >> > Here's what I'm suggesting with my original email:
> >> > >> > > >> >
> >> > >> > > >> >
> >> > >> > > >>
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> https://github.com/agrieve/cordova-android/compare/apache:4.0.x...no_disable_timers?expand=1
> >> > >> > > >> >
> >> > >> > > >> > I was further asking if there was any use in ever pausing
> >> > timers
> >> > >> > (aka,
> >> > >> > > >> > removing the KeepRunning preference).
> >> > >> > > >> >
> >> > >> > > >> >
> >> > >> > > >> >
> >> > >> > > >> > On Wed, Sep 10, 2014 at 4:56 PM, Brian LeRoux <b@brian.io
> >
> >> > wrote:
> >> > >> > > >> > > I consider 4 a release branch. Merge in tested green lit
> >> > code to
> >> > >> > > your
> >> > >> > > >> > > hearts desire but 4.0 is definitely not a feature. It
> >> should
> >> > be
> >> > >> > > always
> >> > >> > > >> > in a
> >> > >> > > >> > > releasable state.
> >> > >> > > >> > > On Sep 10, 2014 1:53 PM, "Michal Mocny" <
> >> mmocny@chromium.org
> >> > >
> >> > >> > > wrote:
> >> > >> > > >> > >
> >> > >> > > >> > >> Question is, do you consider the fact that bugs are
> >> > introduced
> >> > >> &
> >> > >> > > >> > discovered
> >> > >> > > >> > >> (possibly with pain) a sign that the system is broken,
> >> or a
> >> > >> sign
> >> > >> > > that
> >> > >> > > >> > the
> >> > >> > > >> > >> system is working?
> >> > >> > > >> > >>
> >> > >> > > >> > >> I sense that Andrew worries that if work has to land
> on a
> >> > >> feature
> >> > >> > > >> > branch of
> >> > >> > > >> > >> this feature branch, it won't get eyeballs.
> >> > >> > > >> > >>
> >> > >> > > >> > >> I sense that Joe worries that if we land
> >> > everything/anything in
> >> > >> > > >> > Android-4.0
> >> > >> > > >> > >> it will become unstable, as mistakes are prone to
> happen
> >> > (see
> >> > >> > i.e.
> >> > >> > > >> > recent
> >> > >> > > >> > >> issue with black background).
> >> > >> > > >> > >>
> >> > >> > > >> > >> Personally, I prefer eyeballs and instability to
> delayed
> >> > >> > discovery
> >> > >> > > >> and a
> >> > >> > > >> > >> sense of stability, especially for a feature branch
> like
> >> > >> > > Android-4.0.
> >> > >> > > >> > >> There are workarounds for demos (i.e. create your own
> >> > branch
> >> > >> off
> >> > >> > > of a
> >> > >> > > >> > >> known working version), but its not as easy to solve
> the
> >> > >> eyeball
> >> > >> > > >> > problem.
> >> > >> > > >> > >>
> >> > >> > > >> > >> -Michal
> >> > >> > > >> > >>
> >> > >> > > >> > >> On Wed, Sep 10, 2014 at 3:50 PM, Joe Bowser <
> >> > bowserj@gmail.com
> >> > >> >
> >> > >> > > >> wrote:
> >> > >> > > >> > >>
> >> > >> > > >> > >> > I think this needs to be thought through more, and
> I'm
> >> > >> > extremely
> >> > >> > > >> wary
> >> > >> > > >> > >> when
> >> > >> > > >> > >> > you say this is a single commit, especially based on
> >> the
> >> > last
> >> > >> > > couple
> >> > >> > > >> > of
> >> > >> > > >> > >> > months and how long it took 3.6 to go through. Given
> >> > that we
> >> > >> > > have
> >> > >> > > >> > people
> >> > >> > > >> > >> > travelling halfway across the planet who intend to
> show
> >> > >> people
> >> > >> > > their
> >> > >> > > >> > work
> >> > >> > > >> > >> > in less than two weeks, I would definitely like it if
> >> you
> >> > >> were
> >> > >> > to
> >> > >> > > >> put
> >> > >> > > >> > >> this
> >> > >> > > >> > >> > in your own branch for testing.
> >> > >> > > >> > >> >
> >> > >> > > >> > >> > On Wed, Sep 10, 2014 at 12:41 PM, Andrew Grieve <
> >> > >> > > >> agrieve@chromium.org
> >> > >> > > >> > >
> >> > >> > > >> > >> > wrote:
> >> > >> > > >> > >> >
> >> > >> > > >> > >> > > I don't think there'd be much value in that. It'll
> >> be a
> >> > >> > single
> >> > >> > > >> > commit
> >> > >> > > >> > >> > > that almost entirely just deletes lines.
> >> > >> > > >> > >> > >
> >> > >> > > >> > >> > > What do you think about the never auto-pausing on
> >> > >> > > backgrounding?
> >> > >> > > >> or
> >> > >> > > >> > >> > > about auto-pausing when intent sending?
> >> > >> > > >> > >> > >
> >> > >> > > >> > >> > > On Wed, Sep 10, 2014 at 12:32 PM, Joe Bowser <
> >> > >> > > bowserj@gmail.com>
> >> > >> > > >> > >> wrote:
> >> > >> > > >> > >> > > > Can you put this on its own branch before it
> lands
> >> in
> >> > >> > 4.0.x?
> >> > >> > > >> > That'd
> >> > >> > > >> > >> be
> >> > >> > > >> > >> > > > awesome!
> >> > >> > > >> > >> > > >
> >> > >> > > >> > >> > > > On Tue, Sep 9, 2014 at 5:32 PM, Andrew Grieve <
> >> > >> > > >> > agrieve@chromium.org>
> >> > >> > > >> > >> > > wrote:
> >> > >> > > >> > >> > > >>
> >> > >> > > >> > >> > > >> For cordova-android 4.0, I'd like to go as far
> as
> >> > just
> >> > >> > > deleting
> >> > >> > > >> > the
> >> > >> > > >> > >> > > >> "KeepRunning" <preference>.
> >> > >> > > >> > >> > > >>
> >> > >> > > >> > >> > > >> Apps get a "pause" event when they are
> >> backgrounded,
> >> > and
> >> > >> > > they
> >> > >> > > >> > can do
> >> > >> > > >> > >> > > >> any pause-type logic there (e.g. unlisten to
> >> > >> accelerometer
> >> > >> > > >> > events or
> >> > >> > > >> > >> > > >> pausing audio).
> >> > >> > > >> > >> > > >>
> >> > >> > > >> > >> > > >> Any strong objections?
> >> > >> > > >> > >> > > >>
> >> > >> > > >> > >> > > >> On Tue, Sep 9, 2014 at 4:27 PM, Andrew Grieve <
> >> > >> > > >> > agrieve@chromium.org
> >> > >> > > >> > >> >
> >> > >> > > >> > >> > > >> wrote:
> >> > >> > > >> > >> > > >> > Commit description: If multitasking is turned
> on
> >> > >> > > >> > >> (keepRunning=true),
> >> > >> > > >> > >> > > >> > then temporarily disable it when starting a
> new
> >> > >> activity
> >> > >> > > that
> >> > >> > > >> > >> > returns
> >> > >> > > >> > >> > > >> > a result - such as camera.
> >> > >> > > >> > >> > > >> >
> >> > >> > > >> > >> > > >> >
> >> > >> > > >> > >> > > >> >
> >> > >> > > >> > >> > >
> >> > >> > > >> > >> >
> >> > >> > > >> > >>
> >> > >> > > >> >
> >> > >> > > >>
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> https://github.com/apache/cordova-android/commit/26adfb634651196106fb5b66f15eecb535a06d82
> >> > >> > > >> > >> > > >> >
> >> > >> > > >> > >> > > >> > Bryce / anyone - clues as to *why* we'd want
> to
> >> > >> disable
> >> > >> > JS
> >> > >> > > >> > timers
> >> > >> > > >> > >> > when
> >> > >> > > >> > >> > > >> > firing off an intent?
> >> > >> > > >> > >> > > >
> >> > >> > > >> > >> > > >
> >> > >> > > >> > >> > >
> >> > >> > > >> > >> >
> >> > >> > > >> > >>
> >> > >> > > >> >
> >> > >> > > >>
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> >
> >
>