If anyone is interested, windows phone is doing it in a similar way: Apps will be stopped when in background but can register special trigger for specific tasks. The executed background tasks will only receive a limited amount of CPU time and network bandwith:
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh977056.aspx Am 22.06.2014 17:43, schrieb Fabio Colella: > Currently the app lifecycle may kill an app in any moment if the app > is not on focus. Most of the apps are designed to be used when > focused, but there are many other apps that require to work even when > not in focus, many examples: > > * Running apps: should count calories and distance even when not focused > * Data Sync (Dropbox, OneDrive, GoogleDrive): should continue the > up/download and syncronization when not focused. > * Torrent apps(Transmission) > * IRC and messaging platforms not covered by "Online Accounts" > * Custom Keyboards and Lockscreens (this needs even more work) > * Firewalls, antivirus, antispam (may become useful when *the > platform becomes popular*, we should take them in account) > * Other things to which I'm not currently thinking to but that may > be useful > > > The current approach is to use system services to achieve the results: > this is what happens with music and messaging apps. The problem with > this approach is that we may end up with the need to create really > many services and still not cover all the needed requisites. On the > other hand we may just deny the developers and the users to create and > use certain kind of apps. The advantages of not allowing background > services are mainly longer battery life and better overall performances. > > I think we should *find a compromise that allow the user to use apps > that need background services but also makes him/her free to > stop/resume them.* > > My idea for background services: > > * should need an Apparmor permission > * should warn the user that the app uses background services > * should be killable/pausable by the user and visible in the home > scope and or in the notification area > * could be autokilled/paused when battery life is low (this approach > is the one used by Samsung, Google Drive, Dropbox) but should > still allow the user to resume the service if he/she needs it even > on low battery > * could be paused/resumed according to the number of running apps > and services > > My consideration is that the user should always end up being able to > decide what he/she want's to use and when. We put conventions (like > stop on low battery) over user configuration, but the user should > still be *free* to change it. > >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
