(In fact, why are you running a stream-oriented application over such an unreliable connection at all?)
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.
No, but the other 6 billion people on the planet do.
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.
However most phone vendors incorrectly assume "background connections" will drain battery life despite evidence to the contrary.
Phone vendors have a vested interest though in forcing developers to use their proprietary "push" feature for syncing to phones, they say it's for "battery life" but really its about vendor lock in.
A well engineered app can sync over its own TCP connection just fine and not hurt battery life, but then such an app can work on any device, not just blessed Android builds that have access to GCM.
Every modern phone today will give you a list of the apps that take the most juice, and yet somehow for some reason people still install facebook. We might need to protect users from themselves.
I don't understand why phone manufacturers need to add features to protect facebook users from facebook. facebook has the money to build an app that isn't shit.
My Android tablet is on a stable WiFi network at home...
Weechat and weechat-android are great choices here. Best CLI and Android IRC clients I've used, and I've tried quite a few.
If you're trying to run standard irc and appear online as much as possible, that's not going to work in iOS without a bouncer to stay online for you and send push messages to send notifications and allow the app to run for a bit to download the messages.
It's probably not a bad idea on Android too, it's technically possible to run as a background service and stay connected, but there's a lot of uncertainty, because other services can crowd you out, and you're at the whim of Google and oems with power management these days.
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.
... and maybe your own hardware to run them on. But I wouldn't expect any major player competing against other companies to do the work for you when the outcome is supporting some chat protocols that most people don't use.
(Otherwise, if you're expecting vendors to do it for you, you get to expect the lecture that comes with that expectation, in the form of APIs designed to minimize the ease of doing the wrong-for-the-average-utility-of-the-platform thing. Your cell radio could probably be adjusted to operate as a spark-gap transmitter also, but I don't expect them to provide an easy API for that either ;) ).
IRC isn't reliant on a proprietary push message API, though (be that provided by Apple or Google).
I'm sure there are long-lived bouncer plugins that will integrate with said APIs, but the core IRC protocol is not suited to or designed for devices that aren't capable of a long-lived connection.
This idea that the end device should do all the work is not a sustainable approach. There should be a server side component that is handling this for you and sending push notifications when your app needs to wake up for new data.
How do you think push notifications work? There isn't some magic in LTE to wake up your phone. Your phone needs to keep a connection open in the background and periodically wake up the modem to check for new information.
I use Conversations (XMPP client) on Android, it keeps a plain old TCP connection open in the background and honestly it does not much battery at all. It's consistently at the bottom of battery usage according to my phone.
It's a lot cheaper to keep an LTE radio on in a low-wattage "ping me if you need me" mode and trust the 'infinite-power' landside terminal to notify you of messages than to wake it up once every N seconds to loudly ping a cell tower "HEY LET ME KNOW IF I HAVE ANY MESSAGES KTHX."
There’s a very distinct difference between having a persistent connection that only transmits data when there’s something notable vs having a connection that constants pushes a kitchen sink of data that may or may not be needed. Sure, if you sent a push notification on every single message and status change on the IRC server, it’d likely use the same amount of (or maybe more) battery, but who does that?
In that case, having the app run the background really does seem like a waste when compared to leaving the OS to do this task.
If XMPP/IRC can’t provide that, it’s not iOS’ problem.
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.
What I, the owner of my device, have directed them to do.
Apple's approach makes easy things difficult (because one must use their APIs) and difficult things impossible (because Apple have decided that purchasers of their devices shouldn't be permitted to do things Apple wishes them not to do).
I want a general-purpose computer that I own & control in my pocket, not some stripped-down communicator owned & control by someone else.
... the market appears to be making the case that you are not the average consumer, but that's an independent variable.
I don't think this is true in the later releases is it? I get a lot more ad-hoc permission requests these days, and there's much more control in the application settings (the android app settings, not the settings the app presents).
The Play Store has no requirement that apps degrade gracefully when permissions are denied. So the result is usually the same as pre-Marshmellow. You just get more annoying popups.
I miss Cyanogenmod where I could deny a permission (e.g. contacts) and the app would have no idea it was denied (it would receive an empty list of contacts).
I'm pretty much fine with this, though the data-hostage situation you describe does seem bad.
You're right that from a user control perspective, the cyanogenmod approach is likely best.
All android phones I've owned had this option.
But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the background, no user permission is required. I think Apple does check that background APIs are not misused as part of the review process, though - I don’t think you could implement a tracking socket masquerading as a background download, for instace.
Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication.
This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way.
EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.
If you want to play audio or track gps in the background you need to do things yourself though.
But, if I recall correctly, VLC will continue a background file transfer session from its built in web server on iOS if you play a movie in the background. Otherwise it will be killed after 10 minutes.
I was going to report a bug to the app suggesting they include some ultrasonic or subsonic audio to defeat this mechanism, but it's just an arms race at that point. The phone will start looking at the total power in the audible spectrum to decide whether to kill the app or something.
This kind of thing is infuriating and prevents apps from doing anything outside of the box, stifling innovation and making users frustrated.
The Facebook app used to play a silent audio track to stay active in the background, until they got called out: https://www.reddit.com/r/iphone/comments/3opxhm/facebook_app...
By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privacy perspective. Of course Google considers that you leaking your personal info is a feature so that part probably won't change, but they should at least care about the two other points.