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

371–380 of 414 posts

Re: Android vendors, don’t kill my app

#371

Post by lstamour »

scarface74 wrote: post #366
lstamour wrote: post #364

Earlier quoted context omitted.

There are rules: Unacceptable: https://developer.apple.com/app-store/review/guidelines/#una... Spam: https://developer.apple.com/app-store/review/guidelines/#spa... Copycats: https://developer.apple.com/app-store/review/guidelines/#cop... You can't make your own App Store, you can't ship your own browser -- https://developer.apple.com/app-store/review/guidelines/#sof... -- you have to use HLS, you can't use backgroun…

I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already. There is a difference between "I want to write a podcast app" and "I want to duplicate Over…

I was citing rule 2.5.4 with that list of approved background app categories, unless you can name exemptions...

Re: Android vendors, don’t kill my app

#372

Post by noelsusman »

morganvachon wrote: post #197
kda26 wrote: post #144

Earlier quoted context omitted.

On my phone (android), going to apps>selecting app I want to run in the background>battery>background usage I can allow the app to run unrestricted in the background. All android phones I've owned had this option.

My understanding from the OP website is that this is ineffective for certain popular phone vendors' customizations. In particular, the Nokia phone listed comes preinstalled with an app that aggressively shuts down any running process, whitelisted or not, if the screen has been off for 20 minutes. There's simply no way to stop this behavior apart from gaining root and uninstalling the battery "saving" app, or flashing…

The Nokia one is egregious, but their second worst vendor (OnePlus) allows users to whitelist individual apps, though there's a bug right now where that setting gets reset randomly.

Re: Android vendors, don’t kill my app

#373

Post by panopticon »

madeofpalk wrote: post #368
untog wrote: post #353

Earlier quoted context omitted.

How on earth would that be a feature? If you have to show a popup on launch for something like that then it's a user experience failure, no matter if it's your fault or Apple's. Either way, it means the user has to treat your app differently to every other app on their phone. That is bad. "It's user error" is a weak excuse if any kind of significant number of users are doing it.

If a user 'force quits' an app, don't they expect that it won't be running in the background receiving app content updates? If I force quit an app on my computer, it no longer runs and does things.

I think most users expect to receive notifications from apps (especially communication apps) even if the app doesn't appear in the App Switcher carousel. What people expect from their phones and computers are wildly different here.

Re: Android vendors, don’t kill my app

#374

Post by scarface74 »

lstamour wrote: post #371
scarface74 wrote: post #366

Earlier quoted context omitted.

I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already. There is a difference between "I want to write a podcast app" and "I want to duplicate Over…

I was citing rule 2.5.4 with that list of approved background app categories, unless you can name exemptions...

Well unless you think that Apple added the APIs that I linked to and added settings to allow you to disable background processing (that doesn’t apply to the categories) you mentioned, which do you think is the more appropriate interpretation to what is allowed - the rules or the API documentation?

Re: Android vendors, don’t kill my app

#375

Post by ajross »

AnthonyMouse wrote: post #357
ajross wrote: post #354

Earlier quoted context omitted.

> There is no benefit to killing an app without notifying it in any way Sigh. There can be on balance . Bad apps get killed, users don't see as many dead phones. A few false positives get killed too, to great annoyance of their authors (and potentially users, but it's mostly the app authors upset here, be honest). Whether that's worth it or not depends on the numbers involved, not your personal definition for "ham-fi…

Can you explain the advantage in killing the app without notifying it? You're going to kill the app because it's consuming 500MB of memory, fine, send it SIGTERM or equivalent and then give it two minutes to orderly shut down before you send SIGKILL. Not doing it that way has a cost and no apparent benefit to "balance" it with.

> Can you explain the advantage in killing the app without notifying it?

Um.. "The app uses less energy." Is that a serious question?

Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.

Re: Android vendors, don’t kill my app

#376

Post by JustSomeNobody »

lol768 wrote: post #249
JustSomeNobody wrote: post #245

Earlier quoted context omitted.

Getting messages should not/does not have anything to do with running in the background.

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.

Re: Android vendors, don’t kill my app

#377

Post by JustSomeNobody »

feikname wrote: post #252
JustSomeNobody wrote: post #245

Earlier quoted context omitted.

Getting messages should not/does not have anything to do with running in the background.

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.

Re: Android vendors, don’t kill my app

#378

Post by shimfish »

shimfish wrote: post #203
Ninn wrote: post #170

Earlier quoted context omitted.

Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged. Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?

Whether this is possible or not is deeply missing the point as well as showing a vital misunderstanding about UX.

People were correct to downvote my comment. The tone was all wrong. For some reason, I take Android's many shortcomings as a personal affront. I guess that's what years of being a dev where all the piracy and user support are with Android issues while only returning a fraction of the profit compared to iOS will do to you.

The point is that this is entirely Google's fault and yet it's the devs who have to clear up the mess and take the blame, or alternatively we bombard the users with technical fixes and explanations. Quite clearly neither of these options is where we should be with a mature OS on a mass consumer device.

Now I'm getting all angry again just thinking about it. Time to up my meds.

Re: Android vendors, don’t kill my app

#379

Post by jdbernard »

whouweling wrote: post #164
scarface74 wrote: post #143

Earlier quoted context omitted.

Does Android not have the concept of “local notifications” where you can tell the OS to schedule a notification to be sent to the app to wake it up instead of being in the background the whole time?

As others replied; it does. But the API does not behave consistent on different brands and API levels. Also some manufacturers cancel alarms when the user swipes away an app (which some users do constantly to keep the recent apps list "clean")

I'm one of those users. The visual clutter leads to mental clutter. Having a "clean" notification bar makes it easier to ignore the pavlovian "check your phone!" conditioning that has built up over time.

I appreciate that in some cases apps need to be in the notification bar in order to remain running. I also appreciate those like Tasker that have the option to hide their icons or use "empty" icons (so nothing shows).

Re: Android vendors, don’t kill my app

#380

Post by untog »

madeofpalk wrote: post #368
untog wrote: post #353

Earlier quoted context omitted.

How on earth would that be a feature? If you have to show a popup on launch for something like that then it's a user experience failure, no matter if it's your fault or Apple's. Either way, it means the user has to treat your app differently to every other app on their phone. That is bad. "It's user error" is a weak excuse if any kind of significant number of users are doing it.

If a user 'force quits' an app, don't they expect that it won't be running in the background receiving app content updates? If I force quit an app on my computer, it no longer runs and does things.

An app that has been force quit can still receive remote notifications just fine. I don't think the average users knowledge is so nuanced that they understand the distinction between a remotely-sent notification that always appears and a locally generated one that's the result of a background process that doesn't.
Post reply on HN