Hacker News new | past | comments | ask | show | jobs | submit login

Best thing about those excuses are:

Every other mobile OS supports multitasking and all the smartphones i know have similar battery life. Symbian, Windows, Android, all have multitasking and yet people try to convince me that it, "not needed", "not possible", "makes the device unstable", "drains battery too much" which is just not true. My Android phone lasts at least as long as an iphone and i use multitasking all the day. It's just that the OS was truly made for this and it does it quite well.




If I leave an app running in the background that keeps the net connection open on my Nexus One, the battery goes from 100 to 0 in about 5 hours.


Well, i have atleast running: Facebook, twitter, rss aggregation, gmail and k-9mail imap idle, gtalk plus weather and my phone is at around 30% end of a normal day with a few calls and around 2hrs rss reading on my way to/from work. Only one day battery life is quite sad compared to featurephones but i'd say it's normal for the smartphone of today. Oh, and i have gps/wifi turned on that day. Android 2.1 admittedly has some big improvements around that, as on my G1 wifi/gps made a much bigger difference. According to the battery stats the display is draining by far the most power anyway.


My iphone runs ~2.5 days without a charge...


I'd bet that app was poorly written and doing something else in the background. An app that is just listening for data from an open connection should be using roughly zero CPU. But we'll try science; I've signed into AIM on my Nexus One and left it running in the background. The battery is at 81% now, I'll report back in an hour.


I'd bet that app was poorly written and doing something else in the background. An app that is just listening for data from an open connection should be using roughly zero CPU.

It would be too much work to vet every app for good concurrent programming. It's a much better idea to disallow it and add an API with resource controls later. This is the only way to protect users from resource hog apps.


If you keep a connection open it drains battery life because the chip can't power down.


Sort of. In tumult's case he's got a connection that's actively downloading data and playing music. I would assume that'd keep the radio chipset (either wifi or cell, whichever he's using) and the CPU both from being able to switch to a lower power standby mode.

However, you can have an open but idle connection open in the background with only minimal battery drain. That's how pretty much every kind of push notification or IM system works, even on cell phones.


77% after an hour.


Sign in with the connection currently using WiFi instead of GPRS/3G, and it will keep the WiFi hardware on, which is what kills it. There is no way for a normal user to know that they need to open new, persistent connections over a connection type that uses the cellular modem instead of the WiFi. And Android defaults to using WiFi for new connections if the WiFi hardware is powered on and connected to a network.

The best way to save battery on an Android phone is to turn off WiFi unless you need it at some point during the day. iPhone will stop attempting to do push notifications and the background Apple apps will disconnect if the only available connection is WiFi.

I'd also like to point out that "I bet the app was poorly written" is exactly the situation Apple is currently avoiding until they are confident they have a reasonable technical solution to it.


I was signed in using WiFi, and I normally have WiFi enabled all the time and get over 24 hours of battery life. Maybe some wireless chipsets suck too much power, but it doesn't appear to be a problem on the N1.


Maybe we're doing something different, but I cannot get my Nexus One to stay alive for longer than 5 hours with an active net connection. It if it's a low-traffic connection (calm IRC channels, occasional email polling) it will last a day (same with my G1) but streaming radio, etc will leave it dead in a long afternoon.


Ah.. Streaming radio. By active net connection I thought you meant email polling, IM, etc.

Playing streaming video will kill the battery pretty decently, but IMHO that seems fair. Your keeping the radio pretty busy, the audio hardware, the cpu, etc.

I'd actually like to hear from an iPhone user whether they can run Pandora or Last.fm for 5 hours straight without killing their battery either.


I'm an iPhone user as well, and it also kills the iPhone. the point was that on iPhone, 3rd party apps are not given the opportunity to do this without the user being aware (because it's in the foreground.) i've had a runaway android app kill my phone after it screwed up and started devouring resources in the background while it was in my pocket.


The user would have to be aware of streaming audio. Also, as stated elsewhere in this thread, apps don't normally run in the background on Android either. I'm curious what app you believe killed your battery life in the background? That sounds... unusual.


Apps normally run in the background all the time in Android. I know which app it was (meebo) because I can view the stats afterwards. Also, to help alleviate some of your confusion, we are talking about background processes, not just streaming audio.


Apps only run in the background if they specifically register a background service. Usually this is when you click a button in the apps preferences like "update in background", etc.

Read this: http://geekfor.me/faq/you-shouldnt-be-using-a-task-killer-wi...


Wow, thanks for this point. Just reminded me to turn off the android phone I was using but had stuck in the drawer.


Android is just now getting reasonable battery life with 2.x when heavy multitasking is in use. Many people need to have process cleaning apps to have zippy performance without rebooting the phone every few days. (And the fact not all android phones are upgradeable to 2.x is an issue meaning many still have crappy multitasking battery life).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: