ubuntu-phone team mailing list archive

[Baskaran S <baskarans.xl@xxxxxxxxx>]

The balanced solution would be let it to user decision. Let them decide. By
Default the OS can allow background process up to 'n' numbers. Let's say 3
(this can vary depending on device specification parameters: battery
capacity, screen size, CPU and memory). If user going to run beyond that
threshold 'n', the OS can warn the user whether they want to run this
process in background and give option to stop already running apps in
background.

On 1 October 2015 at 16:46, Sturm Flut <sturmflut@xxxxxxxxxxxxxx> wrote:

> Good morning dear list,
>
> this has been brewing for quite some time now and the discussion
> Krzysztof Tataradziński started a week ago didn't lead anywhere again,
> so I'm starting it yet another time:
>
> In my opinion the "no background processing for apps on the phone"
> design decision is wrong, is already hurting us too much and has to be
> revoked as soon as possible.
>
> Why? Let me make a list of examples.
>
> - Open Telegram for Ubuntu, send a picture to a friend, switch to
> another app or scope. On any other platform the message would continue
> to be sent in the background, but not on Ubuntu. Now you might say
> "Telegram is going to become a Telepathy plugin, and that one can run in
> the background", but there is no sign of a Telepathy system service and
> even if it were already present, you're now forcing everybody to build
> Telepathy plugins for their services. That's just not going to happen.
> Let's be honest, WhatsApp and Viber and friends will not go this way for
> a number of very good (economic) reasons.
>
> - Notifications for the myriads of services out there. On any other
> platform the app would just register a small background service that
> wakes up every minute or so and then goes to sleep again. Now you might
> say "We have the Ubuntu Push Notifications service for that", but that
> requires the service provider to change his whole server side, which
> noone except Telegram does. That's why we already have to run
> account-polld.
>
> - An app that processes location updates in the background, e.g. a
> fitness tracker or a navigation app. Now this is IMO the best example
> for how the "no background processing" decision complicates everything
> to infinity: The simple solution would be to have a small background
> service that just does whatever it has to do. But since we can't do
> that, we have to come up with a very convoluted system that most likely
> involves registering for some list of events with location-service,
> which then calls a small handler binary provided by the app (like the
> push notifications design). But how do you prevent that handler from
> running amok, or from just keep running in the background? Ah, yeah,
> kill it after five seconds, like the push notification handlers. But
> five seconds on a slow CPU aren't much when I e.g. also have to do some
> I/O and use D-Bus, while five seconds on a fast CPU are a lot of time if
> I don't have to do much. So what's the right maximum runtime for a
> handler that covers all use cases? There is none. Will location-service
> support all the event/filter/callback options I need for my specific
> app? Most likely not.
>
> - Cloud and P2P services like Owncloud, Dropbox, Syncthing, Tox etc.
> Apps that control devices via Bluetooth, like my FitBit or a Smartwatch.
> What's the design for those? More system services? We can't afford to
> write a system service for each and every use case. That doesn't scale.
> It already isn't scaling right now. And even if we could, is the
> proposed solution really to have 100 system services running for all
> users, instead of five to ten third party background processes that the
> user really needs and knowingly installed herself?
>
> I can come up with many more examples for how this is simply
> complicating our lives, and for what reason? A (tiny) gain in battery
> life. We have many apps that cannot be built/ported right now because we
> are waiting for APIs and system services that haven't been coming for a
> year now and only have to be created because we can't just run in the
> background. Do we even know if the effect on battery life is really
> worth it? I challenge you to run e.g. Dekko as a lifecycle exception and
> check if the background polling is noticeable. Because it's not like
> those system services don't consume any resources at all, the work has
> to be done by somebody. A "bad" Telepathy plugin will consume just as
> much resources as a "bad" background process, the "better" design of
> using Telepathy alone is not going to prevent this.
>
> What also really confuses me about this issue is that the "no background
> processing" approach apparently only applies to mobile devices and
> confined apps. Isn't that somehow against the whole idea of an Ubuntu
> that is the same on all devices?
>
> I would really like to hear all your thoughts on this and how we're
> going to solve the situation, because we quite frankly have actual
> problems (broken GPS, no SD card support for apps, no Bluetooth, no SIM
> Toolkit, etc.) which should have a much higher priority than building
> convoluted and complex designs just to potentially save three hours of
> battery life over the course of a week.
>
> cheers,
> Simon
>
> --
> 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
>