ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #04764
Re: Thoughts on inhibiting app suspend via application lifecycle
On Tue, Oct 22, 2013 at 8:06 AM, Alberto Mardegan <
alberto.mardegan@xxxxxxxxxxxxx> wrote:
> The case of an application using the GPS is interesting. The nice
> thing here is that the system can know that the GPS is on and that the
> application is listening to it, so it could let the application run
> even when in the background, without the need for a specific policy flag.
> Conversely, if the GPS is off, there's generally no point in letting a
> GPS application to continue running, and it could be stopped.
>
It is worth nothing that application that is listening to GPS in
'foreground' doesn't mean the app should keep working/the phone awake. For
example, an app that attaches GPS location to a post, while we're on the
edit screen, need not keep the device (or, GPS, for that matter) on. The
system could safely go to sleep, instead draining power if the user left
the app on the edit post page. On the flip side, as it has been already
noted, there's a number of apps that require GPS on, even when they move to
background. I personally find Android APIs convenient in that respect. It
is the responsibility of the developer to consume as little power as
possible, otherwise the app would get bad reviews. While I find the idea of
containing the resource resolution as a platform responsibility
interesting, if we go that route, I think we'll overcomplicate the solution
to the problem.
As far as UI/daemon split is concerned, that makes perfect sense
(incidentally, just like on Android). Whether the metronome should ship
with a deamon - perhaps that's too much, but why not? We should recognize
the fact that it is complicated to communicate with background services as
area for improvement on our end.
Cheers,
karni
--
Software Engineer
Professional and Engineering Services
Canonical Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Follow ups
References