6 ms·

No, most of the time its a story about how lack of multitasking is GOOD and how the other platforms are bad for offering it, how users are too stupid to use it

No, most of the time its a story about how lack of multitasking is GOOD and how the other platforms are bad for offering it, how users are too stupid to use it etc. To be perfectly honest, I can only think of two use cases for (third-party application) multitasking on a device like the iPhone: 1. App 1 in background streams/plays music while I use App 2 to do something else. 2. IM client in background popping up messages as they come in. On a device with the form factor and use cases of a typical "smart" phone I just can't think of any other reasonable case where I'd even want, let alone need, multitasking. So count me among the group who'll be happy if something shows up which actually makes multitasking on a device like the iPhone useful, but who don't particularly miss it at the moment because there just isn't that much it'd be good for.

elai 17y ago
Passive GPS tracking apps - Like locale for android which changes your profile settings to put your phone on silent when your at school. Speakerphone only while travelling fast, forward to your home phone while at home, etc.
- DannoHung 17y ago
  Man, that's cool, but it'd drive me crazy.
  - theBobMcCormick 17y ago
    Why would it drive you crazy? From what I understand (I've never used it), the Locale app is customizable. You specify what setting you want changed and under what circumstances. I actually use similar but more limited free application on my N1 called "Timeriffic". I have it set to turn off notifications (text messages, new emails, etc) automatically at night and turn them on the next morning. I leave the ringer on though for phone calls, because generally if someone calls me on my cell after 11pm it's probably important. :-)
    - tpz 17y ago
      For what it's worth, I have had my Android phone for ~17 months and to this date Locale is _still_ its killer app. I simply refuse to own any other phone until it can do the same. I will certainly understand if iPhone/iPad multitasking arrives with some fairly severe limitations placed on the developers of background apps. Right now there's zero ability in that area so anything, even if severely limited, will still be an infinite improvement (depending on how you like to imagine your divide by zero operations playing out. ;)
    - glhaynes 17y ago
      It sure sounds nice in theory, but I'm paranoid enough about such things working that I'd end up manually turning off my ringer anyway. At least for a long time until I felt really comfortable with it... it is super sucky to be "that guy" at a wedding/funeral...
      - thwarted 17y ago
        Do you really go to enough weddings or funerals in the same location that you'd be able to use something that keyed off GPS to change the ringer settings? I seriously hope you'd explicitly turn off the ringer in those cases.
        glhaynes 17y ago
        :) Good point, but I was really just using those as hyperbole. A better example is that it can't know when I'm in a meeting or not (conference rooms in my building are interspersed with offices), so I've still gotta manually silence it during meetings... that's the most common use case for silencing for me (some aren't in this same situation, but many are), and location-based auto-silencing is useless for that. So now the user has two things to keep in mind as far as silencing: which times it is programmed to do so automatically (all of which the user must be a bit suspicious of already - as you said, to be extra-sure the user would want to manually override even at those locations during times that it's really important for the ringer to be off) and which times they still have to manually override it. So we've got extra mental burden and anxiety for the user, partially or wholly overriding the savings of not having to worry about silencing in some circumstances. We're only trusting the system for those times where we'd really like it to work but it doesn't have to be guaranteed, so there's some lurking uneasiness during those times. And the user has to program it. And I'd think it's very likely to be a significant battery drain since it's needing to turn on the GPS quite often to be useful. Etc etc. Anyway, it's a super-cool sounding feature when just considered as a bullet-point, but it just strikes me as a "techno cool" feature (kind of like speech recognition and "Minority Report" interfaces) that I doubt I'll ever see widely used. I'm sure there are a few specific circumstances where it's really handy and I'm happy for those who enjoy it, but I have nearly no interest in it compared to a trusty manual switch and I think I'm speaking for the vast majority of users there. Could certainly be wrong.
ezy 17y ago
Well, given that the iPad runs the iPhone OS, I think you can generalize this to one case. Any app that needs to maintain a persistant network connection. That covers IM, streaming...and remote login (ssh, vnc, rdp, etc...)
- ryanpetrich 17y ago
  I'm not convinced that remote login requires this. RDP and VNC can keep a session available when disconnected, and screen is available over SSH.
