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 : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
