Hacker News new | past | comments | ask | show | jobs | submit login

What's wrong with their current multitasking solution?



"What's wrong with their current multitasking solution?"

If everyone codes their apps perfectly, nothing.

On the other hand, if there just happen to be one or two cough apps out there that are coded according to the pre-multitasking way of doing things there are three main problems:

(1) it will consume more battery, because the apps will pound away in their inner loops blissfully unaware (because they're not listening, or didn't handle it correctly).

(2) it removes control from the user, since a mostly crashed app will remain mostly crashed. Under the old scheme you could exit out and then go straight back in, in order to start with a 'clean slate' (sic).

(3) it uses more memory, on devices that are painfully low on memory. Half a gig (actually less for overhead) was okay-ish when you were the only thing running... but when it is being shared it doesn't go very far at all.

(4) off by one errors


1) no battery will be consumed by "runaway loops" because it will either be closed or be completely frozen in the background, regardless of the app design and epoch (pre- or post-multitasking)

To perform computations in the background, an iOS app has to be voluntarily coded to do so by using the multitasking API.

(3) half a gig on the iP4 is plenty enough to hold numerous Safari tabs, a huge game like Infinity Blade or Dead Space, and half a dozen random apps (twitter, messages, mail...).


I can confirm that (1) is in fact wrong. I have apps that when I run them and then 'exit' the battery gets chewed noticeably faster.

Half a dozen apps is not very many apps. In fact, it is a ridiculously small number of apps for a device that is "all about the apps".


Which ones? I'm curious, it would be interesting to know about them so as to avoid such buggy bastards who dare to resist to SIGSTOP (or its equivalent).

The task switcher is not a task bar, it's a MRU list. You're better off finding them again on Springboard if they're not in the half-dozen most recent apps range, which is muscle-memory. What do you expect? you can only fit so much on a ~3" screen and make items touchable. Stuffing more icons would make the task switcher end up looking like Springboard anyway, only messy because you'd have to scan through it due to the number of items. Springboard + muscle-memory beats that anytime.


2) you can manually close apps. Long-press on them in the multitask bar and click the "x" to close. Next time you go in you will get a clean slate.

3) iOS will shut down LRU'd apps as it runs out of memory. This is a non-issue.

Most of the issues for me around multitasking center around the UI.


(2) You shouldn't have to manage them manually. Also, but orthogonal to that is that the multitask bar blows from a user experience point of view. (Just by way of example, if you do decide that the user should manage memory manually, you should at the very least provide some kind of indication about how much memory/threads/resources each app is currently using, otherwise the user is just shooting blanks in the dark (sic)). You didn't previously (need to do this) under single tasking. For most apps therefore single tasking provided a superior user experience.

The obvious exception is apps that do some kind of notification, e.g. if you wanted to write your own SMS or twitter style client. Given the vast numbers of apps coded for the single tasking paradigm, it would have been better to create some kind of 'opt-in' notification API (a good one, not whatever they had previously).

(3) to an experienced eye the performance degrades as it reaches those limits and starts having to do app level garbage collection. Also, this means that apps need to pay more attention to their own memory management and the low-memory messages they are receiving from the OS. In a perfect world this would have already happened. Given the ... how shall I put it ... journeyman level of experience of most iOS developers this is an utterly unrealistic expectation. This is a big issue.


Technically I prefer Apple's approach. Android devices will always, sooner or later, reach a point that you have to manually kill off some apps.

But the app switch interface in iOS is less than desirable, it'll quickly clutter up even if you do not feel the lag, you'd wanna X everything off just so you don't have to scroll to the left 6 times to reach the app you intended for.


The app switch list is designed as a convenient way to switch to the most-recently-used apps. If you have to scroll 6 times to find an app, then you're not switching to a MRU app, but a LRU app instead. In that case, finding the app icon in springboard will likely be faster. Clearing the list is a symptom of misusing the feature.


I'm always surprised when people do this - I don't see people compulsively clearing out their Recent Items. I wonder if the only people who do this are people who are used to closing apps on a computer to conserve resources.


Speak for yourself re Android - I never have to kill off apps in my Nexus One running 2.3.


I don't kill anything either.

What I meant by my original comment is that for me it doesn't work as I'd like. It may be an issue with the apps I use or iOS's way of doing multi-tasking.

I listen to 5by5 podcasts (atomic web browser) and follow the discussions on irc (Colloquy for iPad).

I someone posts a link on the irc and I follow it when I come back to colloquy I don't get any of the messages sent while I wasn't looking...

When I use the AndChat in my Nexus One I can happily go watch a lolcat and when I get back I can read all of the I can haz messages everyone sent while I was looking at the site.

That use case is the one I consider broken in iOS, maybe Apple doesn't care about people who still use irc or maybe it's Colloquy that's broken.


You could do something ala n900.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: