4 ms·

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 launc

by 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.

4 ms·

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 launc

by tewks 17y ago

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.