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

241–250 of 414 posts

Re: Android vendors, don’t kill my app

#241

Post by mosselman »

Yizahi wrote: post #230
mosselman wrote: post #43

First I though "Is Nokia bad or good? Then I saw 'bad vendor score'" so I figured they are the worst. Then I got confused about all the vendors having the same score, but a different colour. Then I saw that some of the circles are slightly darker than the others... This type of visual communication hurts my brain too much.

It seems that just as bad apps they are trying to shield their website is also badly written and the simple picture of poop is linked from whatever of the 7 third-party sites with spying javascript code they are using and is blocked by adblock. Circles for me too.

Ah that explains it. I was under the impression that I was looking at a simple website, not some super fancy front-end application. I block all external domains with ublock-origin.

Since when do you need to serve emojis from a third party? I thought you can just insert them straight into your HTML. Or is that not cool enough?

Re: Android vendors, don’t kill my app

#242

Post by AstralStorm »

Piskvorrr wrote: post #239
PunchTornado wrote: post #211

Earlier quoted context omitted.

been using android since forever. Now I'm on a s8+. I never had a case like this. maybe I didn't noticed it. But my alarm always went on like it should. my music always played. is this a bug that sometimes happens? how rare is it?

S8 has this, but can be opted out (plus it has what I assume is a whitelist of pre-approved apps, but even those can be opted in, IIRC). It's clumsy, but sort-of works. It does break some old apps that rely on scheduled wakeups, though :(

Also the Samsung variant will not kill the app or service that is showing a notification as it should. So the three problem is limited to apps relying on dumb running in background.

Alarm scheduled wakeups get rounded to a minute in power saving mode though.

Re: Android vendors, don’t kill my app

#243

Post by mosselman »

kalleboo wrote: post #51
mosselman wrote: post #43

First I though "Is Nokia bad or good? Then I saw 'bad vendor score'" so I figured they are the worst. Then I got confused about all the vendors having the same score, but a different colour. Then I saw that some of the circles are slightly darker than the others... This type of visual communication hurts my brain too much.

Something on your end is not loading (JavaScript off?) Each vendor has 1-5 poop emojis with Nokia having 5 and Stock Android only 1

Thanks, yep, I ad-block external domains by default.

Re: Android vendors, don’t kill my app

#244

Post by AstralStorm »

kda26 wrote: post #152
z3t4 wrote: post #117

Earlier quoted context omitted.

Interesting. Batteries in smartphones usually have five times more battery capacity then feature phones, it should last over a month!

Smartphones also have 5x more screen to light up, too.

Reminds me of YotaPhone 2 eInk display - pretty crummy, but the Snapdragon 820 device stayed on a week on without additional power saving...

Re: Android vendors, don’t kill my app

#245

Post by JustSomeNobody »

anc84 wrote: post #193
CodeWriter23 wrote: post #127

Earlier quoted context omitted.

No, it’s the consequence of permitting background tasks at will. Apple took some heat, and there is learning curve associated with doing it their way, but they actually thought it through and created an energy-efficient architecture that addresses common use cases. And apps that don’t fit those use cases - what are they doing with your device?

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

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

Re: Android vendors, don’t kill my app

#246

Post by ehnto »

dorfsmay wrote: post #228
lukevp wrote: post #215

Earlier quoted context omitted.

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…

How do you differentiate an apps crash from an OS forceful kill? Both would show a last good status and no good exit.

Presumably you would have an error log in the crash circumstance, unless it was very seriously broken.

Re: Android vendors, don’t kill my app

#247

Post by jessaustin »

dorfsmay wrote: post #228
lukevp wrote: post #215

Earlier quoted context omitted.

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…

How do you differentiate an apps crash from an OS forceful kill? Both would show a last good status and no good exit.

You can detect which model of phone the app is running on, right? On these problematic models you should probably just assume that the app got killed in that circumstance.

Re: Android vendors, don’t kill my app

#248

Post by toast0 »

dorfsmay wrote: post #228
lukevp wrote: post #215

Earlier quoted context omitted.

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…

How do you differentiate an apps crash from an OS forceful kill? Both would show a last good status and no good exit.

App crash leaves a crash dump generally. Also, if your app crashes too often on some oems, the phone will automatically clear the local data, to "fix" it. I forget which one did it or I'd shame them directly.

Re: Android vendors, don’t kill my app

#249

Post by lol768 »

JustSomeNobody wrote: post #245
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?

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.

Re: Android vendors, don’t kill my app

#250

Post by lol768 »

dithering wrote: post #227
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?

"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?)

>"Use a bouncer" might be the answer there.

Weechat and weechat-android are great choices here. Best CLI and Android IRC clients I've used, and I've tried quite a few.

Post reply on HN