| You need to read more than 3 reviews to understand the annoyance out there. Put it another way: remember all the whining and moaning about the lack of cut-and-paste support? How many people do you think have ever used that feature, now that Apple finally gave in and added it? I don't even remember how it works, myself. If the survey data were available, I'd bet $1000 that more users have consciously wished for background audio playback than have ever even thought about cutting and pasting text on their iPhones. To answer your UI question, the way background streaming should work is for Apple to allow apps to set whatever flag that the iPod app sets. Yes, you should have to revisit the app to stop and restart a background stream, just as you do with the iPod app. Users understand and expect this. Launching another sound-playing app, including the iPod, will terminate whatever remains of the streaming app's process. There is no need to alter the behavior of the double-home shortcut, or anything else. Yes, other apps should be able to detect the presence of a background stream and react accordingly. Whatever API they use to detect activity from the iPod app should return the same result if a Pandora-like user app is running. If the best/only way to facilitate this is to allow the iPod app itself to support third-party streaming extensions, then that's fine. It is trivial for any operating system to schedule an application with only just enough CPU time to conduct basic streaming operations. The iPhone's CPU is fast, almost in the same class as the original Xbox's CPU. Trust me (or not), they could enable background streaming without interfering with other apps or significantly harming battery life. |
My main point (which I fear you missed) was that I cannot be violently wrong about the demand for background audio streaming, given that less than one percent of all iPhone OS device users who can use Pandora Radio have rated it.
I find your attitude bizarre; Apple didn't "give in and [add]" copy/paste. They figured out the right UI/UX metaphors and added the feature when they had it right. Look at the problems that people have been complaining about with the usability of the Nexus One's copy/paste implementation.
Apple will do the same with background applications when they get the UI/UX metaphors and the appropriate battery consumption issues dealt with appropriately.
Your assessment of the ability to enable background audio streaming "without interfering with other apps or significantly harming battery life" is, well, wrong. If this were the case, I wouldn't experience periodic random slowdowns of my iPhone 3G (even in SpringBoard!) that appear to be related to when the radio is waking up and sending or receiving.
Your assertion about the battery life is utter nonsense, since streaming audio requires an active data radio (which is a huge battery drain) and CPU activity. The CPU will be required to coordinate the data connection and decode the data from the network stream into an audio stream; if the data isn't in MP3 or AAC format on the network, the CPU will also be required to process the data into one of the supported formats. Remember that all iPhone OS devices have dedicated audio codec chips for processing MP3 and AAC audio.
The radio, however, is going to be the key point on battery drain. I stopped using a hands-free Bluetooth headset (I now use a hands-free Bluetooth speaker in the car) because simply having the Bluetooth connection active drained my battery faster than anything else. I tried using my iPhone as a proximity token for my computer at work and found the exact same problem (and absolutely no data was being exchanged).
At an OS level yes, it's trivial to schedule this. Above the kernel level, though, it's still pretty damned hard. Achievable, but Apple have shown themselves to be perfectionists, and if iPhone 4.0 is going to allow background audio streaming, it will be because they've figured out how to do it right (and it could easily include restrictions on the format of data being transferred).