Created an issue with proposed changes:
https://issues.apache.org/jira/browse/CB-7947. Let's move discussion there.
On Tue, Oct 21, 2014 at 12:03 PM, Andrew Grieve
wrote:
> 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 t
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 wrote:
> So, what's going on with this? Did this
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 wrote:
>
>
> On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik
> wrote:
>
>> We have tested this behavior and in fact AmazonWebView which was and is
>> always based on chromium, we
On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik
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, th
On Fri, Sep 12, 2014 at 10:21 AM, Andrew Grieve
wrote:
> On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser 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, a
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
wrote:
> On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser wrote:
> > After testing this
On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser 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 a
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
breakin
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
wrote:
> Hi,
>
> I periodically check how
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 pa
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, an
Big -1 for breaking current background behaviour.
Or am I misunderstanding?
On 11 Sep 2014 10:34, "Joe Bowser" 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.
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 G
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
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" wrote:
> Question is, do you consider the fact that bugs are introduced & discovered
> (possi
On Wed, Sep 10, 2014 at 1:46 PM, Michal Mocny 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?
>
Given when they are discovered (right before release), I consider
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
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 l
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 wrote:
> Can you put this on its
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 wrote:
> For cordova-android 4.0, I'd like to go as far as just deleting the
> "KeepRunning" .
>
> Apps get a "pause" event when they are backgrounded, and they can do
>
For cordova-android 4.0, I'd like to go as far as just deleting the
"KeepRunning" .
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, And
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 w
22 matches
Mail list logo
