ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On Friday 25 October 2013 09:35:26 Michael Zanetti 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.
> 
> 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.

Oh, and I forgot. In the UI it should be really, I mean *really* easy for the 
user to close an app. It should be no more efforts than bringing it to be 
background (e.g. just swiping from another edge, or ending the minimize swipe 
on a certain spot). That will cause the user to close more stuff when he 
doesn't need. Would have the additional benefit that the right edge gesture 
actually becomes useful again because there aren't 10 apps to cycle trough in 
order to find the wanted one.

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