Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAEeF2TcxM9hd_k+ZPp9kYEB1UZbmadL7VcQhkVBvVQpBFYLioQ@mail.gmail.com>
References: 
 <CABiQX1UYp6+wQBjVY0Peff48-3ntP5QD=oXNVvfZCfBf0gQSng@mail.gmail.com>
	<CABiQX1V-H2F2zshGte44tXpAuvyaekr+om=8ez=tDsZANTCg0Q@mail.gmail.com>
	<CAOBL_k5qEXry=e4-V0qTyB4LdpFPFdCMnHHP44LYQyn68Poyhw@mail.gmail.com>
	<CABiQX1WakAddjLwid4bJkPFdypLJfQ=R6UfHmy9Xp3H=5Wvb-w@mail.gmail.com>
	<CAOBL_k4Ndx31hVH9TO+qr_CGw212KqGUs9mkvKz+d6CCj7UACA@mail.gmail.com>
	<CAEeF2TcxM9hd_k+ZPp9kYEB1UZbmadL7VcQhkVBvVQpBFYLioQ@mail.gmail.com>
Date: Wed, 10 Sep 2014 13:56:47 -0700
Message-ID: 
 <CADVgkyObVT+Lom42cahWGvRDzZG4-JnKB385EzqH69PC726jig@mail.gmail.com>
Subject: Re: Android: activityResultKeepRunning
From: Brian LeRoux <b@brian.io>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=90e6ba6e8fb84feee60502bc4a4c

--90e6ba6e8fb84feee60502bc4a4c
Content-Type: text/plain; charset=UTF-8

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?
> > > >
> > > >
> > >
> >
>

--90e6ba6e8fb84feee60502bc4a4c--