ra88it 17y ago
3. Give me an alert notification based on my GPS coordinates (ie., remind me to install updates on my parents' computer next time I'm at their house)
stanleydrew 17y ago
No offense, but the fact that you can only think of two use cases for 3rd party app multitasking isn't really a very compelling reason not to include it in a smartphone os. It's the awesome use-cases that nobody has thought of yet that are being stifled by this limitation.
- ubernostrum 17y ago
  Those are the two I'd personally care about, and so are the two I come up with. However, one of them accounts for something like 90% of all the use cases I've ever seen proposed, in any forum, anywhere, for third-party multitasking on the iPhone, and really just boils down to one word: "Pandora". I've said elsewhere and will say again that Apple could probably placate a huge number of people simply by giving Pandora and no other third-party application an exception to the multitasking policy. But in a larger sense I'm extremely skeptical of the claim that there are many "awesome use-cases that nobody has thought of yet", simply because of the two fundamental problems: form factor and resources. First, the form factor problem: a mobile phone's screen can only be so large before the device stops fitting in a pocket, which means you get a certain amount of total UI real-estate, and that's it. Unfortunately, it's a pretty tiny slice of real-estate, which means that the traditional multitasking interfaces -- multiple windows, or multiple panes within a larger container -- don't work. You just don't have room on that screen for four or five applications and clear delineations between their screen areas to all be displayed simultaneously; you really don't even have room for two, because even if you cram all your stuff into that space you're still going to run right into Fitts' Law and have something that's unusable. This means you get only one realistic UI option, which is that every application runs "full-screen". This may not mean using 100% of the screen area, but the size problem means you need to use so much space that there really isn't room for much else to fit alongside it. As a result, all the cool kids in the mobile OS field (iPhone OS, Android and WebOS) are doing the "fullscreen app" paradigm. And then there's the resource problem, which has been discussed endlessly but not in particularly constructive ways. Every application that's running needs to have code and data resident, and a huge number of them want a network connection too. This means every additional application eats up more memory (a scarce resource on a phone-sized device) and power from running one of the device's radios (ditto -- and note that even if the app someone's interacting with at the moment doesn't need a network connection, odds are that some other running app does, so you don't even get a break when the user's not directly interacting with a network-using app). This is a resource-management problem, and whatever solution is used for it will inevitably cascade back up into the UI. WebOS uses a card metaphor to cycle between applications, but launch a bunch of applications and the UI goes from responsive to... well, not responsive. Which suggests that, nice as the metaphor might be, it doesn't really work. The other option, which is the one pretty much everybody else is going with these days, is to have a monitoring process serialize the state of and then terminate one or more applications when resources start running low. This also has the advantage of fitting nicely with the already-necessary fullscreen-app UI because from a UI perspective there's no interaction difference between "Leave App A running, but move App B to the front" and "Save App A's state, terminate it and launch App B". If you don't believe this, note that it's exactly what Android does when it runs low on resources; unless you're watching a process monitor you have no reliable way, as a user, to tell what it actually did when you hopped from App A to App B. This is also indistinguishable from what the iPhone already does; any decent application already saves state on normal termination, so the fact that the application isn't really running anymore is only noticeable if it was meant to keep doing something in the background (like play music or pop notifications in response to events). Which means that basic, built-in constraints of running on a mobile-phone-sized device, all by themselves, drastically limit the opportunities for meaningful multitasking. Because of the form-factor problem you can only ever have one application doing actual user interaction at a time, while all others have to sit in the background and do whatever they do without displaying interface (other than notifications) or requiring any serious interaction from the user (basically, you can pop "this thing happened" or "would you like to do X? Yes/No", and not a whole lot else because you don't have room for more UI without stealing full-screen focus, which is, again, indistinguishable from a serialize-and-terminate-and-launch). Which brings us back, basically, to "play music while some other app is being used", and "pop up notifications". That's not exactly a rich playground of possible use cases; music is, well, music, and notifications are basically only worthwhile to do when: 1. Event X happens (e.g., IM or SMS received). 2. Clock reaches Time X (alarm, reminder). 3. Device arrives at Location X. This offers the largest number of possibilities, but there are still only so many pseudo-geocaching games, walking tours and social-network things you can do without flooding the app market with a bunch of essentially-duplicate applications. So... yeah, there's really only the two use cases for multitasking: music, and notifications (which I tend to lump under "IM" since that's the one people would probably use the most). As a side note, what's best for enabling this is not actually full multitasking (in the "every app stays completely resident running all its stuff" sense), but something much more like daemons which periodically wake up and do things.

