A thought on OS 4.0 Multitasking

[Carniphage]

I have the impression that those apps are in background or at least freezed, because since I open them again they are where I left them.

Any app that is quit, remains in memory frozen. Which means it can be re-started for immediate relaunch.
The relaunch is instant and preserves the context from when the app was frozen.
But these frozen-apps do not place any additional demand on the system. They don't cause a slowdown. They just occupy some memory. When the system eventually runs out of RAM - the oldest app is kicked out.

So there is no user-benefit in manually quitting applications.

C.

 

[mrblack927]

Okay, everyone in this discussion seems to be taking one of two sides:

1) The quick app launcher (double tap) has nothing to do with multitasking and you shouldn't worry about it because it's basically just a "recent apps" shortcut menu
2) The quick app launcher IS directly tied to multitasking and lets you quit apps that are in one of the seven "multitasking modes"

To me, it seems like 2 is the more plausible explanation, and here's why: Multitasking apps can still take up resources. Everyone is talking about the "freeze state" API but that's just one of the seven that are included. You don't think apps that are playing music still use resources? What about apps that are "finishing an operation after quit"? The other 6 APIs all use resources when they're running in the background and they should all have a way to force quit. This is what I believe Apple intended the quick launch bar's "quit" function to be used for. If the app is designed well, the impact should be minimal and you should never have to manually quit apps (as many people have pointed out), but with any software development platform, there is the opportunity for ABUSE. This is why we have that option available.

 

[shandyman]

Okay, everyone in this discussion seems to be taking one of two sides:

1) The quick app launcher (double tap) has nothing to do with multitasking and you shouldn't worry about it because it's basically just a "recent apps" shortcut menu
2) The quick app launcher IS directly tied to multitasking and lets you quit apps that are in one of the seven "multitasking modes"

To me, it seems like 2 is the more plausible explanation, and here's why: Multitasking apps can still take up resources. Everyone is talking about the "freeze state" API but that's just one of the seven that are included. You don't think apps that are playing music still use resources? What about apps that are "finishing an operation after quit"? The other 6 APIs all use resources when they're running in the background and they should all have a way to force quit. This is what I believe Apple intended the quick launch bar's "quit" function to be used for. If the app is designed well, the impact should be minimal and you should never have to manually quit apps (as many people have pointed out), but with any software development platform, there is the opportunity for ABUSE. This is why we have that option available.

from the way it was discussed at the keynote, its not 7 set API's, but only 7 of all the existing API's can be used in regards to multitasking.

 

[thelatinist]

The question of "how to terminate an app" I think is not stupid. I hope that the "when it needs space the system will kill the less used app" is not yet in the OS 4.0 beta 2, because if it is there, it just doesn't work.

I have the Beta installed on my 3GS and as soon as I use some ipod,itunes,settings,mail,notes,clock and etcetera, they are all in background and my iPhone turns into a slow turtle. The only way to give him some air is to manually kill apps, but is kinda frustrating...

You are confusing appearance in the quick launch toolbar with running in the background. With the exception of the iPod and mail applications (which have always run in the background), none of the applications you cite actually run in the background. When Settings, Notes, iTunes, etc. are closed all that happens is that their current state is saved and their icon is added to the quick launch toolbar. There is no way that removing their icon from the quick launch bar affects your phone's speed.

Except for the native apps that have always run in the background (phone, mail, iPod, Safari), no apps run in the background. Apple's multitasking does not consist of implementing background applications. It is simply a combination of better saved states for closed apps and the introduction of seven system services (built into the OS) which can continue some of the functions of applications after they are closed (please note: there currently is not even a single app which makes use of those system services). This does not mean that the apps continue to run in the background and consume system resources. On the contrary, the entire point of the way Apple is implementing "multitasking" is to prevent that.

I have the impression that those apps are in background or at least freezed, because since I open them again they are where I left them.

This is simply a saved state. The app is closed, but it saves information about where you were in the app before it closes so it can open up where you left off. That doesn't mean the app is consuming system resources.

 

[Theappmachine]

When my iPhone slows down, and I kill some native app, it gets back on its legs. The cause must be somewhere else then, and is not in multitasking.

 

[Mike777]

Multitasking is needed because the iPad is a larger device. It seems to me quite likely I would want to copy some things from my email to another document and leave them all open while i watch a movie to unwind with the kids then come back.

In short, I don't care if it multitasks or not. I don't care about the details, just make it seem like things are the way the were when I left them, like in real life.

Thats all. And if I leave the tv on in the background i expect it to stay on don't i

 

