Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of bowserj@gmail.com designates
 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAK_TSXKO+Y5AXqhK6+NamJMuzEAXVDnW1fVORj_a_vEfNthXZw@mail.gmail.com>
References: 
 <CABiQX1UYp6+wQBjVY0Peff48-3ntP5QD=oXNVvfZCfBf0gQSng@mail.gmail.com>
	<CABiQX1V-H2F2zshGte44tXpAuvyaekr+om=8ez=tDsZANTCg0Q@mail.gmail.com>
	<CAOBL_k5qEXry=e4-V0qTyB4LdpFPFdCMnHHP44LYQyn68Poyhw@mail.gmail.com>
	<CABiQX1WakAddjLwid4bJkPFdypLJfQ=R6UfHmy9Xp3H=5Wvb-w@mail.gmail.com>
	<CAOBL_k4Ndx31hVH9TO+qr_CGw212KqGUs9mkvKz+d6CCj7UACA@mail.gmail.com>
	<CAEeF2TcxM9hd_k+ZPp9kYEB1UZbmadL7VcQhkVBvVQpBFYLioQ@mail.gmail.com>
	<CADVgkyObVT+Lom42cahWGvRDzZG4-JnKB385EzqH69PC726jig@mail.gmail.com>
	<CABiQX1V-pbz8VpOXPev0ufp38uBfOecGPYPbL6ysqJx2S6rd=A@mail.gmail.com>
	<CAOBL_k4ab7P2gET-q35ey0tmdUDHp6P+juPH0n0SYZORFN+eSA@mail.gmail.com>
	<CAPTyS6BOR1N6SVSKA5h7a2BqvcFv-DscQe8UnCKQY-gxd2gAXA@mail.gmail.com>
	<CABiQX1WegBQKcc8uhE5Mp=uu8_N0H60bHiswOLGKyvv+RDQdSg@mail.gmail.com>
	<CAAY=exiCw2kBOKyJrN+GKz3Zf6r7zfW5QVC7dfFaKY5ZZ6bwXw@mail.gmail.com>
	<CAK_TSXKO+Y5AXqhK6+NamJMuzEAXVDnW1fVORj_a_vEfNthXZw@mail.gmail.com>
Date: Fri, 12 Sep 2014 10:02:31 -0700
Message-ID: 
 <CAOBL_k4u9qVLpxXmFTQD+1EmWcKeXnqSq57acMxK9AyTEHihZg@mail.gmail.com>
Subject: Re: Android: activityResultKeepRunning
From: Joe Bowser <bowserj@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec51dd27f36ad850502e140f3

--bcaec51dd27f36ad850502e140f3
Content-Type: text/plain; charset=UTF-8

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 <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 <agrieve@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" <bowserj@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?
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >>
> > > >> >
> > > >>
> > >
> >
>

--bcaec51dd27f36ad850502e140f3--