-
Website
http://www.technovia.co.uk/ -
Original page
http://www.technovia.co.uk/2008/03/craig-hockenberry-on-the-iphone-battery-life-issue.html -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
Congratulations for spinning a really positive article about the functionality of the iPhone / iPod Touch into the usual FUD FUD FUD from the companies who really wish that the iPhone didn't exist. He does actually explain in the article if you didn't cherry pick that you can pretty much achieve the same things by following Apple's guidelines...
Of course, the fact that I'm typing this on a MacBook Pro, which is currently also syncing my iPhone, and that I've owned at least one of just about every model iPod is just a cover.
Far from explaining how it's all fine and dandy, and how you can "achieve the same things using Apple guidelines", Craig states that this is an issue: that's why he says "I think Apple will address this issue in the future." Please quote exactly where he says it's not an issue. I'll be waiting for your call.
I didn't imply that you were in the pay of anyone - and I have been reading both this blog and the old version for quite some time.
What I was objecting to was that you had taken what I read as a fair and balanced coverage of programming for the iPhone by someone who actually knows what he is talking about and cherry picked a headline for hits.
What he did say was...
"Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh."
I am pretty sure that he meant it was a design failure with his software and not the iPhone as he goes on to say:
"Some have stated that Apple is limiting innovation. My opinion is that they are helping us from collectively shooting ourselves in the feet."
The way that I read that is that the SDK is compensating for the hardware's lack of battery power. A background process pinging a server every five minutes is not bad software design - it's something that could be done on other smartphones without reducing the battery life that much.
(One example of this is the Jaiku app on S60, which i a real power drainer as it's pinging for both location and presence updates frequently. It sucks battery power - but you'll still get a day's charge on an N73)
I think he was also heading off the standard responses of "But I'll be good 'cause I know what I am doing Apple, honest" with his:
"And right about now, you’re thinking “But I’ll be smart about how I use the hardware.” Sorry, bucko, but you’re the exact reason why we don’t have background processing in the current SDK. You’re living in your own little dream world."
Basically his article was saying that he's pretty certain that Apple will add functionality to make a call that will work like this but let the system manage the actual calls.
REMEMBER: The SDK is in beta. That means the people who get to work with it can report these things and Apple will develop the SDK along with the hardware.
Now, let me preface this by saying I'm not an iPhone developer. I've been reading about it and I discovered that I cannot write my killer app because Apple will not let me have a way to run in the background. So I'll just have to keep waiting. Furthermore, I know nothing of twitter's protocols, so there may be more to it than what I'm reading.
That said...
Consider what is being said: Every five minutes, it does an XML query. That's 12 times an hour. That's 48 times in four hours.
48 Twitter queries and your battery is dead? What are these queries doing?
If I had to make a guess, I would say that he is connecting to a server and not disconnecting. For example, when his daemon starts up, it connects to a server. Then it sleeps for five minutes. When it wakes up, it sends a query to the server, gets it's response, does whatever magic it does, and then goes back to sleep for five minutes. When it wakes up, it sends another query. But during those five minutes when nothing is happening, it is still connected to the server. Therefore, the radios cannot shut down.
Now why is it staying connected?
Again, I'm a long-time developer and if I had to make a guess, I'd say it's because twitter will only collect this information for logged in users. If you lose your connection, it's the same as logging out. This is generally considered a good thing for network-based services--as long as you're connected, the server knows that someone is on the other end and will mark them as being "logged in." If the connection is dropped because the user quits the application or it crashes or something, then you mark the user as being logged out.
I don't want to say it's a poor design on the server side--it isn't. But it's something that needs to be taken into account when designing server protocols for battery powered devices that can't afford to leave connections open forever. Some way to say, "Hey, I'm logging in. If my connection goes away, don't worry--I should be back in 10 minutes. Keep me logged in and hold onto that data for me until I reconnect and ask for it."
A work-around for this would actually be to have a twitter-daemon running on a plugged in computer that you can connect to in this fashion. So your computer would be connected to twitter and would store all the information that twitter sends. When your iPhone connects to your computer, it just feeds it to the iPhone. When the iPhone goes away, it goes back to storing it.
So, no, it's not about developers not being "good" about how they use the hardware. In a situation like this, there isn't really a choice. Instead, the problem is with the protocol which uses a connection to denote whether someone is connected. And there isn't really a way to solve the problem short of using an intermediary as I mentioned above.
(They also support A2DP, another egregious failing of the iPhone.)