cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Android: activityResultKeepRunning
Date Fri, 12 Sep 2014 19:24:51 GMT
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