[glhaynes]

Indeed. If multitasking comes, apps will still have to interact with everything else through well-defined, public APIs; the only place they'll have free reign will continue to be their own folder. Also, I'd expect to see some quotas enforced to guarantee that, say, background Pandora really does only take x% CPU, probably within a static amount of memory.

[stcredzero]

If multitasking comes, apps will still have to interact with everything else through well-defined, public APIs

I think that's how it should be!

[gbookman]

I'd expect to see some quotas enforced to guarantee that, say, background Pandora really does only take x% CPU, probably within a static amount of memory.

I think it would be much smarter for Apple to just give the iPhone user some sort of notification when there isn't enough memory to run the app he's trying to open. Kinda like the classic Mac OS for those that remember.

[halostatue]

That would be a very bad move and very un-Apple.

What is a user supposed to do with that sort of notification? When I launch a program, I mean to run the damned program. I don't want to be told "I can't run this, go close something else first." This would be a huge step backwards in iPhone OS usability.

I don't care as much about background apps such as Internet radio streaming (sorry, especially since Pandora isn't available in Canada, I really can't care; I found that when I could use last.fm I didn't use it that much, either, which is why I didn't subscribe—there's no value in it for me). I suspect that most phone users don't, either.

I'd be much more interested in a better notification queue, local notifications and alarms, and things like that than the ability to run programs (like Pandora) in the background.

I'd be much more interested in an API to allow searching inside an application's data than running programs in the background.

I'd be much more interested in quick ways to switch between two or three programs that I use regularly without having to go to SpringBoard than running programs in the background.

My needs aren't typical, but I think that the need to run streaming audio programs in the background is, for now, even less typical.

[gbookman]

That would be a very bad move and very un-Apple.

I actually agree, but it would be better than forcing developers to adhere to a static memory quota.

Ultimately there isn't any simple answer for the iPhone multitasking issue. Maybe Apple should create tools that let developers create "background modes" of their apps, which would take up less memory and dynamically cede control to other apps with higher priority, like the Phone.

[smokey_the_bear]

A static memory quota might be better than what we have now. Sometimes my app gets punted at 2 MB, sometimes it can use 20. Users with jailbroken phones seem to have particular problems with memory, especially when they try to take photos.

[CamperBob]

My needs aren't typical, but I think that the need to run streaming audio programs in the background is, for now, even less typical.

You're just violently wrong about this. Go over to the App Store and have a look at Pandora's reviews, if you want to see 10,000 or so users who disagree with you about the importance of background streaming.

Pandora is among the most popular apps for a reason (quick survey, how many other iPhone users reading this thread haven't used it at least a few times, if not regularly?) and the lack of background streaming is easily the #1 complaint.

Generalized multitasking, meh, but there is no technical reason why allowing a single background-streaming operation should interfere with other applications, and there's no conceivable reason why Apple couldn't allow apps to do it. They're just being, for lack of a better term, weird about it.

[halostatue]

Let's pretend for a second that you're right and that there's about 10,000 people who want background streaming, that's 0.01% of the total number of estimated worldwide users (75 million) on the iTunes platform. A percentage that small is too small for me to be "violently wrong". I suspect that 80% of users have never even heard of Pandora on or off the iPhone.

Curious, I went to the iTunes app page for Pandora: http://itunes.apple.com/us/app/pandora-radio/id284035177

Two points:

1. See that "/us/" in the URL? The Pandora Radio app is ONLY available in the U.S. This is confirmed when I went to the "Pandora Media, Inc. Web Site" link:

"We are deeply, deeply sorry to say that due to licensing constraints, we can no longer allow access to Pandora for listeners located outside of the U.S. We will continue to work diligently to realize the vision of a truly global Pandora, but for the time being we are required to restrict its use. We are very sad to have to do this, but there is no other alternative."

So, off the top, only about 50% - 55% of all iPhone OS users can care about background streaming with Pandora due to the geographic limitations involved. (Call it about 41 million possible users.) We're still only up to 0.03% of possible users if we use your number.

2. Fortunately, we've got better numbers available on that same page. At the time that I looked at it, there were 48,998 ratings for the current version and 361,593 ratings for all versions. Only three ratings/reviews are shown (a 1-star with a rant about medialets and people who complain about the lack of backgrounding; two five star that make no mention of backgrounding). Let's pretend, though, that all 361,593 ratings complain about backgrounding (despite clear evidence that they don't). When we do a quick number crunch we're still only at 0.9% of possible users talk about this and about 0.5% of worldwide users.

We could double or even quadruple the percentages that I've calculated here for alternatives to Pandora (like last.fm), and I'd still be right that the need to run streaming audio programs in the background is a mark of a highly atypical iPhone OS user. Objectively, I am not wrong about this. Your quick parenthetical survey is also asking atypical users what their opinion is. I stand by my statement that my needs aren't typical and the need for backgrounded streaming audio is, for now, even less typical.

From a UI/UX perspective, the management of backgrounded audio streaming applications is something that isn't easy. How do you stop it? How do you start it again once stopped, or do you have to visit the streaming application again? Do you conflate it with the iTunes double-home-tap? If the streaming app is stopped and iTunes isn't playing something, what should double-home-tap do?

There are apps (mostly games) out there that can detect if you're playing music in iPod; if you are, they mute their own music (and sometimes their sound effects); other times, they pause your iPod player to play their audio—and they may restart your iPod audio afterwards. How does a background audio app interact with this in such a way that doesn't require changes to these existing software titles? Should streaming apps be able to hook into iPod media play capabilities?

Every single one of these questions has to be answered—and more—and it needs to be done with as little negative impact on existing software as possible.

I'd like to see all of this happen, but don't delude yourself about your typicality in the population of iPhone OS device users.

[CamperBob]

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.

[halostatue]

If you reread what I wrote, I acknowledged that it was a limited data set for the content of reviews. If I had been able to read more reviews, I would have done so.

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