Android vendors, don’t kill my app • Hacker News Board

Re: Android vendors, don’t kill my app

#411

Post by lol768 » Wed, Jan 16, 2019, 10:46 PM UTC

JustSomeNobody wrote: post #376

lol768 wrote: post #249

Earlier quoted context omitted.

Getting messages requires an open TCP connection, hence it really is quite important (at least with IRC) that the app stays running in the background.

This is what the push message API in iOS is for. It wakes up the app when messages come in.

> This is what the push message API in iOS is for. It wakes up the app when messages come in.

IRC isn't reliant on a proprietary push message API, though (be that provided by Apple or Google).

I'm sure there are long-lived bouncer plugins that will integrate with said APIs, but the core IRC protocol is not suited to or designed for devices that aren't capable of a long-lived connection.

Re: Android vendors, don’t kill my app

#412

Post by romwell » Thu, Jan 17, 2019, 1:19 AM UTC

seszett wrote: post #66

perlgeek wrote: post #63

https://dontkillmyapp.com/samsung > Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds. Wait, do you really need a background task for alarms? (why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?

No, you don't need a background task for alarms. There is a JobScheduler API for that. The aggressive battery settings of most vendors only interfere with badly coded apps to begin with, apps that use background tasks when they should be using more appropriate APIs.

>apps that use background tasks when they should be using more appropriate APIs.

But some tasks do need to run in background, don't they? Specifically, sports tracking apps. Had a lot of issues with those on on various phones; now I simply don't switch out of the tracking app at all while it's running (otherwise, I can never be sure it simply won't be tombstoned in the background).

Re: Android vendors, don’t kill my app

#413

Post by dangerface » Mon, Jan 21, 2019, 10:50 AM UTC

hiddentruth wrote: post #263

dangerface wrote: post #216

Earlier quoted context omitted.

I have a Xiaomi and oneplus phone, neither of them have ever closed a background app so I dunno what you are talking about, but if phones are doing that then, yea fair enough thats a problem. The wording in the linked website is talking more specifically about cpu limits, which is how most os manage background resources, whats the problem with that? Sleep tracking is a good example you should use an event system, but…

Are fitness tracking apps able to run uninterrupted in your Xiaomi phone? Did you change any relevant settings?

I had a huwaii fit-bit-thing for a few months it uses two apps and I had issues getting them to talk to other software, but no problems tracking or shutting down, didn't change any settings. Maybe other apps have problems but theirs worked fine.

Re: Android vendors, don’t kill my app

#414

Post by dbrgn » Wed, Jan 23, 2019, 9:45 PM UTC

barrkel wrote: post #122

dbrgn wrote: post #44

Earlier quoted context omitted.

Not just long-running background processes (e.g. gemerating a backup of your app). It may even prevent your push notification handler from running.

Most push notifications are spam, and even when they aren't, they are usually from self-important apps that think they are the most important thing running on your phone. The only push notifications I want are messages from humans.

See - messengers use push notifications to let you know about messages from humans. Most users of messengers get (understandably) upset if they don't receive notifications for incoming messages.

Note that you can always block notifications for apps you chose. The problem here is the other way around: You do want notifications, but even though you disable battery optimizations and some other things for the app you're using you can't get push notifications to be delivered reliably. That's a pain.