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 <to...@devgeeks.org> wrote: > Biiiiig -1 for breaking current background behaviour. > > Or am I misunderstanding? > On 11 Sep 2014 10:34, "Joe Bowser" <bows...@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 <agri...@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" <mmo...@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 <bows...@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 < >> agri...@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 <bows...@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 < >> > agri...@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 < >> > agri...@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? >> > >> > > > >> > >> > > > >> > >> > > >> > >> > >> > >> >> > >>
