ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Fri, Oct 25, 2013 at 9:35 AM, Michael Zanetti
<michael.zanetti@xxxxxxxxxxxxx> wrote:
> On Thursday 24 October 2013 15:36:11 Rick Spencer wrote:
>> On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge
> <jamie@xxxxxxxxxxxxx>wrote:
>> > On 10/24/2013 02:00 PM, Rick Spencer wrote:
>> > > It's been interesting to read all the expected use cases, and also the
>> > > requirements for application developers. It's good to think hard about
>> >
>> > how we
>> >
>> > > fulfill these requirements, and do it well.
>> > >
>> > > What I liked about Thomas's first iteration of the application life
>> >
>> > cycle, is
>> >
>> > > that it is clean, simple, comprehensible, and works. To me, it seems
>> >
>> > that as an
>> >
>> > > app developer you get:
>> > > 1. the ability to do what you want when your app is in front and the
>> >
>> > phone is
>> >
>> > > not idle.
>> > > 2. a set of services via well known APIs to call for things where your
>> >
>> > app may
>> >
>> > > not be in front (i.e. music service, download service, alarm service
>> >
>> > etc...)
>> >
>> > > I think that instead of thinking of ways to grant applications long
>> >
>> > running
>> >
>> > > processes, we should grow these services. For example, it sounds like a
>> >
>> > location
>> >
>> > > service may be required, etc...
>> >
>> > I think that is where we landed:
>> > https://lists.launchpad.net/ubuntu-phone/msg04766.html
>> >
>> > Ie, we build out our services but application developers also have a way
>> > to
>> > implement their own background service if they need to.
>>
>> So I am saying the opposite. Rather than allowing apps to create background
>> services I think we should stick to the original vision. Apps use well
>> known APIs for their functionality, or the the user keeps the app in front
>> and alive on the phone. I think there should be no "background processes"
>> other than what is available on the base system. This system we have
>> started down is clean, simple, and very hard to subvert. The hard part is
>> providing the correct set of APIs so that app developers do not wish they
>> could write such services.
>>
>> I think that if we go down the path of allowing folks to write background
>> services, then we may as well just allow the app to run in the background.
>
> I agree. Why introduce all the complexity of IPC? It will bring in issues for
> sure, besides killing any portability from other platforms as apps require
> major architectural changes in order to be split into app + service. For the
> user, the only outcome of those background services is that it's even harder
> to understand what is there running and consuming the battery.
>

Well, a user shouldn't have to care (I'm talking in terms of the
average phone/tablet user here). For IPC: I'm not convinced that we
would need to expose such a low-level detail to developers under the
assumption that we provide a sensible middleware/abstraction that
easily allows a developer to define tasks. Communication then is on
our plate and we can solve it in a central place.

> I do not agree on the opinion that we should _only_ allow system services, as
> that will create a tremendous amount of required features for those daemons
> and still make a lot of use cases impossible because we can't handle all. I do
> think that for as many use cases as possible we should go for system services,
> but not restrict apps to only have those.
>
> Why not just adding a capability for running in background? AFAIK it is
> planned to allow the user granting/rejecting single capabilites. Rejecting
> that capability would still cause the app to be stopped (with all the
> implications that brings ofc) if the user wants so.
>

Opening up a capability like that will almost surely be set as a
default and we would pass on the responsibility to the user to handle
and maintain the list of running apps. I'm especially concerned about
forcing the user to deal with process states and requiring a mental
model of how an app is executed on the system.

> Additionally we should help the developer optimize his app, e.g. with clear,
> well documented signals on when UI updates should be stopped/minimized because
> in the background. Access to hardware resources (e.g. GPS updates, network
> bandwith etc) could be limited and slowed down. We could have a watchdog that
> checks for excessive CPU usage and still stops a background app if we feel
> it's behaving too nasty because of bad implementation. And there are more
> things I could think of in terms of saving battery. But I still think freezing
> an app and require the developer to implement background services just brings
> unneeded complexity with only little benefit.
>

To make this point very clear: Yes, we could do all of this (which is
a significant amount of effort) and still could not guarantee good
performance and good battery life. On top, we would pass the
responsibility on to the user and to the developer "just" to ease our
work.

> IMO key is to support the developer in making good stuff, instead of locking it
> down and forcing it to find workarounds for still delivering the use case he
> needs.
>
>>
>> For completeness, I would expect a different policy to be in force when
>> running on a desktop. I could imagine that in desktop mode the policy
>> allows applications to run in the background. However,that is a discussion
>> for later ;)
>
> Having such a set of helpers for saving battery, or a watchdog that informs
> the user of excessive background resource wasting would be useful for th
> desktop too. While I don't think the forceful freezing of applications would
> work reasonably well on traditional desktop apps anytime soon.

Look at Apple's AppNap is a great example of transitioning a strict
lifecycle model to the desktop use-case and maximizing power saving.

Thomas

>
> Br,
> Michael
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp