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

341–350 of 414 posts

Re: Android vendors, don’t kill my app

#341

Post by untog »

jmull wrote: post #304
bad_user wrote: post #240

Earlier quoted context omitted.

No, they haven't solved it.

I’m curious: why doesn’t background refresh solve the problem?

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.

Re: Android vendors, don’t kill my app

#342

Post by int_19h »

fixermark wrote: post #327
toast0 wrote: post #254

Earlier quoted context omitted.

If you want a messaging app to work well, it should send and receive messages when the phone has network connectivity and power. Power is a prerequisite for running in the foreground, but network connectivity is not. Some people may in fact want messaging apps to only work while in the foreground and network available, but I suspect that's less desired. If you're trying to run standard irc and appear online as much a…

And also, it's the 21st century and we don't need chat protocols to be client-side-liveness chatty to "stay on" when the entire cellular network is architected to find devices and route messages to them. IRC isn't a well-designed protocol for this use case, and a "land-side" bouncer that bridges the chatty protocol to a lazier protocol ought to be more energy-efficient overall.

Well-designed or not, it exists, and sometimes you just want to use it, without a lecture on how it's suboptimal.

Re: Android vendors, don’t kill my app

#343

Post by ajross »

sudhirj wrote: post #200
bad_user wrote: post #192

Earlier quoted context omitted.

>> " Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks " iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does. _Example 1:_ fetch email (withou…

Example 1 has been solved with Background App Refresh a long time ago [1] Example 2 should work fine with the background mode declared [2] Both these APIs are pretty old... is there something I'm missing? [1] https://developer.apple.com/documentation/uikit/core_app/man... [2] https://developer.apple.com/documentation/foundation/url_loa...

Isn't that the same kind of excuse-making you're dinging the Android world for? "OK, fine, the experience sucks by default but it works fine if you just do this and this and this". Android has all those sorts of features too.

It's just a hard problem. App developers are bad, and do bad things. OSes can't protect against all bad behavior. Phone manufacturers do have a vested interest in protecting their users from bad apps. Users do actually benefit from this on balance.

Re: Android vendors, don’t kill my app

#344

Post by vxNsr »

untog wrote: post #341
jmull wrote: post #304

Earlier quoted context omitted.

I’m curious: why doesn’t background refresh solve the problem?

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.

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.

Re: Android vendors, don’t kill my app

#345

Post by amaranth »

dmitriid wrote: post #207
anc84 wrote: post #193

Earlier quoted context omitted.

Can I run XMPP or IRC on an iphone by now or does it still only receive messages when foregrounded?

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 which get to read all your messages and access your login credentials work.

Re: Android vendors, don’t kill my app

#346

Post by vxNsr »

admax88q wrote: post #284
dithering wrote: post #227

Earlier quoted context omitted.

"Use a bouncer" might be the answer there. All engineering is compromise, and needing a bit more compromise to support legacy applications is not unreasonable. (In fact, why are you running a stream-oriented application over such an unreliable connection at all?)

My XMPP client works perfectly on my Android phone. Prompt and reliable notifications of new messages. Better than most "Push Message" based clients I've used for other chat services. It's consistently the last in battery usage as well. Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.

Classic HN response.

I'd guess a FTP and a linux file-server would solve all your filesharing woes as well.

No dev making a mass market device or software should build as if the 1% graybeard engineer is gonna be the only user, that's a lot more user hostile.

Re: Android vendors, don’t kill my app

#347

Post by hernan604 »

Ninn wrote: post #170
adrianhon wrote: post #148

For our Zombies, Run! run tracking/audio adventure app, "battery management" is turning into our most consistent customer complaint, to the point where it's impacting review scores, active users, and probably subscriptions. The result of the changes made by Huawei, OnePlus, Xiaomi, and Samsung mean that our app is killed during runs, and people interpret that as the app crashing. We're trying to figure out the best w…

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?

Have an app priority defined by user

Re: Android vendors, don’t kill my app

#348

Post by anderskaseorg »

lukevp wrote: post #215
masklinn wrote: post #209

Earlier quoted context omitted.

As TFA notes (in the Nokia section, possibly others): > This app kills apps in the most brutal way we have seen so far among Android vendors. You can't detect that your application was kill -9'd. I don't think you can detect that "PowerSavingAppG3" is running either (I'd guess it's running as root and you're not), so you can't even infer from its existence that your application will be traumatically killed in short o…

I think you are reversing what the parent comment meant. You can continually write to the sandboxed filesystem of your app, say write the current timestamp every 10 seconds, and a status of if the app exited gracefully (which you can control). Then when restarting the app you check if there was a timestamp written in the last say 2 hours and no graceful exit then you know the app was terminated and can explain that t…

Please don't! This will wear out both the battery and the flash memory for no reason. It's exactly this kind of sloppy coding that made these manufacturers decide app killers were necessary.

Re: Android vendors, don’t kill my app

#349

Post by vxNsr »

simonh wrote: post #201
tinus_hn wrote: post #179

Earlier quoted context omitted.

For some basic use cases, like notifications and downloads, there is a special system or api that allows your app to do that in the background without actually running. If you want to play audio or track gps in the background you need to do things yourself though.

OK, hence the Facebook issue where they played a silent audio track to keep their app active. I'd forgotten about that, thanks.

Wow, that sucks is again super user hostile, I'm so happy I removed their app.

Re: Android vendors, don’t kill my app

#350

Post by dithering »

vxNsr wrote: post #346
admax88q wrote: post #284

Earlier quoted context omitted.

My XMPP client works perfectly on my Android phone. Prompt and reliable notifications of new messages. Better than most "Push Message" based clients I've used for other chat services. It's consistently the last in battery usage as well. Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.

Classic HN response. I'd guess a FTP and a linux file-server would solve all your filesharing woes as well. No dev making a mass market device or software should build as if the 1% graybeard engineer is gonna be the only user, that's a lot more user hostile.

Never mind HN, that's a classic Slashdot response.
Post reply on HN