I have a feeling that backgrounding will not make a surprise appearance at WWDC or the new iPhone.
The amount of RAM currently in the iPhone is minimal. It's just enough for the core processes and a third party application. Heck, many resource intesive apps in the store specifically request that a user reboots the iPhone to flush memory. (If you have a jailbroken iPhone, log into ssh and run a top, then cycle through your most-used apps. You'll notice that the amount of free memory is tight!)
From a technical standpoint, the biggest difference between OS 2.x and 3.x is the re-engineering of the Springboard. If you notice, many of the 3.0 features mentioned at the last conference specifically relate to the Springboard. I think that with a beefier Springboard, as well as the issues that some developers have faced with memory issues and crashes, a 128MB memory upgrade would be specifically aimed at addressing these issues, not the ability to background applications.
You also have a bunch of other issues like hardware prioritization. If two concurrently running apps both use sound (let's say Pandora and Skype), which app gets priority? If two request the GPS, which app gets access first? These types of methodology-style issues are not addressed in the 3.0 API.
I do feel that if Apple is probably looking into solutions. I think that push notifications are just a first step. The centralized push concept solves the problem of having multiple running applications making network requests.
If Apple considers backgrounding, I could see them taking push notifications one step forward to allow for an application to make network requests to a "push framework" which centralizes network requests to one source. Once you throw the iPhone on standby, this framework could notify the push server so that it can "pause" the network activity. Once the phone is "on" again, this framework pulls the "paused" data from the push server and connects it up to the apps using the framework. This would reduce network requests and prevent battery drainage whenever the phone is on standby.
The amount of RAM currently in the iPhone is minimal. It's just enough for the core processes and a third party application. Heck, many resource intesive apps in the store specifically request that a user reboots the iPhone to flush memory. (If you have a jailbroken iPhone, log into ssh and run a top, then cycle through your most-used apps. You'll notice that the amount of free memory is tight!)
From a technical standpoint, the biggest difference between OS 2.x and 3.x is the re-engineering of the Springboard. If you notice, many of the 3.0 features mentioned at the last conference specifically relate to the Springboard. I think that with a beefier Springboard, as well as the issues that some developers have faced with memory issues and crashes, a 128MB memory upgrade would be specifically aimed at addressing these issues, not the ability to background applications.
You also have a bunch of other issues like hardware prioritization. If two concurrently running apps both use sound (let's say Pandora and Skype), which app gets priority? If two request the GPS, which app gets access first? These types of methodology-style issues are not addressed in the 3.0 API.
I do feel that if Apple is probably looking into solutions. I think that push notifications are just a first step. The centralized push concept solves the problem of having multiple running applications making network requests.
If Apple considers backgrounding, I could see them taking push notifications one step forward to allow for an application to make network requests to a "push framework" which centralizes network requests to one source. Once you throw the iPhone on standby, this framework could notify the push server so that it can "pause" the network activity. Once the phone is "on" again, this framework pulls the "paused" data from the push server and connects it up to the apps using the framework. This would reduce network requests and prevent battery drainage whenever the phone is on standby.