ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On Wednesday 25 June 2014 12:47:02 Marc Deslauriers wrote:
[snip]
> As I said, I don't want to prevent background services, I want us to do it
> in a way that most people would find reasonable, and using the principle of
> least astonishment. I'm pretty sure when people close their flashlight app,
> they don't expect it to be running in the background and tracking their
> location.

That's why I for one (as a user and a developer) would be really happy with 
the option for the user to allow an app to be kept running (as in running, not 
suspended). Sort of like this:

An app indicates that it has features which require to keep running and 
processing data. If the user starts that app for the first time, the system 
asks the user: "App X asks for permission to keep processing data even while 
the display is off. Please note that this might affect your battery lifetime. 
Accept/Decline. (You can change this setting in the system settings at any 
time)".

If the user declines, the app will be suspended when unfocused and some 
features might not work. If the user agrees, the app would not be suspended 
and support all the use cases that came up in this thread. However, if the 
user closes the app's window, that would also stop the process in any case. 
That would make it quite clear to the user what's running and what isn't.

I'd also be fine if this question only pops up if the user has qualified as 
power user (e.g. a setting to enable this advanced stuff) and just decline it 
automatically for non tech savvy people.

If the developer needs to do things even when the app is completely closed, 
that's when a set of restrictive, predefined system services like push 
notifications etc should help out.


I'm not really concerned about the app being quit by the out of memory killer. 
If we're out of memory we're out of memory, there's not much we can do about. 
Maybe the OOM killer could try to stop non-background enabled apps before 
others and try to be smart in order to minimze the risk of interrupting such a 
background task...

br,
Michael