You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2014/09/09 22:27:21 UTC

Android: activityResultKeepRunning

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 Joe Bowser <bo...@gmail.com>.
On Wed, Sep 10, 2014 at 1:46 PM, Michal Mocny <mm...@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?
>

Given when they are discovered (right before release), I consider it a sign
of that the system is broken.  This delayed the release of 3.6.1 a fair
bit, which I personally consider a bad thing.


>
> 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.
>

1. It's not a feature branch.  This is a branch for the eventual release of
4.0.x.  I introduced the many webviews code in a feature branch before it
landed.
2. It's up to the person who is introducing the feature to get us
interested in the feature branch.



>  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.
>
>
Actually, it makes the eyeball problem worse.  We want MORE eyeballs on
4.0.x, and that works by actually demoing stuff that people can reproduce
with that branch.  We want to show something that we're planning to release
soon, not demoware.  Also, it make us accountable to our users, which is
important to some of us.


> -Michal
>
> On Wed, Sep 10, 2014 at 3:50 PM, Joe Bowser <bo...@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 <ag...@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 <bo...@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 <ag...@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 Joe Bowser <bo...@gmail.com>.
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 mean Hello World with a minor change to the XML/  We could pause on the
activity, but it looks like the issue is more serious now, and that if you
resume, you will never fire the DeviceReady event.  That's why Crosswalk
removed it and did the new event-based system.  Instead of the problem
being with Chromium resuming at the right time, if it even resumes at all.


> >
> > 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 <ic...@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?
> >> > >> > > >> > >> > > >
> >> > >> > > >> > >> > > >
> >> > >> > > >> > >> > >
> >> > >> > > >> > >> >
> >> > >> > > >> > >>
> >> > >> > > >> >
> >> > >> > > >>
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> >
> >
>

Re: Android: activityResultKeepRunning

Posted by Joe Bowser <bo...@gmail.com>.
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 Joe Bowser <bo...@gmail.com>.
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 <ic...@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 Archana Naik <na...@gmail.com>.
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.

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 <ic...@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>.
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 <ic...@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 <ka...@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 <to...@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" <mm...@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 Joe Bowser <bo...@gmail.com>.
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.

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 <ic...@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 <ka...@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 <to...@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" <mm...@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 Ian Clelland <ic...@chromium.org>.
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 <ka...@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 <to...@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 <ag...@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" <mm...@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 <bo...@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 Andrey Kurdumov <ka...@googlemail.com>.
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 <to...@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 <ag...@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" <mm...@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 <bo...@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 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 <to...@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 <ag...@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" <mm...@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 <bo...@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 <bo...@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 Tommy Williams <to...@devgeeks.org>.
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 <ag...@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" <mm...@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 <bo...@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 <bo...@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 Joe Bowser <bo...@gmail.com>.
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 <ag...@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" <mm...@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 <bo...@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 <bo...@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>.
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" <mm...@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 <bo...@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 <ag...@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 <bo...@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 <ag...@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 Brian LeRoux <b...@brian.io>.
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" <mm...@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 <bo...@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 <ag...@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 <bo...@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 <ag...@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 Michal Mocny <mm...@chromium.org>.
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 <bo...@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 <ag...@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 <bo...@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 <ag...@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 <ag...@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 Joe Bowser <bo...@gmail.com>.
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 <ag...@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 <bo...@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 <ag...@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 <ag...@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'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 <bo...@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 <ag...@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 <ag...@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 Joe Bowser <bo...@gmail.com>.
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 <ag...@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 <ag...@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>.
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 <ag...@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?