Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android vendors, don’t kill my app

dontkillmyapp.com

Post reply on HN
Print view View original

381–390 of 414 posts

Re: Android vendors, don’t kill my app

#381

Post by untog »

jmull wrote: post #370
untog wrote: post #341

Earlier quoted context omitted.

Background refresh doesn't work if the user "force closes" the app, i.e. they go to the task manager and swipe it away. Anecdotally, it's super common for people to do this as they have read somewhere that it helps battery life (not untrue, but also not really effective). So if you were writing an e-mail app you wouldn't be able to guarantee that you'll actually deliver e-mail to users, which feels kind of important.

I see. I can see the issue. But it comes down to this: if a user explicitly kills an app, should it keep running in the background? If the answer is "yes", then what you're really saying is users shouldn't be able to kill apps if the app doesn't want to be killed. I get that some users don't know what killing an app means but do it anyway for some reason. But that's not a problem with background refresh. E.g., maybe…

The problem is that nothing is self-evident. An app that sends remote notifications to notify you of an e-mail looks exactly the same as one that locally generates a notification as a result of background processing. But the former will work after being swiped away from the app switcher and the latter won't.

I just don't think it's reasonable to expect the average use to "get" that.

Re: Android vendors, don’t kill my app

#382

Post by chaostheory »

TruthSHIFT wrote: post #273
sergiosgc wrote: post #271

I have an Android One Nokia (8 Sirocco), and: a) I wholeheartedly want this behaviour. The phone lasts 2-3 days without recharging, and I no longer fear leaving home with 30% battery. b) It's not an app that kills background apps. It's Android's own Background Activity Manager, where apps that are not whitelisted can't wake up the CPU. They run only when the CPU wakes up for some other reason (screen-on qualifies but…

From a usability perspective, this sounds crazy. Is is responsible of me to recommend Android to my non-technical friends?

Another big benefit of going with Apple for non-technical users is the Apple retail stores. These stores host free classes on how to use Apple devices and apps. This is huge for older people.

Re: Android vendors, don’t kill my app

#383

Post by jabberthemutt »

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.

Which means there is a third party eavesdropping on chat.

Re: Android vendors, don’t kill my app

#384

Post by arantius »

colejohnson66 wrote: post #251
richardwhiuk wrote: post #151

Earlier quoted context omitted.

It does - the one that works properly is https://developer.android.com/reference/android/app/AlarmMan... However, the implementations of the API are questionable. Some calls to that API on some OEMs device round alarms to the nearest minute, some to the nearest ten minutes.

> Some calls to that API on some OEMs device round alarms to the nearest minute, some to the nearest ten minutes. WHY? What benefit does that serve?

Limits the potential battery impact.

Without this restriction, how long before an app maker schedules their alarm every millisecond?

Re: Android vendors, don’t kill my app

#385

Post by jsjohnst »

admax88q wrote: post #286
jsjohnst wrote: post #280

Earlier quoted context omitted.

I think the point being made is that’s a terrible use of resources, not only are you keeping the app running, but you are also forcing the power hungry LTE radio to stay on more. This idea that the end device should do all the work is not a sustainable approach. There should be a server side component that is handling this for you and sending push notifications when your app needs to wake up for new data.

> sending push notifications when your app needs How do you think push notifications work? There isn't some magic in LTE to wake up your phone. Your phone needs to keep a connection open in the background and periodically wake up the modem to check for new information. I use Conversations (XMPP client) on Android, it keeps a plain old TCP connection open in the background and honestly it does not much battery at all.…

> How do you think push notifications work?

There’s a very distinct difference between having a persistent connection that only transmits data when there’s something notable vs having a connection that constants pushes a kitchen sink of data that may or may not be needed. Sure, if you sent a push notification on every single message and status change on the IRC server, it’d likely use the same amount of (or maybe more) battery, but who does that?

Re: Android vendors, don’t kill my app

#386

Post by Skunkleton »

masklinn wrote: post #337
Skunkleton wrote: post #326

Earlier quoted context omitted.

Sure you can: 1. Create an empty file when the application launches 2. When the application terminates, write the reason for termination into the file. 3. When the app launches again, read the file. If it was empty, then you were SIGKILL'd, or you crashed.

> you were SIGKILL'd, or you crashed. "Might have been killed, might have crashed" is not helpful, and the inability to know is the very issue at hand here. You can't know whether your application crashed, the user forcefully killed it or you fell afoul a background killer. What now, do you start spamming the user anyway?

Most of the time when you crash there is a signal associated with that which can be handled. If you application terminated normally under an error case, then that has to be captured through the same mechanism.

Re: Android vendors, don’t kill my app

#387

Post by jmull »

untog wrote: post #381
jmull wrote: post #370

Earlier quoted context omitted.

I see. I can see the issue. But it comes down to this: if a user explicitly kills an app, should it keep running in the background? If the answer is "yes", then what you're really saying is users shouldn't be able to kill apps if the app doesn't want to be killed. I get that some users don't know what killing an app means but do it anyway for some reason. But that's not a problem with background refresh. E.g., maybe…

The problem is that nothing is self-evident. An app that sends remote notifications to notify you of an e-mail looks exactly the same as one that locally generates a notification as a result of background processing. But the former will work after being swiped away from the app switcher and the latter won't. I just don't think it's reasonable to expect the average use to "get" that.

I agree the users shouldn’t be the ones worrying about the subtlties. It’s we developers.

Re: Android vendors, don’t kill my app

#388

Post by londons_explore »

amaccuish wrote: post #260
londons_explore wrote: post #101

Earlier quoted context omitted.

The social media apps will almost certainly use Googles push notification service, which is the only background notification allowed. Your imap client is trying to hold a TCP connection open to your server, which isn't allowed. There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of…

Do you know of anywhere, where this is all explained? Like the idea of recording average timeouts by ISP?

I'm not sure anyones written it up yet. You can see it for yourself if you run adb logcat on a sleeping phone. Try running it on different networks and see the keep alive period. (you'll have to turn off all push notification sources, because a push message counts as a keep alive too).

Re: Android vendors, don’t kill my app

#389

Post by feikname »

JustSomeNobody wrote: post #377
feikname wrote: post #252

Earlier quoted context omitted.

Receiving messages (aka "listening" in server jargon) is essentially a background task, constantly probing to check for any changes.

Right. That's why there's an API for it. Each app doesn't have to stay awake listening. The OS will wake the app up.

Oh, that does make sense.

In that case, having the app run the background really does seem like a waste when compared to leaving the OS to do this task.

Post reply on HN