elai 17y ago

Passive GPS tracking apps - Like locale for android which changes your profile settings to put your phone on silent when your at school. Speakerphone only while travelling fast, forward to your home phone while at home, etc.

DannoHung 17y ago
Man, that's cool, but it'd drive me crazy.
- theBobMcCormick 17y ago
  Why would it drive you crazy? From what I understand (I've never used it), the Locale app is customizable. You specify what setting you want changed and under what circumstances. I actually use similar but more limited free application on my N1 called "Timeriffic". I have it set to turn off notifications (text messages, new emails, etc) automatically at night and turn them on the next morning. I leave the ringer on though for phone calls, because generally if someone calls me on my cell after 11pm it's probably important. :-)
  - tpz 17y ago
    For what it's worth, I have had my Android phone for ~17 months and to this date Locale is _still_ its killer app. I simply refuse to own any other phone until it can do the same. I will certainly understand if iPhone/iPad multitasking arrives with some fairly severe limitations placed on the developers of background apps. Right now there's zero ability in that area so anything, even if severely limited, will still be an infinite improvement (depending on how you like to imagine your divide by zero operations playing out. ;)
  - glhaynes 17y ago
    It sure sounds nice in theory, but I'm paranoid enough about such things working that I'd end up manually turning off my ringer anyway. At least for a long time until I felt really comfortable with it... it is super sucky to be "that guy" at a wedding/funeral...
    - thwarted 17y ago
      Do you really go to enough weddings or funerals in the same location that you'd be able to use something that keyed off GPS to change the ringer settings? I seriously hope you'd explicitly turn off the ringer in those cases.
      - glhaynes 17y ago
        :) Good point, but I was really just using those as hyperbole. A better example is that it can't know when I'm in a meeting or not (conference rooms in my building are interspersed with offices), so I've still gotta manually silence it during meetings... that's the most common use case for silencing for me (some aren't in this same situation, but many are), and location-based auto-silencing is useless for that. So now the user has two things to keep in mind as far as silencing: which times it is programmed to do so automatically (all of which the user must be a bit suspicious of already - as you said, to be extra-sure the user would want to manually override even at those locations during times that it's really important for the ringer to be off) and which times they still have to manually override it. So we've got extra mental burden and anxiety for the user, partially or wholly overriding the savings of not having to worry about silencing in some circumstances. We're only trusting the system for those times where we'd really like it to work but it doesn't have to be guaranteed, so there's some lurking uneasiness during those times. And the user has to program it. And I'd think it's very likely to be a significant battery drain since it's needing to turn on the GPS quite often to be useful. Etc etc. Anyway, it's a super-cool sounding feature when just considered as a bullet-point, but it just strikes me as a "techno cool" feature (kind of like speech recognition and "Minority Report" interfaces) that I doubt I'll ever see widely used. I'm sure there are a few specific circumstances where it's really handy and I'm happy for those who enjoy it, but I have nearly no interest in it compared to a trusty manual switch and I think I'm speaking for the vast majority of users there. Could certainly be wrong.

ezy 17y ago

Well, given that the iPad runs the iPhone OS, I think you can generalize this to one case. Any app that needs to maintain a persistant network connection. That covers IM, streaming...and remote login (ssh, vnc, rdp, etc...)

ryanpetrich 17y ago
I'm not convinced that remote login requires this. RDP and VNC can keep a session available when disconnected, and screen is available over SSH.

ra88it 17y ago

3. Give me an alert notification based on my GPS coordinates (ie., remind me to install updates on my parents' computer next time I'm at their house)

stanleydrew 17y ago

No offense, but the fact that you can only think of two use cases for 3rd party app multitasking isn't really a very compelling reason not to include it in a smartphone os. It's the awesome use-cases that nobody has thought of yet that are being stifled by this limitation.

