ubuntu-phone team mailing list archive

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

On Wed, Jun 25, 2014 at 4:23 PM, Benjamin Zeller
<benjamin.zeller@xxxxxxxxxxxxx> wrote:
> Am 25.06.2014 16:16, schrieb Thomas Voß:
>> 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.
> Thats why I was proposing the heartbeat solution.
> Every service that needs that, would have to register to it.
> IF there is nothing registered, the phone does not need to wake up.
>

Sure, but we would still wake up for the sake of waking up. As opposed
to waking up due to an actual event coming in (a push notification,
significant distance travelled, significant movement).

> The heartbeat could be used even for our services, if we need to do
> something
> like that. It should save battery time, because its cheaper to wake up
> the phone
> once to do n tasks than waking up n times.
>

I think we don't have sufficient numbers to back that statement,
specifically in the case of opportunistic suspend as known from the
Android world.

Cheers,

  Thomas

> Cheers
>
> Benjamin
>>
>> 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
>>>
>