4 ms·
Every single app that uses notifications needing to run in the background is not a scalable solution.. Even correctly behaving apps will consume much more powe
by thebean11 5y ago
Every single app that uses notifications needing to run in the background is not a scalable solution..
Even correctly behaving apps will consume much more power and network with this scheme.
- Andrew_nenakhov 5y agoImagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer? It is not up to the OS to decide which apps the user needs running. Be it wifi scanner, vpn or some file sync process. All the user needs is a correct tool to know which app consumes what, and then there User must decide. Not some prick in google or xiaomi or samsung or whoever else.
- thebean11 5y agoI’m not saying apps shouldn’t be allowed to run in the background. But for notifications specifically it’s an unacceptable solution. It just doesn’t scale to the number of apps the average user receives notifications from.
- Andrew_nenakhov 5y agoNobody was saying that every app needs to run in the background to deliver you notifications. I was arguing that for some apps background functionality is essential, and such functionality is obstructed by OS vendors, who strive to tie all background work to push notifications.
- thebean11 5y agoSure, I agree with you there, but background app permissions and push notifications seem like pretty separate issues.
- Andrew_nenakhov 5y agoThey are totally not, because whenever you need an app do something, like, display a message sent to you, the 'official' way is to do it via push notifications. But if your user doesn't use Google Play services, you have to make the app run in the background, which is increasingly difficult in Android (and impossible in iOS).
- shadowgovt 5y agoHypothetically, an Android vendor could build a notification service separate from Play Services and deploy it on their Android builds. Has to be a vendor (or, more broadly: "someone who controls the OS down to the kernel level") because the notification technology involves some heavy abstraction-breaking footsie between the physical link layer and the TCP stack. But the two big challenges there are: - odds are the first several iterations of it will suck, so they'll be competing with an already-working solution that most users have no concerns using (significant market uphill fight, with the only major value-add being "We're not Google"). - we've just traded one master for another. Ultimately, unless someone builds an open-standard at the Android distro level that includes an API to allow users to establish a notification source, the distro owner still owns the notification system (and there's no reason a priori to assume they're less evil than Google). And designing that API to be abuse-proof would be a challenge; do it wrong, and we're back to the bad old days of sub-one-day battery life on an idle phone. It'd be a hell of a cool project for someone to take on though.
- izacus 5y ago> Imagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer? Your macOS has an unacceptable battery life already despite having a massive 58WHr battery - about 3.5x the size of a normal phone battery. Phone users don't want to lug that size of a battery around just to get battery life that's worse than they get right now from a 15WHr one.
- thebean11 5y ago> Your macOS has an unacceptable battery life already Heh, not true anymore with the new M1 lineup. I was skeptical but they are insanely efficient.