ubuntu-phone team mailing list archive

[Krzysztof Tataradziński <ktatar156@xxxxxxxxx>]

Hello,
I want submit only one small note

2015-10-01 14:04 GMT+02:00 Thomas Voß <thomas.voss@xxxxxxxxxxxxx>:

> Hey Simon,
>
> Thanks for your thoughts and ideas. Please find my suggestions and
> replies inline:
>
> On Thu, Oct 1, 2015 at 1:16 PM, 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.
> >
>
> To state this very clearly: We are looking at a continuum of potential
> solutions here.
> It is unfortunately not as simple as just revoking one solution and
> picking another one, but
> all the different objectives have to be balanced. To this end, let me
> clarify some of the guiding
> principles and objectives that have to be accounted for in the context
> of lifecycle policies:
>
> (1.) Battery life: One of the scarcest resources on a mobile device
> and something that we aim
> to protect as much as possible. Allowing arbitrary background
> processing hurts a lot here, with Android's
> lifecycle approach being one of the examples where battery life
> deteriorates and becomes unpredictable
> depending on the apps that have been installed on the device. Now this
> wouldn't be a problem for the
> quite technical audience subscribed to this mailing list. But it is
> certainly an issue for the average user who
> should not be forced to maintain a list of running apps and processes
> just to achieve sensible battery life.
>
> (2.) Security & privacy: One of the worst case examples are apps
> running in the background, feeding on a device's
> sensor data and sending it off to the cloud. There have been numerous
> examples exploiting the issue on Android.
> Again, the technical audience subscribed here would be fine, the
> average user likely is not.
>
> (3.) Predictable performance: A phone is expected to perform whenever
> it is needed to, and the application being front & center
> to the user should provide a smooth and crisp experience. To this end,
> the system has to be able to assign as much performance-relevant
> resources as possible to the currently focused app. If arbitrary
> background processing is allowed, the respective scheduling problem
> becomes
> very very hard to solve (if possible at all).
>
> Please note that there are way more aspects to this problem space than
> just the three points I elaborated on before.
> The key point is: For a technical or tech-savvy audience, the
> lifecycle approach we are taking for the phone might seem overly
> restricted.
> However, for the average user, such a harsh policy comes with a lot of
> benefits.
>
But average users don't want to use phone that is limited in that way.
For now that system is for some technical guys; if we want to target Ubuntu
Touch for larger audience we need provide ability to work apps in
background - why people use smartphones a lot of time? Because they can
track their sports, use their favorite chatting app (and get notifications
from it, even when it's 'closed'), get synced data from cloud, get notify
about attack on their castle in favorite online game, etc.
If we don't allow to do that things in easier way, Ubuntu will don't get
too much big market apps, consequently Ubuntu will don't get too much
non-technical users and that harsh policy wouldn't be useful for any one -
there will be no people to appreciate that harsh policy.

>
> > 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.
> >
>
> That's actually not true in the general case. Most often, the services
> use the platform's push notification
> infrastructure to deliver updates. Please note that we require
> account-polld to work around the limitation that
> facebook, twitter and google have not integrated with our infrastructure
> (yet).
>
> > - 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.
> >
>
> It will grant a certain amount of processing time to your app or
> better its location update helper. A fitness tracker could easily just
> store
> the respective update for later processing. A navigation app would
> require more sophisticated schemes, but we are happy to evolve the
> service as required (as pointed out earlier).
>
> > - 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?
> >
>
> We would not write a system service for each of them, but instead
> provide a framework to handle the specific problem area.
> It is a lot of work to get those frameworks right, and your help is
> obviously greatly appreciated in doing so. Other than that, it is
> really really easy
> to integrate cloud services with the content-hub infrastructure and
> thus exposing the content in the system.
>
> > 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.
>
> Please see the initial list of objectives and guiding principles. On a
> very personal note, I don't think the aim should be to make "our" life
> easier but
> to make the life of users as pleasant as possible. If that means to
> come up with novel and probably harsh solutions and policies to
> address certain
> problems ... that's what it is.
>
> 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.
> >
>
> They do consume resources, for sure. The point is: A fixed set of
> system services controlled and maintained by us results in predictable
> battery life (modulo bugs).
> The real question is not if battery life would deteriorate for
> allowing a specific app to poll in the background. Instead, the
> question has to target the general behavior of
> the system with arbitrary apps being installed in the system.
>
> > 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?
> >
>
> It certainly is not. A lifecycle policy is always specific to a
> device, its resources and even the specific usage scenario.
> With that, allowing multiple apps to run even if not focused in
> desktop-like use-cases is perfectly fine. Even altering the behavior
> in case of a phone being plugged in to a power supply would be perfectly
> fine.
>
> > 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.
> >
>
> As pointed out in my introductory comment: battery life is one of
> multiple concerns we have to address.
>
> Cheers,
>
>   Thomas
>
> > 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
>
> --
> 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
>