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

Don't kill my app

dontkillmyapp.com

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Don't kill my app

#41

Post by Kwantuum »

sebtron wrote: post #17

I think many commenters supporting the "kill my app" behavior do not understand how bad using the affected devices can be. The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map the app would reload. My search would be gone, and I would…

The most egregious problem caused by this that I've encountered is an almost complete inability to use email 2FA on websites because my phone will kill the browser as soon as I switch to my inbox, and when I go back to the browser I'm back on the login screen which will generate a new one-time-password and make the one I have in my clipboard worthless. I've also encountered the exact same problem with 2FA using an authenticator app, though since the codes are valid for ~30 seconds or so, if I manage to enter my credentials fast enough or they auto-fill, at least the code I copied is still valid.

Re: Don't kill my app

#42

Post by danmur »

I don't understand why Samsung is up there, at least on mine there's options to let it run things in the background when you need to. And otherwise, I'd rather not have apps hogging the battery in the background.

Re: Don't kill my app

#43

Post by BoorishBears »

kqr wrote: post #25
matheusmoreira wrote: post #19

Earlier quoted context omitted.

Why can't the app save its state to storage and restore the saved state when it's started again?

I feel like this is how Android has been designed from the start. Ages ago apps used to have a bug where form contents were cleared if the user switched from portrait to landscape orientation -- same problem: developers assumed they could store state in instances of input fields, when in fact these would be re-instantiated when the view was significantly re-rendered. This specific case seems like a continuation of th…

Nah configuration changes are definitely a fault.

Rotating your device or plugging in a keyboard should cause the UI to be torn down: it makes for a horrible UX and it's behavior that dates back to a phone that had 192MB of RAM.

It should have been ditched ages ago but in typical Android fashion lived on so long that now it can't really be changed and instead the SDK tries to work around it by providing developers with primitives to work around it.

Re: Don't kill my app

#44

Post by nneonneo »

