ubuntu-phone team mailing list archive

[Sturm Flut <sturmflut@xxxxxxxxxxxxxx>]

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