ubuntu-phone team mailing list archive

[Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>]

Am 25.06.2014 12:36, schrieb Florian Will:
> 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.
That would be neat, but probably should be hidden in some expert view to
not confuse the average user
>
> 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.
IRC was just a example, what about things like spotify, as soon as you
lock the screen or put the app in background music will stop, which
renders it useless
like Rasmus said it before. And with the cheap mobile internet streaming
music to your phone is quite common today.
>
> 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.
That's why we should have a way for the background task to tell the
system, "hey I need to wake up every n minutes", maybe something like a
heartbeat signal that is
sent to all background services that are registered for the signal, so
the phone wakes up one time, triggers all background processing and then
goes back to sleep.
This should use less battery than giving the background process a way to
wake up on its own with a timer.

> 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.
Forcing the user to have the app open is imho not the way to go, other
smartphone platforms have solved this.
>
>