ubuntu-phone team mailing list archive

[Rick Spencer <rick.spencer@xxxxxxxxxxxxx>]

On Tue, Mar 11, 2014 at 5:05 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas Voß wrote on 10/03/14 12:36:
> >
> > On Mon, Mar 10, 2014 at 1:13 PM, Matthew Paul Thomas
> >
> > ...
> >> That would result in you getting cut off a Skype call, for
> >> example, when the person you're talking to gets you to check your
> >> calendar. Or a recording app failing whenever you read the script
> >> or the music that you're trying to record. Assuming that gets
> >> fixed eventually, users would experience less churn if there was
> >> a single design for returning to phone calls before it's fixed,
> >> and returning to other recording apps after it's fixed.
> >
> > I disagree here. We have spent a significant amount of time on our
> > lifecycle story and on establishing, implementing and supporting a
> > strict lifecycle policy on the phone. With that, I'm surprised by
> > such a statement. I would have expected that our designs by now are
> > aligned with such a fundamental platform decision.
>
> Sorry, I'm not sure which part you disagree with.
>
> Is it correct that if recording/listening apps can't run in the
> background, then you would get cut off a Skype call, Google Hangout,
> Yahoo Messenger call, WhatsApp Voip call, or any WebRTC call when you
> switched to a different app?
>
> Do you agree that Ubuntu Touch should be a platform on which ISVs like
> those can make apps as useful as their apps on other platforms?
>
> If so, do you agree that the current lifecycle model would need to be
> only a first iteration, rather than a permanent restriction? Or is
> there some other way around the problem?
>
Even everyone agrees that such apps should "work" when in the background.
The question is the implementation of how to make them work. Letting them
"just run" is one implementation, but it is not one that we are using. We
are, rather, providing system services that apps can use and offload such
functionality to the system and they can be controlled and not abused.

I suggest that we focus on the requirements (a communication app can
continue to function when another application is active) rather than the
implementation that achieves the requirement.

Cheers, Rick