One of the linked issues has this to say (https://issuetracker.google.com/issues/122098785):

> As a company, we develop a library that collects sensor and location data from the device, sends it to our platform, and transforms it into meaningful information about the user (user habits, routines, etc.).

> Over the past years, it has been painfully difficult to support Chinese OEM devices (Huawei, Xiaomi, etc.). These OEMs are modifying Android in ways that break core functionality. The default behavior of these devices is to forbid newly installed apps to send/receive broadcasts, acquire wakelocks, start services, set alarms, etc. in certain conditions (e.g. screen off), unless the user explicitly whitelists the app.

Honestly, I would prefer such an app stay broken. I don't need the app collecting that data in the background. If the attitude of Android developers is that they should be permitted to run in the background and collect this kind of information without explicit background permission from the user, then it's a no-brainer for OEMs to push back in order to preserve battery life.

Re: Don't kill my app

#45

Post by pretext-1 »

sebtron wrote: post #18
dreamcompiler wrote: post #13

I don't have much sympathy for this idea. The vast majority of apps don't need to do anything in the background, but almost every app thinks it's the only app on your phone and wants to be running and online 24/7 so it can constantly send you notifications, mine your personal info, and upsell you on crap you don't need. This is why we can't have nice things. It's a tragedy of the commons where the commons is your bat…

Many app need to keep state while they are in background though. Imagine your browswer tabs reloading every time you swotch to a different app and back.

Doesn’t mean your apps need to run in the background all the time. State restoration is a concept that has been present in Android/iOS from the beginning (or almost) and many apps implement it successfully. This is not why the “Don’t kill my app” author wants to run in the background.

Also Android has ongoing notifications which let your app stay running forever and iOS introduced Live Activities in iOS 16 which can be used similarly (e.g. Instagram uses it to finish uploads in the background). But what the author of “Don’t kill my app” wants is to run in the background without making it obvious to the user, which many would consider malicious.

https://developer.apple.com/documentation/uikit/view_control...

https://developer.android.com/topic/libraries/architecture/s...

Re: Don't kill my app

#46

Post by photonthug »

fritzo wrote: post #5
Torlan wrote: post #4

Don’t kill my battery

Yes, Dear app developers, different users want different things. The primary uses of my phone are (1) multi-factor authentication, and (2) as a GPS beacon whereby family can locate me if I'm injured in the wilderness. I definitely value battery life over app snazz.

So does GPS beacon then not qualify as an app? I guess here you can hope the vendor has an "official" beacon app that they grant battery-life exceptions for, but then you're screwed if you prefer a third-party beacon. Maps, those can be as safety-critical as a beacon too.. it would be a shame if someone cleared your map-cache because app-devs / mobile OS designers are optimizing for urban technophiles who have easy access to electricity. Or if that flashlight app breaks because it has an offline-mode that's insufficiently tested, and it chokes down when it's trying to load ads from an API it can no longer access! It's depressing to think about but bad UX, poor initial design, or just inevitable enshitification of perfectly fine working systems like this has no doubt actually killed people.

Re: Don't kill my app

#47

Post by isodev »

sebtron wrote: post #17

I think many commenters supporting the "kill my app" behavior do not understand how bad using the affected devices can be. The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map the app would reload. My search would be gone, and I would…

You're describing bad app implementation.

It is quite common for the OS to suspend apps when they're in the background or when the device is under low memory/power conditions. The fact that you as a user are experiencing it in the form of degraded functionality is a bug with the app itself and should be addressed by the developer.

As a reference, check iOS apps where the system monitors and controls each app's resource usage much more aggressively and a user is never aware of this.

Re: Don't kill my app

#48

Post by zahrc »

toast0 wrote: post #28
jraby3 wrote: post #12

Earlier quoted context omitted.

The best hack I’ve found for iOS (iOS isn’t even listed in the article) is keeping phone in low power mode.

iOS apps are built around Apple's policies which are more or less uniformly enforced on Apple phones. iOS apps started with near zero background compute and that was only added later. OTOH, Android apps started with near zero restrictions on background compute and it's been added on in bits here and there. Two different Android phones may have drastically different policies and not because the user chose it. App deve…

> It's not always easy doing that for Apple, but there's not ten different ways you have to do things for ten different manufacturers.

It's why, I, as a user, chose to stick with iOS. At least it's the devil I know, with the behaviour and boundaries that I can accept - without having to figure out every kink everytime there is an update.

I understand that some people prefer to tinker with their phones, I do not.

Re: Don't kill my app

#49

Post by [deleted] »

masklinn wrote: post #33
matheusmoreira wrote: post #19

Earlier quoted context omitted.

Why can't the app save its state to storage and restore the saved state when it's started again?

Because it costs resources the developers are unwilling or unable to spend. They might also be lacking competence. My local bus authority’s application is barely able to keep track of its state while it’s running . An other common situation is an applications getting in an irrecoverably broken running state. If the application preserves state on shutdown you might not be able to get it out of the broken state.

[deleted]

Re: Don't kill my app

#50

Post by kenferry »

osener wrote: post #20
sebtron wrote: post #17

I think many commenters supporting the "kill my app" behavior do not understand how bad using the affected devices can be. The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map the app would reload. My search would be gone, and I would…

This somehow seems to have become an inevitable reality of mobile phones. I had to upgrade from my iPhone 7 because it had essentially become a “single-process OS” where even switching to Google Translate to help me compose a message would have the messaging app killed in the background. And now I am experiencing similar issues, although not as severely yet, with my iPhone 12 Pro Max. Restarting the phone seems to he…

iOS actually kills apps in the background FAR less than it used to. If your apps are not preserving state across being killed, it’s because they’re not doing the work to make sure the app death is transparent. Perhaps they’re more tempted to forego the work because it’s somewhat _less_ essential than it used to be.
Post reply on HN