http://l8rs.blogspot.com/2008/05/iphone-20-sdk-limitations.html

Apple will need to address this or be surpassed by Android which surely will.

Regarding your power question, yes an open TCP/IP socket simply listening over EDGE drains about 10x power over the regular check in for SMS or voice call. This may change in future physical layers, but with standard GSM chipsets that is what we see on our scopes.

More broadly. as I argued a couple of days after Craig’s original post, both of the problems he cites are not only solvable, but largely solved in the current incarnation of mobile apps for Windows Mobile.

The way the GSM and CDMA radio works is that it tries to keep the best possible connection open between the phone and the nearest cell. In a heavy populated are like a city this is usually not a problem since you have five bars every where.
But this also means that there is ALLOT of hardware layer (OSI 1-3) data passing going on to establish the best connection between the numerous cells in view, continuously monitor the signal strengths (typically 4 or more), and worry about handover to the next tower if you are moving.
That’s allot of juice.
Additionally, keeping a TCP connection open but sending nothing guarantees the conncetion will be terminated by the carrier. Carriers are motivated to keep the scarce GPRS resources open, so they typically implement a 3-10 minute ‘kill’ window. No data passes in that time and it kills the connection. SO_KEEPALIVEs are ignored as are ICMP packets. (and you thought Comcast traffic shaping sucked). So if you use an always-on connection you have to build in your own ‘keep-alive’ packets at the application layer (OSI 6-7) instead of relying on TCP frames, OOB frames, or ICMP ethernet frames to do the work for you.

The final ‘screw you’ from the phone battery is that if have even 1 bar missing (80%) signal strength, the battery is dumping all it’s power into the radio to try to boost the signal strength. The power valve between the battery and the radio is variable and can set to low (sitting next to a cell gettin’ sterilized) or supper high (left on in the overhead on the plane).

The debate between polling and always-connected on cell phones (any cell phone) is somewhat moot. because of the pretty even trade offs in power management, it turns out that a well designed application and protocol makes MUCH more of a difference than the hardware and TCP/IP stack implementations, regardless of the network connection models.
It is a rare think these days when the application developers hold all the cards when it comes to usabillity and performance. It also means you get blamed for everything :)

-C

Possibly a Apple owned background process could handle the url handler ( sent as an SMS?) and launch the app via the url handler. Given the LaunchMe sample code might well be a possibility :-) Not sure how this helps mobilrscrobbler but it could help those of us who want our own “push” technology.

Thank you for the constructive feedback about MobileScrobbler. The next update will include a preference toggle to queue your tracks instead of transmitting them while the device is asleep. Feel free to suggest future improvements through the bug tracker on the MobileScrobbler website.

Thanks!

I hope this limitation is one of those “we can fix it in rev 1.1” kind of issues.

Personally, I think that folks are way too uptight about this: Apple surely has a plan. I believe the no-background-applications line about as readily as I believed the ajax-as-sdk line from last year.

My best guess (hope?) is that they’ll allow background processes which don’t have any UI (and potentially severe limits on memory lest they be shut down). I assume that the standard IPC tricks work in the iPhone OS?