ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On Friday 25 October 2013 09:56:03 Thomas Voß wrote:
> 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.

The communication between the background task either needs to be based on and 
limited to some generic format (i.e. jsonrpc). To do more (for example D-Bus), 
interface, type descriptions, serializers etc need to be available and end up 
on the app developer's plate somehow. I don't see yet how this would be 
flexible/powerful and transparent to app developer at the same time.

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

I don't think this capability would be set by default and also only turned on 
by apps that require it.

For the user maintaining a list of running apps: We are introducing new stuff 
to learn for the user every day. I don't see why the one thing that has been 
around on every computing device since multitasking got invented (closing 
apps) should be the one a user can't handle. You don't require a mental model 
for that. Each time you use the right edge you get presented with all the stuff 
hanging around. Having an easy way to dismiss unused stuff would not be that 
hard to get I think.

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

I don't see this as easing up our work. As you said there is a considerable 
amount of efforts on our side to handle this. I think this is rather giving 
developers and users more control of their products and devices. Actually to 
me it seems just freezing an app is the "ease our work" path but with the cost 
of lost features and more complicated app development.

There are examples out there which don't even do this optimizing stuff and 
still run very well in terms of battery life and performance, even with 
multiple running apps.

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

I'm not familiar with details on AppNap, but just testing it for 5 minutes on 
my gf's macbook makes it seem like something optional the app can (and should) 
support, instead of freezing all the apps. Which would be more closer to my 
approach I'd say.

Br,
Michael

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