[Macworld]

Post your comments for Some background on background processes here

[TheBum]

"Consider a program that allows you to connect remotely to your Mac at home, for instance. Such programs exist today for jailbroken iPhones, and I believe they will exist in the App Store as well. Such a program really needs to be able to run in the background—otherwise, every time you exit that program, you’ll break the connection to the home machine (because the network link will be closed)."
This is a bad example IMO. Why couldn't the very same program use the push notification API to keep the network connection open? Nothing says that the program has to actually get push notifications.

[TheBum]

I realized I may have been hasty in my last comment. I should have qualified it by saying that, since we don't know what the push notification API will look like, it's impossible to know whether it could be used for such a purpose. Or, since Apple will already be providing a persistent connection capability with push notifications, who's to say they won't support other types of persistent connections.

[bsfa]

I was thinking about this. My TomTom silences the radio of my car when it gives directions. Suppose you use your iPhone as the source of music in your car, you wouldn't be able to use it for navigation concurrently. Meh.
Bert

[cnate]

I really hope that the dev team figures out a way to port original applications and services that run in the background over to the iPhone 2.0 OS... Under 1.1.4, I can set up an encrypted SSH tunnel in the terminal program and exit it to start VNSea for a secure VNC connection to control my mac remotely over the internet... It's all of the power of your mac in your pocket from anywhere in the world that has an internet connection...
Because I don't want to choose between that functionality and being able to get on my campus 802.1x wireless network...

[doglesby]

bsfa said:

I was thinking about this. My TomTom silences the radio of my car when it gives directions. Suppose you use your iPhone as the source of music in your car, you wouldn't be able to use it for navigation concurrently. Meh.

I don't see why, iPod is one of those apps that can run in the background. You would have to quit TomTom to skip/rewind/pause/etc. but it should be trivial to resume (it can remember where you're going and discover where you are).

[doglesby]

Macworld said:

Another possible concern is privacy?how will Apple insure that the messages that flow through its servers aren?t compromised before they reach their destination? Will the notification messages be encrypted, for instance?

I don't see why Apple is on the hook for better security than the original service. Surely if the service encrypts messages, Apple won't decrypt them. That's all I would expect.

[doglesby]

This is basically the RIM approach, only more flexible and powerful.

I loved Forstall's reaction to the task manager. Highlight of the keynote.

[MarkM]

You don't have to exit the current application to pause, ff, rewind, etc, the iPod functions. There's a setting (under General->Home Button) that lets a double-click of the home button bring up an iPod control overlay. Very useful!

[SlotcarBob]

Not really (maybe). I think Apple is laying that on developers, and may not put the restriction on their own applications. I think this is to be seen.

[weapau]

ensure vs. insure. Sorry, just a pet peeve. I did just look it up, and found some ambiguity, so you're the editor.

My point is, if you can only have one thing going on at a time, that means we are going to have to be staring at our iPhones, waiting for things to happen instead of getting stuff done. I'm not sure I like that, I want applications to be working for me in the background.

[SMJH]

I think their rejection of background processing is too broad. There's a big difference between a process in the background which sits in an endless loop and one that sleeps (i.e. is suspended) until an event arrives after which it performs a tiny amount of processing and sleeps again until the next event. The impact of this second type of background process on performance would be hard to even detect.

[Mack]

Apple haven't come up with a "push" solution they have really come up with a "push-pull" solution.
The event notification (only) is pushed to the device but the corresponding event data remains on the server until the user wakes up the application - at which time the application "pulls" the event data down to the device.
The first problem with this is that it depends on the user having connectivity not when the notification is sent but when the user chooses to respond and the application is activated.
In a true "push" solution, data would be transferred to an iPhone belonging to (say) a user sitting on a train. After the data had landed the iPhone user would be notified, the train could then go into a tunnel but the iPhone user would still be able to access the data (message, update, e-mail, document, etc.).
The second problem is that Apple still provides no solution for data flowing in the other direction. Many potential applications could be devised that were dependent on a server receiving data updates coming from the iPhone.
For example, a tracking application that tells a central operator where in a district all the sales representatives are throughout the day. In the keynote we saw a tracking application where the iPhone tracks itself - but what about a centralised tracking system?
What about a plug-in for a social Web site that automatically updates my friends with what song I am listening to, or what video I am watching, or who I am speaking to on my iPhone, in real time?
Apple has providing a solution that will keep some application developers happy, but they will have to dig deeper before everyone is satisfied.

[Demonic_Rush]

What about iPod Touches? THEY don't have a constant connection to the net due to a lack of 3G/EDGE.
I don't want to have this background thing forced on the apps. I think the dev team should decide on that and even then, if they choose to use Unified Push, they should have a version w/ BG processes.
It's a really subtle way of bullying ppl into an iPhone when they can't/ don't want to change carriers