4 ms·

Sometimes I feel the whole world misses the point about multitasking on mobile devices. Here's what I think: * Existing iPhones offer an infrastructure to quic

Sometimes I feel the whole world misses the point about multitasking on mobile devices. Here's what I think: * Existing iPhones offer an infrastructure to quickly save and restore the state of your application so that it can be "hibernated", therefore reducing the need for real multitasking. * Obviously, due to the limited display size of mobile devices, you can't have two apps running on the same screen at the same time, it just doesn't make sense, so an "inactive" app is off the screen, hence most of the time it doesn't matter if is actually running or hibernated. Just like on the iPhone. * Sometimes, you still want your app running even when it's off-screen. Things like music players (Spotify for instance), mail tools (gmail fetching email in the background) or social tools (a twitter client fetching the latest tweets that you can read later even if you don't have signal). * Notice that generally, for things that you want to run in the background, you don't need an active UI. There's no need for UI for an audio player in the background, a mail reader syncing in the background, etc. * Solution: disallowing code that is eligible for running in the background to have access to the screen. This will make he background tasks a lot leaner as it would force developers to separate "service-like" code from "application code" and enforcing strict memory/CPU limits on "background services".

vetinari 17y ago
And this is exactly how Android does it - you can spawn thread that will run in background, but it will be a "service" - UI-less part of your application. In addition, there are events notifying application that it is going to be "hybernated"; basically it tells it to save whatever information it needs to restore into current state.
- DrJokepu 17y ago
  While I'm no expert at Android architecture I own an Android phone and I think there are there are two ways an app can run in the background on Android: first, there are the "background services" (or whatever they are called) but my understanding is that there are also six slots of apps that aren't "hybernated" they're just not "focused" - they might not consume any CPU cycles but they're still in the memory. I would axe this second type of background tasks. Correct me if I'm wrong though, I always wondered how it works exactly.
  - vetinari 17y ago
    Actually, there is only one way the application can run in background: the "service". The "background slots" are implementation details. Applications do not receive the event "you are going to be killed, please serialize" the same moment they lose focus; they receive it at the system's discretion. The system decides based on memory available (mostly), whether it will leave some processes running or whether they will be "backgrounded" (basically, what is more economical - backgrounding processes all the time, when the user is switching between two apps, or just keep them both in memory?). To some extent, this is tunable by the power users - if they download "Dev Tools", they can set the limit to 1 - 4 processes (or unlimited). It is basically trade off between memory consumption and responsiveness. I repeat - this is not supposed to be setting for common users; it is just exposed for developers to experiment, what happens when they push the decision threshold in one direction or another. The system is supposed to have good default out of the box and manage the processes automatically (which is also reason, why there is no task manager).

vetinari 17y ago

And this is exactly how Android does it - you can spawn thread that will run in background, but it will be a "service" - UI-less part of your application. In addition, there are events notifying application that it is going to be "hybernated"; basically it tells it to save whatever information it needs to restore into current state.

DrJokepu 17y ago
While I'm no expert at Android architecture I own an Android phone and I think there are there are two ways an app can run in the background on Android: first, there are the "background services" (or whatever they are called) but my understanding is that there are also six slots of apps that aren't "hybernated" they're just not "focused" - they might not consume any CPU cycles but they're still in the memory. I would axe this second type of background tasks. Correct me if I'm wrong though, I always wondered how it works exactly.
- vetinari 17y ago
  Actually, there is only one way the application can run in background: the "service". The "background slots" are implementation details. Applications do not receive the event "you are going to be killed, please serialize" the same moment they lose focus; they receive it at the system's discretion. The system decides based on memory available (mostly), whether it will leave some processes running or whether they will be "backgrounded" (basically, what is more economical - backgrounding processes all the time, when the user is switching between two apps, or just keep them both in memory?). To some extent, this is tunable by the power users - if they download "Dev Tools", they can set the limit to 1 - 4 processes (or unlimited). It is basically trade off between memory consumption and responsiveness. I repeat - this is not supposed to be setting for common users; it is just exposed for developers to experiment, what happens when they push the decision threshold in one direction or another. The system is supposed to have good default out of the box and manage the processes automatically (which is also reason, why there is no task manager).