ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

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.

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.

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.

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.

Br,
Michael