ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Wed, Jun 25, 2014 at 1:31 PM, Benjamin Zeller
<benjamin.zeller@xxxxxxxxxxxxx> wrote:
> 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.
>

XMPP powers a wide variety of applications, and nothing in our system
prevents general XMPP from working.
As pointed out earlier, most communication app use-cases can be solved
elegantly with the push notification service.

> 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.
>

Great, I think the Unity8/Unity api team would be glad to get some
help in implementing such detailed views and make them available to
power users. Those views and notions should not be required for an
"average" user to use the phone.

> 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.
>

@spotify: If possible, we should work towards music hub integration.
The obvious benefit is the lifecycle escape path, another one that it
helps with reusing functionality across the 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.
>

Well, we do rate-limiting in multiple parts in the push stack. In
addition, the app-specific push notification helper can only translate
to notifications, nothing more and its confinement profile is
extremely strict.

> 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.
>

We have that, it is called cron :) I don't think it is the appropriate
solution for the problems presented here, though. The reason is
simple: why would we wake anything (including the phone) from deep
sleep just because a timer expires? I have no objections against
service-specific helpers, but we should only ever take action if
action is required. A recurring timeout is a naive sampling solution
to the problem.

Cheers,

  Thomas

>
> 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.
>
>
>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>