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

I'm glad he made this point, but he's still not giving Android enough credit. With Android, apps can create a service that can run and do whatever it likes. It's not limited to a couple APIs.

People are pretty jazzed about Skype running in the background, but they are going to be dissapointed when they realize that only means that you can keep the current call running while you leave the app. Skype still won't be able to stay open and listen for incoming calls. Same with chat or IRC apps.

Not true. The background services offered by the OS allow the apps to still receive calls/IMs etc while not in the foreground. According to Apple press release:

"These services include background audio, so apps like Pandora can play music in the background, and VoIP, so VoIP apps can receive a VoIP call even when the iPhone is asleep or the user is running other apps."


cpr and swernli are correct: Skype can "listen" for incoming calls.

This is demoed by Skype's head of product development, David Ponsford around 00:22:20 in the video of the iPhone OS 4 Event: http://events.apple.com.edgesuite.net/1004fk8d5gt/event/ (I personally found most of the event rather interesting, if you have about an hour to spare.)

That could have been done with a tweak to push notifications, no?

Your last paragraph isn't true about VOIP apps, but I can't say more due to the NDA.

I really don't understand why Apple has an NDA on its essentially public developer program. There are so many iPhone developers that all the standard rules and agreements will be made public almost instantly no matter what.

No, part of the privilege of being a registered iPhone developer is you get access to beta SDKs and information that the public does not. The idea is to give iPhone developers who are in their program a head start. The fear of getting booted from Apple's program is usually sufficient to bite your tongue before you saying something in public that should not be discussed.

As an example: now that the iPad SDK is no longer under NDA: one of the most interesting APIs in iPhone OS 3.2 (iPad) is MPMoviePlayerController gaining the backgroundView and view properties. Basically, it opened up a whole arena of interactive video applications that overlay graphics on top of live or recorded video (think watching baseball game on iPad and pulling up player's on-base stats by clicking on magic button hovering near base, true interactive TV, interactive remote control with show previews...)


And part of the problem is what we see here, which is that potentially incorrect information cannot be authoritatively debunked, perhaps for months. This gives plenty of time for the wrong "facts" to get lodged in people's heads, so even when the truth comes out people will carry on with false beliefs.

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.

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

Actually, 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/ [2] http://buddycloud.com/ [3] http://code.google.com/p/protobuf/ [4] http://www.process-one.net/en/solutions/oneteam_iphone/ [5] http://xmpp.org/extensions/xep-0273.html [6] http://prosody.im/ (dammit, how do I embed URLs in the reply?)

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

My mistake. I just looked through some of the documentation, and I was wrong. Previously I just read some of Apple's high-level docs, which didn't make it clear.

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