Slashdot Mirror
Multitasking In For iPhone 4.0?
The latest word on the iPhone is that the 4.0 OS will finally have
honest-to-goodness multitasking. This could hopefully lead to things like a real chat client, and dangerous battery consumption. I still hope it's true.
The iPhone OS has always had real pre-emptive multitasking. The phone, email, iPod, calendar, and other applications run all the time and can do things simultaneously.
Multitasking just hasn't ever been made available to 3rd party developers.
It has never been a technical limitation in the OS. Rather, Apple kept control over it for battery life and security reasons.
First against the wall when the revolution comes
There are real uses for multitasking, which the iPhone already does - like listening to iPod while surfing or the like. Maybe chat as mentioned, but I also hope to set which apps can be multitasking - I don't trust the developers always to make the correct call - there is no reason to leave a game running in the background while I surf, it would be better to save state. I would actually say saving state and resuming again is better the vast majority of times over running in the background.
But oftentimes I try to hang up the phone by hitting the home button instead of the end call button (even though I think I did), and while surfing, I still see that "Return to Call" blinking on top.
To conserve battery life, I already turned off push notifications and other things. And I would turn off multitasking for my parents phones, they hardly can use a computer as it. With this, they'll only be wondering why the phone battery is dying even faster.
This is why Apple should sue the shit out of Google, because once iPhone OS 4 is available, Google will inevitably steal every single idea from it.
This is why I jailbroke the thing in the first place (well, that, and a few other things): multitasking for everything, not just Apple's apps. For some time now, I have been able to listen to music and browse the web, text, chat, etc. by just switching apps. It works fairly decently, too, and doesn't make it very slow. I am simply amazed they decided this was a proper limitation.
SSC
Obviously, they do want it. And I was in the "geez, why doesn't Apple enable true multi-tasking?" crowd along with most other people. However, after playing with my new iPod touch (thanks sis - she knows I'm too cheap to buy this stuff myself) and comparing it to my Android, I think Apple is smart.
The Apple UI is so smooth compared to Android's, there really is no comparison. I HATE lag when I'm dealing with a UI, and Android's multi-tasking Java based applications take a good 1-3 seconds to do anything I tell them to do. If there's any chance Apple would have impacted their UI performance to enable multi-tasking, I think they made a great move.
I still wouldn't switch from an Android to an iPhone because of the restrictions (and I'm not going to wager hundreds of dollars on a jailbreak), but now I see why people enjoy Apple products.
For most users multi-tasking is a secondary concern to a nice UI.
If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011
In the old days, we had background processes that always had to run. Now we have signals and the like that can awake idle processes so they do not have to run. Then we had TSR applications, and similar items on the Mac, like the Talking Moose. The former was created to solve the long start up time of applications on DOS and Windows. Multiple windows and such were useful on the PC, with larger screens, but somewhat harder to use on the Mac. The Mac seemed to launch applications faster, so I don't have a recollections of being annoyed that Finder was not multitasking.
Multitasking is a solution to solve some problem on the general computer. I am not sure it is the right solution for a small screen mobile small battery device. I would rather see innovative solutions rather than rehashing the same old thing. I think there this might be a useful solution for the iPad. My concern is that iPhone 4.0 is built for the next iPhone, and will make current iPhones harder to use. This is what happened with iPhone 3.0, which does not run very well on the first generation iPhone.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
I've had my Nokia N900 for a couple of months now, and for those unaware, most of the specs are identical to the iPhone 3Gs 32Gb. Well, except that it has a much higher resolution screen, a keyboard, a real GPS, an FM transmitter and a microUSB port for data and charging. But the CPU/GPU and amount of storage are the same, except that you can also add a microSD card to the N900. But now on to the most important difference to the 3Gs. I've used both my N900 and a 3Gs, and the 3Gs just feels sluggish, while having half the functionality.
Flipping home screens on the N900, regardless of how many icons and widgets it's running is smooth, with no clipping. Even with half a dozen apps running in the background, the UI remains equally fast (several instances of the Firefox, Application Manager, Communication app, Contacts app, Skype, MediaBox, battery-eye, conky, etc). Flipping through the 3Gs icon screens clips and feels choppier. It's not a large difference, but keep in mind the hardware is identical and the iPhone has NO applications running in the background.
The N900 also starts up applications faster, in most cases instantaneously. Start up times do increase progressively after about 3-4 large apps are already loaded and actually doing stuff in the background (Firefox loading up pages, Application Manager checking for updates, MediaBox playing music). But many utilities that only refresh while in the foreground do not have any impact at all (Conky, battery-eye, disk usage, etc). In contrast, the 3Gs takes a couple of seconds to load up pretty much every app I tried, regardless of how limited its functionality is, and complex apps take even longer.
Once the apps are running, they are roughly equally fast on both the N900 and the 3Gs. But as I stated above, the N900 may be running several apps in the background, and the foreground apps do not slow down at all.
I think this is why Apple did not allow multitasking up to now. Given how slowly single apps load on their flagship 3Gs, true multitasking will bring it down to its knees. The iPhone OS takes much more resources to run than Maemo or Android, and the iPhone single tasking is a way of masking it. Of course this is speculation since except for the basic Apple apps, nobody managed run more than one app at the same time on the iPhone. And I'm sure those Apple apps are optimized and tweaked to hook into the OS and stay loaded at all times. Most likely the 4G will have a faster processor and more RAM, and will compensate for the OS shortcomings through brute force.
Well if multi tasking is implemented as a series of call backs so that any process that is waiting on data is not consuming clock cycles
iPhone OS is a UN*X; multi-tasking is ultimately implemented as "calls that wait for something to happen end up making a system call and the process blocks".
then there should be no more drain when "multitasking" then when running one application.
...unless, for example, an app is continuously updating the display, showing an animated ad, or displaying a game screen, or.... Perhaps the app would be told "you're going into the background, stop updating the screen (but don't necessarily stop playing audio)".
s far as I can tell using the backgrounder on my jail broken iphone when not actively working most programs still consume cycles.
What indicates that they're consuming cycles, rather than just blocked in a system call?
So almost all of this could be fixed if the wait() call is not properly implemented in the lib.
As per another comment of mine, iPhone OS being a UN*X, wait() is the call you use if you've started a subprocess (fork()/vfork(), posix_spawn()) and you wait to wait for it to exit. There is no single call that is the call to wait for something to happen - there are a whole bunch of blocking system calls such as read(), recv(), recvmsg(), connect(), etc., as well as the usual wait-for-events calls such as select(), poll(), and kevent(), plus the Mach messaging calls. Most apps probably use higher-level APIs that are built atop them.
The latest N900 firmware resolved a LOT of issues. Not sure what firmware the review phone is using, but looking at his theme, it's an older one. My N900 with firmware 3.2010.02-8.002 released about a month ago loads up ALL apps faster than in the review. Same goes for the touchscreen lag. The next firmware, due to be released in a couple of weeks will improve things even further.
But that's not all. :) The N900 also gets faster as you use it. After a cold boot the RAM has 100Mb used, but after loading all sorts of apps it goes up to 153Mb and stays there. Those extra 50Mb contain cashing data for all your apps. I just tried every app I could think of: Communications (SMS and IM), Firefox, Contacts, Phone, Media Player (not MediaBox), Disk Usage, battery-eye, Settings, Application Manager, File Manager, Xterm, PDF Reader, Email. Every single one loaded up instantly, in less than 1 sec.
The only offender is MediaBox, because it insists on scanning your entire device for music, movies, etc. BTW, the N900 can play regular AVI movies without dropping frames or losing sound sync, AND it can output to any TV. I watched 9 (the entire animation movie) full screen on my HD TV the other day. :))
And I NEVER need to reboot my N900, it's rock solid. Even if the first time you start the apps it takes as long as on the iPhone, after 10 mins of use it's much faster.
Well olddotter, the N900 has to perform all the phone related tasks you've listed as well. So your point doesn't apply.
As a dedicated Android user (and programmer), I still don't see the value of multitasking in a mobile app. The runtime can automatically clean up and restart the application with all the state information necessary if it ceases to run anyway. It's a lot easier to just assume that it's _always_ going to be cleaned up upon suspension, instead of writing code that accounts for the possibility that the app just may be resuming from a paused, but not terminated state. I haven't used a single Android app, or written any code that I can say honestly benefits from the multitasking aspects of Android. The runtime can shut down my app any time it sees fit. Planning for resumption from an abruptly terminated app is the norm when developing for Android anyway. The way I see it, the apps would have more resources if the platform didn't have to multitask.