[Carniphage]

Y
Except for the native apps that have always run in the background (phone, mail, iPod, Safari), no apps run in the background. Apple's multitasking does not consist of implementing background applications. It is simply a combination of better saved states for closed apps and the introduction of seven system services (built into the OS) which can continue some of the functions of applications after they are closed (

That's not completely true.
In most cases, apps are just frozen. And some of these APIs hand-over background functionality to the OS, to allow such features as streaming of audio.

But if you look at the Keynote, consider the TomTom GPS demo.

That application is not simply handing-over some service to the OS.
The app continues to monitor GPS location, recompute the route based on location, and make voice announcements based on the updated route.

That clearly *is* running the entire app in background. Apple tolerates this because such applications should only run when the device is on a charging cradle.

C.

 

[shandyman]

But if you look at the Keynote, consider the TomTom GPS demo.

That application is not simply handing-over some service to the OS.
The app continues to monitor GPS location, recompute the route based on location, and make voice announcements based on the updated route.

That clearly *is* running the entire app in background. Apple tolerates this because such applications should only run when the device is on a charging cradle.

C.

its not running the entire app, just certain necessary processes....

 

[Carniphage]

its not running the entire app, just certain necessary processes....

Just those processes like.
The continuous monitoring of the GPS location.
The continuous comparison with that position with the computed route.
The continuous announcement of upcoming guidance.
Handling the eventuality of going off-route and re-computing the new route using the entire route database, to create a new route.
...and so on...

In this case, this is conventional pre-emptive multi-tasking.

C.

 

[shandyman]

Just those processes like.
The continuous monitoring of the GPS location.
The continuous comparison with that position with the computed route.
The continuous announcement of upcoming guidance.
Handling the eventuality of going off-route and re-computing the new route using the entire route database, to create a new route.
...and so on...

In this case, this is conventional pre-emptive multi-tasking.

C.

its not the whole app running and without knowing the coding for it used, all you're making is guesses as to what it *might* run, they may have simplified it down.

 

[Carniphage]

its not the whole app running and without knowing the coding for it used, all you're making is guesses as to what it *might* run, they may have simplified it down.

To work at all in background, the TomTom app has to do all these things.

In other words, the App is clearly doing everything it does in foreground, with the exception of updating the display.

There is absolutely no possibility that these functions could be handed over to some Apple-written OS services layer.

C.

 

[shandyman]

To work at all in background, the TomTom app has to do all these things.

In other words, the App is clearly doing everything it does in foreground, with the exception of updating the display.

There is absolutely no possibility that these functions could be handed over to some Apple-written OS services layer.

C.

again, you're guessing and assuming that its running everything. i doubt it would be running everything, for starters its obviously not running any graphics related processes. ergo not running everything it does in the foreground. plus as i said, for all we know, they've stripped it down to basic core processes for running in the background. obviously you won't accept that unless we get a tomtom dev in here...

 

[thelatinist]

To work at all in background, the TomTom app has to do all these things.

In other words, the App is clearly doing everything it does in foreground, with the exception of updating the display.

There is absolutely no possibility that these functions could be handed over to some Apple-written OS services layer.

C.

I think it's too early to speculate about that; I would not at all be surprised if Apple has worked to incorporate those functions into the API. We'll have to wait to actually look at how it functions. My guess is that you are right and that the task-completion API will allow a limited third-party app to run in the background. But we won't know until we see how it works.

 

[Carniphage]

I think it's too early to speculate about that; I would not at all be surprised if Apple has worked to incorporate those functions into the API. We'll have to wait to actually look at how it functions. My guess is that you are right and that the task-completion API will allow a limited third-party app to run in the background. But we won't know until we see how it works.

TomTom works using its own navigational database. Stored in its own format.
When the driver goes off-route, a fresh route has to be calculated by solving a new route based on the new location.

The navigation API appears to allow an app to run continuously in background.

C.

 

[Mr. Chewbacca]

I don’t see any reason why we should not be able to manually "quit" apps on the launcher.

Correct me if I'm wrong but under the system if I launch Pandora then I open a few news apps, check my mail and fb, log breakfast in lose it and scan the empty box with grocery iq I have already opened like 8 apps and they system may just shut down Pandora since I opened that first.

Wouldn’t it make sense to have a feature in the quick launch bar that lets flick the icon up to remove it from the list. Even if it didn’t close the app I wanted to keep on the bar (Pandora or a frozen game) it would have so many things to scroll through that it would lose the convenience factor.