ubernostrum 17y ago
Those are the two I'd personally care about, and so are the two I come up with. However, one of them accounts for something like 90% of all the use cases I've ever seen proposed, in any forum, anywhere, for third-party multitasking on the iPhone, and really just boils down to one word: "Pandora". I've said elsewhere and will say again that Apple could probably placate a huge number of people simply by giving Pandora and no other third-party application an exception to the multitasking policy. But in a larger sense I'm extremely skeptical of the claim that there are many "awesome use-cases that nobody has thought of yet", simply because of the two fundamental problems: form factor and resources. First, the form factor problem: a mobile phone's screen can only be so large before the device stops fitting in a pocket, which means you get a certain amount of total UI real-estate, and that's it. Unfortunately, it's a pretty tiny slice of real-estate, which means that the traditional multitasking interfaces -- multiple windows, or multiple panes within a larger container -- don't work. You just don't have room on that screen for four or five applications and clear delineations between their screen areas to all be displayed simultaneously; you really don't even have room for two, because even if you cram all your stuff into that space you're still going to run right into Fitts' Law and have something that's unusable. This means you get only one realistic UI option, which is that every application runs "full-screen". This may not mean using 100% of the screen area, but the size problem means you need to use so much space that there really isn't room for much else to fit alongside it. As a result, all the cool kids in the mobile OS field (iPhone OS, Android and WebOS) are doing the "fullscreen app" paradigm. And then there's the resource problem, which has been discussed endlessly but not in particularly constructive ways. Every application that's running needs to have code and data resident, and a huge number of them want a network connection too. This means every additional application eats up more memory (a scarce resource on a phone-sized device) and power from running one of the device's radios (ditto -- and note that even if the app someone's interacting with at the moment doesn't need a network connection, odds are that some other running app does, so you don't even get a break when the user's not directly interacting with a network-using app). This is a resource-management problem, and whatever solution is used for it will inevitably cascade back up into the UI. WebOS uses a card metaphor to cycle between applications, but launch a bunch of applications and the UI goes from responsive to... well, not responsive. Which suggests that, nice as the metaphor might be, it doesn't really work. The other option, which is the one pretty much everybody else is going with these days, is to have a monitoring process serialize the state of and then terminate one or more applications when resources start running low. This also has the advantage of fitting nicely with the already-necessary fullscreen-app UI because from a UI perspective there's no interaction difference between "Leave App A running, but move App B to the front" and "Save App A's state, terminate it and launch App B". If you don't believe this, note that it's exactly what Android does when it runs low on resources; unless you're watching a process monitor you have no reliable way, as a user, to tell what it actually did when you hopped from App A to App B. This is also indistinguishable from what the iPhone already does; any decent application already saves state on normal termination, so the fact that the application isn't really running anymore is only noticeable if it was meant to keep doing something in the background (like play music or pop notifications in response to events). Which means that basic, built-in constraints of running on a mobile-phone-sized device, all by themselves, drastically limit the opportunities for meaningful multitasking. Because of the form-factor problem you can only ever have one application doing actual user interaction at a time, while all others have to sit in the background and do whatever they do without displaying interface (other than notifications) or requiring any serious interaction from the user (basically, you can pop "this thing happened" or "would you like to do X? Yes/No", and not a whole lot else because you don't have room for more UI without stealing full-screen focus, which is, again, indistinguishable from a serialize-and-terminate-and-launch). Which brings us back, basically, to "play music while some other app is being used", and "pop up notifications". That's not exactly a rich playground of possible use cases; music is, well, music, and notifications are basically only worthwhile to do when: 1. Event X happens (e.g., IM or SMS received). 2. Clock reaches Time X (alarm, reminder). 3. Device arrives at Location X. This offers the largest number of possibilities, but there are still only so many pseudo-geocaching games, walking tours and social-network things you can do without flooding the app market with a bunch of essentially-duplicate applications. So... yeah, there's really only the two use cases for multitasking: music, and notifications (which I tend to lump under "IM" since that's the one people would probably use the most). As a side note, what's best for enabling this is not actually full multitasking (in the "every app stays completely resident running all its stuff" sense), but something much more like daemons which periodically wake up and do things.