3 ms·

I think this would be much less of a 'big deal' if you could 'suspend' more apps. Getting a txt during a game leaving the game to reply to it and then coming ba

by edd 17y ago

I think this would be much less of a 'big deal' if you could 'suspend' more apps. Getting a txt during a game leaving the game to reply to it and then coming back and not being able to pick up where you left of does suck. If it could effectively sleep the app and pick it up again properly this would essentially remove any need for background apps for me. I do know Tweetie 2 has implemented this and it rocks.

jasongullickson 17y ago
Agreed. As you mentioned some apps do this, the necessary tools are there (apps are notified when they are about to be closed and allowed to save data, suspend state, etc.) to allow apps to suspend gracefully however it's up to the developer to use them and that is pretty hit-or-miss.
tewks 17y ago
The developer of whichever game you are referring to hasn't written the application properly: it should offer to resume state when the application is next launched. The Apple model, one app at a time, makes a lot of sense, particularly in this use case: on a device with a four inch screen, there's no need to have a game, or most other applications, running in the background!
- tshtf 17y ago
  I would have to disagree. Consider this case: 1) I am on IRC on my mobile device and my coworker says there's a problem with something on server-x 2) With IRC in the background I open an SSH client to login to server-x and check on the issue. Seeing a service is down I switch back to IRC. 3) I tell my coworker on IRC the service appears to be down down. 4) I bring up a browser window to verify that the web server on server-x is not responding. ... etc This type of workflow will not work on single tasking mobile devices, and it's not an unreasonable use case at all.
  - tewks 17y ago
    That type of workflow will not work on today's multitasking devices for very long; the battery will die pretty quickly. I can testify to this having done it on the G1. For the meantime (next year or two), until batteries get better and hardware more efficient, push notifications are a pretty good way to solve this. Why does the handset need to keep these connections open when a remote server can do this more efficiently, not draining the battery, and then push a notification when an event happens? There is a fundamental limit to the amount of information that can be conveyed on a 4" screen. Everything else "running" in the background, in a single tasking environment, can be taken care of by well written apps and services. More of a pain for the developer, yes, but a godsend for one's battery and CPU time.
eelco 17y ago
It's indeed mostly a burden on the iPhone devs side to support good 'suspension' behavior, and there are some frameworks (like Three20) which more or less offer it 'out of the box'. I used an Android phone for a while before switching to the iPhone and in most of the cases where I missed running multiple apps only _one_ background app would be enough (e.g., Last.fm and other music (streaming) apps, a GPS tracker, some games).

by edd 17y ago

jasongullickson 17y ago

Agreed. As you mentioned some apps do this, the necessary tools are there (apps are notified when they are about to be closed and allowed to save data, suspend state, etc.) to allow apps to suspend gracefully however it's up to the developer to use them and that is pretty hit-or-miss.

tewks 17y ago

The developer of whichever game you are referring to hasn't written the application properly: it should offer to resume state when the application is next launched. The Apple model, one app at a time, makes a lot of sense, particularly in this use case: on a device with a four inch screen, there's no need to have a game, or most other applications, running in the background!

tshtf 17y ago
I would have to disagree. Consider this case: 1) I am on IRC on my mobile device and my coworker says there's a problem with something on server-x 2) With IRC in the background I open an SSH client to login to server-x and check on the issue. Seeing a service is down I switch back to IRC. 3) I tell my coworker on IRC the service appears to be down down. 4) I bring up a browser window to verify that the web server on server-x is not responding. ... etc This type of workflow will not work on single tasking mobile devices, and it's not an unreasonable use case at all.
- tewks 17y ago
  That type of workflow will not work on today's multitasking devices for very long; the battery will die pretty quickly. I can testify to this having done it on the G1. For the meantime (next year or two), until batteries get better and hardware more efficient, push notifications are a pretty good way to solve this. Why does the handset need to keep these connections open when a remote server can do this more efficiently, not draining the battery, and then push a notification when an event happens? There is a fundamental limit to the amount of information that can be conveyed on a 4" screen. Everything else "running" in the background, in a single tasking environment, can be taken care of by well written apps and services. More of a pain for the developer, yes, but a godsend for one's battery and CPU time.

eelco 17y ago

It's indeed mostly a burden on the iPhone devs side to support good 'suspension' behavior, and there are some frameworks (like Three20) which more or less offer it 'out of the box'. I used an Android phone for a while before switching to the iPhone and in most of the cases where I missed running multiple apps only _one_ background app would be enough (e.g., Last.fm and other music (streaming) apps, a GPS tracker, some games).