Hacker News Reader

Comment by drivebyacct | Hacker News Reader

Many people seem to think that OS 4 is going to bring this awesome multitasking. I think there's going to be a lot of disappointed people when they find out just how it works, seeing as the API for actually creating background services is crippled and the app switching is just a poorly implemented copy of Android pause/resume functionality.

View on HN

It seems tailored for specific use cases and the various scenarios it handles seem to me to have been addressed well. Is it the particular scenarios that you feel aren't sufficiently well handled or is it that there are scenarios that aren't handled at all? (I'm sure there are some scenarios that aren't handled at all, but I haven't thought of any that would be glaringly missing in the vast majority of people's usage.)

Also, I'm curious what about the app switching is more poorly implemented than Android's version of the same?

That apps are killed slows it down. On Android it takes just over half a second to switch applications.

For apps that start fast (notepad), this is no big deal. But for things like the browser or skype, it is. It takes 4 seconds for him to switch back to swype:

http://www.youtube.com/watch?v=ThkbDcZ_9-k#t=2m30s

This is also seen when switching to the browser near the end of Techcrunch's video: http://www.mobilecrunch.com/2010/04/08/first-video-of-iphone...

I've wondered why iOS kills the last app when it switches away... is it that iOS devices are more memory constrained? Is it that they don't want to disrupt the foreground app by collecting that memory when it's needed rather than immediately? Is it that they want app developers to be more careful about being able to reopen to the same spot they were, perhaps so that the experience of opening the app isn't different depending on whether the app got terminated while in the background or not (or even between device boots)?

OSX, like the Linux core of Android both support pre-emptive multitasking.

The problem to be solved is how to support background processing of 3rd-party Apps without draining the battery.

Thus we are trying combinations of call-backs and App hibernation techniques.

Battery life is more important to me and I suspect most other smartphone users.

What is your evidence for OS4's multitasking being Poorly Implemented?

I recall reading an article linked from HK a few months back written by an Android OS developer who seemed to think it was a fairly solid crack at the problem.

What would you do differently?

> I recall reading an article linked from HK a few months back written by an Android OS developer who seemed to think it was a fairly solid crack at the problem.

And if they missed a use case (always possible) but still decide against general-purpose background threads (à la android/webos) they can always add a service or two for what they missed.

> What would you do differently?

I'm guessing he'd just go with desktop-type multitasking, not considering the resources exhaustion issues inherent to a mobile platform.

Not really. I am not nearly ignorant enough to imply that any of the various aspects of desktop multitasking will be viable or well suited for a mobile platform any time in the future, nor would I want it to be.

The fact that Apple doesn't support proper background services outside of the very basic 3 things they let an app do in the background, only support for bg notifications through a timer or their own push notification server.

I mean, I understand the power assumptions that Apple is making and claiming as benefits, but it just seems limited. I think of several applications I use that would not be implementable on iOS, certainly not without many major modifications including some weird use of the iOS push note-server.

What sorts of apps can you think of that wouldn't be implementable on iOS?

Reply on news.ycombinator.com