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 Tue, 21 Oct 2014 16:03:54 GMT
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 <bowserj@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 <bowserj@gmail.com> wrote:
>
> >
> >
> > On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik <naik.archana@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 <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