cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Android: activityResultKeepRunning
Date Thu, 11 Sep 2014 18:58:41 GMT
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?
>> > >> > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> >
>>

Mime
View raw message