cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archana Naik <naik.arch...@gmail.com>
Subject Re: Android: activityResultKeepRunning
Date Fri, 12 Sep 2014 17:34:01 GMT
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 <agrieve@chromium.org>
wrote:

> On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser <bowserj@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 <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?
> >> > > >> > >> > > >
> >> > > >> > >> > > >
> >> > > >> > >> > >
> >> > > >> > >> >
> >> > > >> > >>
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message