MP support is limited to the seven APIs. People may make assumptions of what multitasking means, but if a function is outside of the APIs then that assumption would be wrong.
Yes, but one of the seven APIs (Local Notification) opens the door to having your app do any kind of processing in background.
There's nothing faux about it. It's just a bit unconventional from the way developers are used to thinking about background processing.
The app does get callbacks from the APIs. Otherwise, the app wouldn't have any control over what goes on during background processing. Yes, a couple of them COULD function without any interaction with the app whatsoever (for example, playing music) but for the most part, it is NECESSARY for the API to interact with the app while in background. The app is getting control at certain points during background processing, and is NOT limited to calling just the 7 APIs during that time that it has control.
As an example, GPS. What could the GPS system possibly do for an app without the app receiving notifications from the GPS system? Absolutely nothing useful. So, the app requests that the GPS system notify it when certain events have occurred - say, you've moved 100 yards or more, or accuracy has changed. At this point the app gets a callback, and can do pretty much anything it wants - for example, update internal memory, save some data in a file, or even send some data over the network. What it CAN'T do is update the UI. That's specifically disallowed. I assume, though, that there's some way to notify the user that you'd like them to switch to the app to take a look-see, and then the app can update the UI.
Local Notifications are a catch-all. You can use that API to arrange to have your app "wake up" either for a one-time event or periodically. On Windows or Linux, this would be called a timer callback. (I think there's more to Local Notifications than that - for example, I think it can be used for some inter-app messaging.) Pretty much anything an app could do by simply having it's main thread continue to run can be done using periodic timer callbacks. I can see how this could complicate I/O programming - I assume an app won't be able to simply wait on a completion (while handling a background callback), for example. In conventional background or thread processing, you'd just make an I/O call, and the thread would be suspended and woken-up when the I/O is completed. What apps will have to do is poll for I/O completion. If the I/O isn't complete, return from the callback, and check again on the next periodic callback. Until very recently, this was the preferred way of dealing with I/O on Unix-like systems anyway. Big deal. A little back to the future.
From what I've read, (and corresponding to my previous prediction) background tasks will get shorter time-slices, so developers need to be efficient in their background processing, or they may not get enough processor time to complete the desired task(s). Good. There are a lot of sloppy iPhone developers, and, frankly, background processing is going to be over their heads. They are going to bitch and whine.
I'm a developer. I've been writing stuff that is massively multi-tasked (Windows, Linux) for years. This is exactly what I had hoped for. I had hoped Apple would limit the amount of stupidity that developers could build-in to their apps.
Letting an app's main thread run in background would have led to the Windows Mobile-ization of the iPhone. Utter chaos and sluggish next-to-useless performance.
The ONLY limitation this scheme imposes is that you can't view the UI from more than one app at a time. There's too little screen real-estate on the iPhone for that, anyway. I can see them introducing home screen widgets at some point, but that's it. iPad might be a different case.
The app switcher in OS 4.0 does not allow you to "kill the application," because the application is not running when it is not in the foreground.
Depends on the app. An app that doesn't use any of the 7 background APIs is not doing anything and is just asleep. If it DOES use any of those APIs, it most certainly is running when not in the foreground. (At those points when the APIs give the app control via a callback.)
The only difference from what we are used to is that the interaction model between the OS and application is reversed during background processing. It doesn't make any practical difference for the end user.
It's unfortunate that there's so much confusion over this, because non-developers are trying to understand some fairly complex stuff. Any decent developer is going to "get it" immediately. It's up to the technical press now to clear this up, since Apple has done such a bad job of it. I hope my comments have helped.
