4 ms·
Do you get acceptable battery life running an IRC client in the background? The client has to keep a persistent data connection open and will be constantly tran
by jsz0 17y ago
Do you get acceptable battery life running an IRC client in the background? The client has to keep a persistent data connection open and will be constantly transferring data. I've not had much luck with IM clients on BlackBerry, WebOS or Android. I guess the bigger question is if the user's battery should be drained in a situation where they don't understand the ramifications of what they're doing. If you're playing a 3D game for an hour you're focused on the screen and can watch the battery meter go down. If you open the IRC client, forget about it, pocket the phone, and a few hours later fall down with a heart attack -- unable to call 911 that's a different issue entirely.
I think some companies do take that ethical consideration very seriously. The company I work for provides a digital phone service with E911 and our corporate culture has definitely changed since this service launched. The possibility of interrupting a customer's service even for a few minutes in the middle of the night makes me uncomfortable. There's always that possibility someone will be reaching for the phone to call 911 and you definitely don't want to be responsible for playing any role in preventing it.
- thwarted 17y agoI stay logged into gtalk on my Nexus One continuously. I don't notice any significant battery drain because of it, and I often have longish conversations with people while waiting for the train via gtalk. The gtalk app doesn't even show up as a significant user of battery power in the "Battery Use" list.
- biafra 17y agoThe reason is that Google has control over the XMPP server. They do not need to send you presence notification if your gtalk client is not in foreground. Just staying online is not the problem. The problem is that usually with XMPP the server sends presence asynchronously. There is no standardized way for a client to request not being send those. If you happen to have 200 or more users in your roster there is always someone going away or coming back. Receiving those packets is draining the battery. If your XMPP server happens to support privacy lists you can request not being send those presence notifications for a while. But at least some servers do not send the last presence when you clear that privacy list. And at least some of those servers do not allow you to get presence for all users in your roster by sending only one (unaddressed) request for presence. You have either to send all users in your roster that request or drop the connection and reconnect to get the current presence of all users.
- AceJohnny 17y agoActually, from talking with the OneSocialWeb [1] and BuddyCloud [2] guys, I understood that Android phones have a really sophisticated "always connected" philosophy. The main CPU can go into deep sleep and the phone still maintains a persistent data connection, waking up the CPU on incoming data. That's for the low-level IP stuff. TCP-over-GSM really sucks your battery. XMPP doesn't (yet) have a standardized way of filtering data. Using Privacy Lists is a workable hack. Google implemented their own thing (using Protocol Buffers [3] to replace XML-on-the-wire, instead of gzipping as the XSF recommends). Process One has their own system as well for OneTeam [4]. The future ideal is to use SIFT [5], but it is still experimental and as far as I know, only Prosody [6] has partially implemented it. [1] http://onesocialweb.org/ http://onesocialweb.org/ [2] http://buddycloud.com/ http://buddycloud.com/ [3] http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/ [4] http://www.process-one.net/en/solutions/oneteam_iphone/ http://www.process-one.net/en/solutions/oneteam_iphone/ [5] http://xmpp.org/extensions/xep-0273.html http://xmpp.org/extensions/xep-0273.html [6] http://prosody.im/ http://prosody.im/ (dammit, how do I embed URLs in the reply?)