← Back to team overview

ubuntu-phone team mailing list archive

Re: Background services: a problem that we need to face

 

Without long-running network connections, XMPP is at risk as well. Just
like IRC, you'd need a proxy or control the XMPP server to be able to send
push notifications. I guess there are a few more use cases where push
notifications won't cut it.

Generally, control and transparency are important to me. Control:
allow/disallow apps to use long-running background services. Transparency:
Be able to check if apps use the background service, for how long do they
use it, how many processor cycles are used for it, etc. Maybe even
notifications that display daily/weekly summaries of background task usage.

Obviously, most users are not interested in control and transparency, they
just want a phone that works and lasts long with a single charge. So I do
accept the very strict and conservative Ubuntu Touch approach. Nobody uses
XMPP or IRC anyways, and WhatsApp will happily send push notifications. I'd
still love to have the control in some kind of experts mode that doesn't
involve recompiling the Ubuntu stack.

Otherwise, a one-off app that simply requires a background task could
probably abuse push notifications and have a server send a new push
notification every minute to be able to do some processing. Or set a
geofence with the smallest possible radius, now really wasting energy. Or
abuse one of the other services. It's difficult to come up with apps that
require this. However, I could imagine apps that need to do some processing
that takes longer than a few seconds (like processing data that was
collected on the phone, maybe through sensors or from the internet, to
create statistics based on that data). Right now, the user is forced to
keep the app open and the screen active, or lifecycle policy will pause the
processing. I'm sure there are more use-cases that can't be solved using a
generic service.

Follow ups

References