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

391–400 of 414 posts

Re: Android vendors, don’t kill my app

#391

Post by me551ah »

Izkata wrote: post #332
me551ah wrote: post #282

Earlier quoted context omitted.

There is a way to detect it but it's hacky. You need to use fcm xmpp to send data push notifications with delivery receipts and also send an acknowledgement from the apps background service. Devices where you don't get the app ack have an app which is force killed Details outlined here : hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a

That sounds way over-complicated. Why not just keep a flag in the database that's updated during the Activity lifecycle?

Sorry, I didn't understand. We need a service side service to keep track of ack's that we received from the device. I am not able to understand how a db flag would help.

Re: Android vendors, don’t kill my app

#392

Post by kkarakk »

jdietrich wrote: post #128
kkarakk wrote: post #81

Earlier quoted context omitted.

what the jobscheduler api is supposed to be used for isn't clear in the docs so people tend to default to creating services(the old way of doing background activities) instead.

The API docs seem perfectly clear to me. https://developer.android.com/topic/performance/scheduling

https://docs.microsoft.com/en-us/xamarin/android/platform/an... compare microsoft's documentation of the same thing with google's documentation and you will see where the failing happens. in comparison intentservices(the old way of doing bg tasks recommended by everyone) are documented the same way by both google and microsoft and so that gets used instead.

Re: Android vendors, don’t kill my app

#393

Post by vxNsr »

untog wrote: post #353
vxNsr wrote: post #344

Earlier quoted context omitted.

Sounds like user error at that point, I would popup a message after the next force quit saying that doing so will pause email notification until the app is reopened. There you go: bug turned into a feature.

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.

The feature in my mind was an easy way to temp silence an app without going into settings.

I still think of it as user error if they force quit an app but still expect it to run in the background. Why force quit it?

I could see how it could be a UX failure for the OS but I don't think we can blame the dev for that. Apple should clarify what force quit does. I think the advent of webapps that don't really exist on your phone at all also causes confusion: the app has been updated with more content each time you use it, even if it's not running in the background, but to the user that's indistinguishable from the app running in the background.

Re: Android vendors, don’t kill my app

#394

Post by zaro »

I think the approach taken by these phone manufacturers a tually makes a lot of sense.

Most developers won't admit it but a lot of apps are quite terrible nowadays. Yes it is very convenient that your app does something in the background that is maybe useful, but it's only one app. When you have 30-40 apps installed w/o auto kill, the battery drainage is terrible.

For me moving from LG to Xiaomi was great in terms of battery life. And yes, sometimes there are app which shouldn't be killed but it's easy enough to change their setting in the battery saver. And really these are only few, most app deserve the auto kill, as they abuse the priviledge of being able to run in the background.

Re: Android vendors, don’t kill my app

#395

Post by Izkata »

me551ah wrote: post #391
Izkata wrote: post #332

Earlier quoted context omitted.

That sounds way over-complicated. Why not just keep a flag in the database that's updated during the Activity lifecycle?

Sorry, I didn't understand. We need a service side service to keep track of ack's that we received from the device. I am not able to understand how a db flag would help.

If all you need is to detect it on the next boot to notify the user, as the prior comment said, then for example:

onCreate - check "running" flag, then set to true

onDestroy - set flag to "ended"

If onCreate saw the flag was already "running" before it was set, then you have a crash to recover from or a kill to notify the user about.

Re: Android vendors, don’t kill my app

#396

Post by AnthonyMouse »

ajross wrote: post #375
AnthonyMouse wrote: post #357

Earlier quoted context omitted.

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.

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

For the two minutes between when you ask it to shut down and when you kill it? Even assuming that's a meaningful amount of energy savings (probably not), you could just kill it at the same time as you would have regardless but ask it to shut down two minutes before that.

> 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.

All value is relative. You can make anything sound good by comparing it to something arbitrarily worse, but that doesn't prove anything. Riding a donkey is better than walking on foot but I wouldn't want to have to travel from New York to LA on one.

The question is whether it's better than the good known existing alternatives, not whether it's better than the bad ones.

Re: Android vendors, don’t kill my app

#397

Post by dmitriid »

amaranth wrote: post #345
dmitriid wrote: post #207

Earlier quoted context omitted.

Slack receives messages with no problem. If XMPP/IRC can’t provide that, it’s not iOS’ problem.

Slack works because of push notifications. A random IRC app can't handle push notifications for you because they aren't the IRC server and aren't running a bouncer for you. On the other hand, the IRC server can't handle push notifications for you because they don't have an app signed with Apple's key sending the notifications. Basically protocols as a general thing can't work on iOS, only individual apps/services whi…

> Basically protocols as a general thing can't work on iOS, only individual apps/services which get to read all your messages and access your login credentials work.

Which I think is a reasonable requirement for a chat service, especially on mobile.

Re: Android vendors, don’t kill my app

#398

Post by theshrike79 »

stronglikedan wrote: post #257
nkristoffersen wrote: post #158

Earlier quoted context omitted.

That is the case in iOS. All permissions are optional and the app must gracefully degrade if permissions are denied.

Unfortunately, some apps just degrade, ungracefully, by flat out refusing to run without certain permissions.

On iOS? That's against app store rules if I remember correctly.

Re: Android vendors, don’t kill my app

#399

Post by ericflo »

kadal wrote: post #295
ericflo wrote: post #111

An example of this problem is casting shows to Chromecast. Android often kills your app in the background while you're watching, and now your Chromecast controls don't work and you have to reconnect.

This is so annoying! Do you know what needs to be whitelisted?

I haven't been able to really figure it out, to be honest.

Re: Android vendors, don’t kill my app

#400

Post by Carpetsmoker »

xyzal wrote: post #90

To be honest, as a user I really like the implementation of battery saving features of my Sony phone: 1. They are not enabled by default 2. Their settings screen explicitly states what the modes do 3. They can extend battery life significantly The most aggressive mode is called Ultra Stamina, and it works by basically turning the phone into dumbphone mode -- complete without any internet connectivity, calls, SMS and…

I wanted to say exactly the same. The Sony page is horribly misinformed.

Calling Sony "toxic" for including a useful OPT-IN feature to extend battery life? Pfff...

Post reply on HN