4 ms·

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

lol768 8y ago
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.
- JustSomeNobody 8y ago
  This is what the push message API in iOS is for. It wakes up the app when messages come in.
  - jabberthemutt 8y ago
    Which means there is a third party eavesdropping on chat.
  - lol768 8y ago
    > This is what the push message API in iOS is for. It wakes up the app when messages come in. 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.
feikname 8y ago
Receiving messages (aka "listening" in server jargon) is essentially a background task, constantly probing to check for any changes.
- jsjohnst 8y ago
  I think the point being made is that’s a terrible use of resources, not only are you keeping the app running, but you are also forcing the power hungry LTE radio to stay on more. 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.
  - admax88q 8y ago
    > sending push notifications when your app needs 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.
    - fixermark 8y ago
      Do push notifications take advantage of knowledge of the physical layer of the network? 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."
    - jsjohnst 8y ago
      > How do you think push notifications work? 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?
- JustSomeNobody 8y ago
  Right. That's why there's an API for it. Each app doesn't have to stay awake listening. The OS will wake the app up.
  - feikname 8y ago
    Oh, that does make sense. 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.
toast0 8y ago
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 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.
- fixermark 8y ago
  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.
  - int_19h 8y ago
    Well-designed or not, it exists, and sometimes you just want to use it, without a lecture on how it's suboptimal.
    - fixermark 8y ago
      That's fine. you are "free" to hack your own version of Android that modifies the APIs to disregard power-management best practices. ... 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 ;) ).

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.

JustSomeNobody 8y ago
This is what the push message API in iOS is for. It wakes up the app when messages come in.
- jabberthemutt 8y ago
  Which means there is a third party eavesdropping on chat.
- lol768 8y ago
  > This is what the push message API in iOS is for. It wakes up the app when messages come in. 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.

feikname 8y ago

Receiving messages (aka "listening" in server jargon) is essentially a background task, constantly probing to check for any changes.

jsjohnst 8y ago
I think the point being made is that’s a terrible use of resources, not only are you keeping the app running, but you are also forcing the power hungry LTE radio to stay on more. 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.
- admax88q 8y ago
  > sending push notifications when your app needs 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.
  - fixermark 8y ago
    Do push notifications take advantage of knowledge of the physical layer of the network? 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."
  - jsjohnst 8y ago
    > How do you think push notifications work? 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?
JustSomeNobody 8y ago
Right. That's why there's an API for it. Each app doesn't have to stay awake listening. The OS will wake the app up.
- feikname 8y ago
  Oh, that does make sense. 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.

toast0 8y ago

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 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.

fixermark 8y ago
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.
- int_19h 8y ago
  Well-designed or not, it exists, and sometimes you just want to use it, without a lecture on how it's suboptimal.
  - fixermark 8y ago
    That's fine. you are "free" to hack your own version of Android that modifies the APIs to disregard power-management best practices. ... 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 ;) ).