Google Latitude Arrives For the iPhone — As a Web App 195
An anonymous reader writes "After months of waiting, the Google Latitude social maps service finally arrived for the iPhone ... but thanks to an Apple rejection of the natively developed app, it's a web app. Says Google on their blog, 'We worked closely with Apple to bring Latitude to the iPhone in a way Apple thought would be best for iPhone users. After we developed a Latitude application for the iPhone, Apple requested we release Latitude as a web application in order to avoid confusion with Maps on the iPhone.' But it gets worse for iPhone users: 'Unfortunately, since there is no mechanism for applications to run in the background on iPhone (which applies to browser-based web apps as well), we're not able to provide continuous background location updates in the same way that we can for Latitude users on Android, BlackBerry, Symbian and Windows Mobile.' Latitude has been sprouting new features lately and is an interesting take on social networking, but it looks like Apple is determined to ensure its users only get a seriously crippled implementation compared to the Android and WinMo versions. PC World put it less politely than Google did, saying, 'Google's new Latitude Web app for iPhone is so hamstrung that Apple customers may be wishing they had a BlackBerry or Android handset instead.'"
If you don't like it let Apple know (Score:1, Informative)
Re:background (Score:2, Informative)
Re:Look into the crystal ball (Score:5, Informative)
Running an active TCP session for an IM client constantly would light up much more of the iPhone's hardware, and drain the battery that much faster.
Well, not exactly....
An active TCP session is EXACTLY what Apple's Push Notification Service [apple.com] uses.
Its an extended version of ActivSync [microsoft.com], Licensed from Microsoft.
It works like this:
You open a TCP connection with an Apple Notification server, and shutdown the radio, leaving the connection open, by never explicitly closing it. With the radio down, the phone is Saving power.
Periodically, you wake up the radio, check if the TCP socket is readable. If so, you read it, and notify the user, and optionally launch that application that the notification was destined for.
If the socket failed, (timed out, network dropped, etc) you reestablish the socket.
Since TCP timeout is usually on the order of 12 minutes or longer, this happens only about 5 times an hour.
Checking socket readability takes just a tiny bit of power for a very very short time. So your radio is on for a few seconds every hour. (Which it is anyway, listening for incoming calls).
Apple's push notification leverages this single socket connection to an unlimited number of applications in the iPhone, by having a single daemon watching the socket, signaling the target app, and notifying the user.
It operates similar to InetD [about.com] in Linux, other than instead of waiting for new connections, it is watching existing ones. In fact, there is some discussion as to whether ActiveSync is even patentable because it is so obvious.
And to be perfectly pedantic, Antennas do not consume any power when receiving.
Re:Look into the crystal ball (Score:3, Informative)
The iPhone is just a Darwin machine, which all of us here should know is based on FreeBSD. It, therefore, has a very good scheduler.
The iPhone is a Darwin machine, which all of us here should know is not based on FreeBSD, but Mach with a bunch of modifications and a BSD runtime layer on top. In fact, MacOS X has a pretty poor scheduler, as Anand et al have benchmarked and anybody's personal experience should corroborate.
Which has little to do with Apple's decision to forbid third-party background processes.