I'm not an android dev, can someone weigh in here? Why is using Tasks bad? Who really cares if he uses a design pattern from five years ago? I'm sure my website code is at least twice as old and PHP, should I spend time rewriting that in Kotlin, too?
> The way he's handling synchro (persistent foreground service) is _explicitly something Google is targeting for battery issues_
My phone has a terrible battery that will drain in 3 hours while navigating¹, but FairEmail running in the background is not noticeable. I've used K9 before as well and didn't notice any difference in battery use.
¹ worst battery I ever had in a phone, and also the most expensive phone I ever had... thankfully I got it second-hand and didn't pay the full price for this. Got a second one for my mom which was equally bad, so we had her device's battery replaced by samsung for iirc €110, but her battery longevity barely improved. Coincidentally I ruled out an hour ago that it's the screen that causes the drain, my next best guess is the CPU. Not sure why this model is such a battery hog, but anyway FairEmail doesn't impact it.
> This app looks like a 5+ year old code base, not something persistently maintained.
FairEmail was the only app that would receive updates every time the f-droid repository had a new release. Most apps go months between updates but of FairMail there were updates almost daily. And it's just this guy working on it all the time, I don't know where he got the energy. So maybe not the "maintenance" shiny new code patterns you'd like to see, but the maintenance I was very happy about was a constant stream of updates.
The comments on code quality are somewhat fair, and there are better ways of doing things, but calling it "out of touch" because it's not been rewritten in kotlin is frankly silly.
Additionally, None of this is justification for removal from the store, the comment calling `requestPermissions` illegal is unjust, there's nothing incorrect about its use here (notwithstanding Play Store policies around contacts). ActivityResultLauncher is a more modern (imo superior) and recommended, but it is not a requirement.
God forbid we have some tolerance for developers who don't want to spend every waking moment rewriting their app to use whatever new API Google have just added...
It's illegal because it crashes the app on the latest versions of Android. It's an illegal operation, not "against the law in N countries" type of illegal, more the "Divide by 0" type of illegal.
The out of touch is my personal assessment of reading through the code: They doesn't seem to recognize the benefits of the modern Android code styles which would reduce their workload, decrease the boilerplate they're writing, and increase the stability of the app overall.
I was just documenting issues I saw with the code from a maintainability standpoint.
The older Tasks & Runnable API is very fragile when it comes to lifecycle changes and will cause crashes regularly. This means that you end up building up a ton of patchy code over time to try and do what Kotlin's lifecycle aware coroutines will do for you.
So of course he spent all his time patching: His code was fragile to begin with. You don't end up so many 3kLOC files without poor architecture.
Look: I've been there. Ripping down fragile monoliths to refactor seems like a waste of time because you'll spend 3 months rewriting code while bugs pile up. It's worth doing though because you'll save 6 months of bug fixes in the future.
When it comes to the APIs there's another comment here that explains explicitly the spyware issue (He was scraping emails and sending them to a 3rd party), but for the Android APIs that he was abusing they're recent privacy focused changes that cannot be ignored.
Sure your website will run fine but fundamentally HTML is very similar to what it was a decade ago. Android's runtime is constantly evolving as the phones change to new demands. Battery usage is something they're exerting more control over, and I personally find that annoying. Privacy is another thing: I'm all for that. The permissions requests he was doing will literally crash the app for modern Android. You cannot request permissions that way anymore because the API has changed to make it more explicit.
It sucks that he didn't care enough to fix it, but here we are. He's done an admirable job limping along the mess of a code base but he hasn't implemented the fixes that were needed for it to work on modern phones.
> The way he's handling synchro (persistent foreground service) is _explicitly something Google is targeting for battery issues_
My phone has a terrible battery that will drain in 3 hours while navigating¹, but FairEmail running in the background is not noticeable. I've used K9 before as well and didn't notice any difference in battery use.
¹ worst battery I ever had in a phone, and also the most expensive phone I ever had... thankfully I got it second-hand and didn't pay the full price for this. Got a second one for my mom which was equally bad, so we had her device's battery replaced by samsung for iirc €110, but her battery longevity barely improved. Coincidentally I ruled out an hour ago that it's the screen that causes the drain, my next best guess is the CPU. Not sure why this model is such a battery hog, but anyway FairEmail doesn't impact it.
> This app looks like a 5+ year old code base, not something persistently maintained.
FairEmail was the only app that would receive updates every time the f-droid repository had a new release. Most apps go months between updates but of FairMail there were updates almost daily. And it's just this guy working on it all the time, I don't know where he got the energy. So maybe not the "maintenance" shiny new code patterns you'd like to see, but the maintenance I was very happy about was a constant stream of updates.