OS 4.0 Multitasking will have to be coded for in the app?

[HXGuy]

Is that correct?

I can understand why they did it like that...but are all app makers really going to go back and recode their apps for this? We are talking about 150,000+ apps...some of them may not even work on apps anymore.

I wonder how many apps will work with multitasking on day one?

 

[miles01110]

It's apparently very easy to modify the apps to work with 4.0's features.

 

[slpdLoad]

Yes, that is correct.

Not only will the APIs make it easyto implement, but I don't think that every app would benefit in any real way from the type of multitasking that Apple is implementing.

 

[Lotus Esprit V8]

So essentially instead of pre-emptive multitasking which is what MAC OSX does they opted for co-operative multitasking which is what OS's prior to OS X did.

Very interesting.

 

[Alkiera]

Yeah, other than apps that line up with one of the background methods, the thing most apps will benefit from is the quick-suspend/resume feature, which I'd guess is would be pretty easy to update an app for.

The real work would be for audio apps, skype/VOIP apps, and anything that uses push notifications, but I'd guess the APIs are written to make the additional work not too onerous.

And while there are 150k apps, it's not like any one developer is going to be updating all of them; most developers only have a few apps.

 

[HXGuy]

Yes but what if there is an app you got say a year ago that you love...but that developer is no longer in the businesses of doing apps and never updates it?

I guess Im seeing it from the point of view of the iPhone -> iPad apps. A bunch have been updated...but the majority have not and while I know that the iPad has only been out less then 1 month, that's exactly the point...that OS4 will be released in the fall but will it be until spring that all the apps do multitasking? Just wish there was a way that all apps would work without the developer having to make changes and resubmit to Apple for approval.

 

[VTMac]

Yeah, other than apps that line up with one of the background methods, the thing most apps will benefit from is the quick-suspend/resume feature, which I'd guess is would be pretty easy to update an app for.

No code changes are required for suspend / resume.

 

[HXGuy]

No code changes are required for suspend / resume.

Oh yea? Well at least that's good.

 

[VTMac]

So essentially instead of pre-emptive multitasking which is what MAC OSX does they opted for co-operative multitasking which is what OS's prior to OS X did.

Cooperative multitasking is NOT a good description of what is happening in OS 4. Cooperative multitasking implies the application has to yield control. This is not the case at all with OS 4. Any process can be preempted at any time. This has been true of every release of iPhone OS kernel that has been released.

OS 4, provides some API sanctioned methods of accessing this behavior. Mainly the APIs are designed to force the developer into a design pattern that is optimized for a particular use - such as:
1) Making sure any given app can't go into run away mode indefinitely and burn up battery. This is the thinking behind the 10 minute background API.
2) Ensuring that the radio is used as efficiently as possible so as not to eat battery. This is the thinking behind the VOIP apis.
etc.

Apples approach is very well thought out FOR THE END USER. It will not address all cases for which developer might want to use multitasking, but Apple approach is going to enforce a minimum quality level across the realm of multitasking. And as other common scenarios are unearthed which are not currently accounted for in the OS 4 APIs, I'm sure they will extend to meet them.

 

[jtara]

So essentially instead of pre-emptive multitasking which is what MAC OSX does they opted for co-operative multitasking which is what OS's prior to OS X did.

No, that's incorrect. It is pre-emptive multitasking, the same as all versions of iPhone OS since 1.0 have implemented. The Apple-supplied apps run in background using pre-emptive multi-tasking, as do many third-party "jailbreak" apps.

Apple is simply now allowing some third-party apps to run in background. They are restricting the class of apps that are allowed to do this, and providing some higher-level APIs that make this somewhat easier for these classes of apps, and dictating that these APIs be used as the mechanism for backgrounding apps.

BTW, third-party apps have always been able to multi-task (multi-thread, technically) internally. That so few do, and as a result have nonresponsive UIs when they are "busy" doing something is just a testiment to the the overall poor quality of iPhone apps. Most app authors don't bother.

There aren't 150,000 apps that NEED to run in background, and the authors of all those apps are unlikely to bother. THIS IS A GOOD THING. It's setting the bar higher, and many apps will fall out of the store. I believe that along with background processing will come higher standards in the app store acceptance process. Apps that do run in background are going to have to meet a higher standard, e.g. they cannot be allowed to hog the CPU.

 

[PhoneI]

I would imagine that even if an app isn't updated to take advantage of the new background APIs, it would still be taking advantage of the fast switching features, which would bring you back to the same point in the app where you were before you left.

 

[blackNBUK]

So essentially instead of pre-emptive multitasking which is what MAC OSX does they opted for co-operative multitasking which is what OS's prior to OS X did.

Very interesting.

Were are you getting that from?

The iPhone kernel is perfectly capable of pre-emptive multitasking as it's based on the same kernel as OSX; I don't see anything to suggest that this will change. The changes to Apps are to get them to work well with the multi-tasking framework that Apple have devised (e.g. low memory notifications and state serialisation) The kernel will still have complete control of which process gets access to the CPU and for now long.