4 ms·

Ahem... I'm gonna take the liberty of reposting my comment from another thread where this "review" cropped up. When you hit the home button, the previous appli

Ahem... I'm gonna take the liberty of reposting my comment from another thread where this "review" cropped up. When you hit the home button, the previous application keeps running, which means it keeps eating memory, keeps using processor cycles, and keeps eating battery.....To truly quit most applications requires a multi-step navigation that is neither intuitive nor well-documented. That one is one of the most pernicious bits of misinformation about the Android platform. Applications that are no longer visible to the user are NOT "background" applications like they are on a desktop OS. Applications that are no longer visible to the user are stopped. They no longer consume CPU resources, but the OS does hold them in memory in case the user returns to the app. Stopped applications may be killed by the OS, thereby freeing up the memory used by them, at any time by the OS when it determines it needs resources. Think of it like caching. The app state is cached in memory so that if you switch momentarily to another app (to answer a call for example) you can return immediately to the previous app with minimal delay and minimal resource cost (ie, the app doesn't need to be re-loaded, etc). The Android developer docs have more information: http://developer.android.com/guide/topics/fundamentals.html#.. http://developer.android.com/guide/topics/fundamentals.html#.... The only things that truly run in the background on Android are service process. These are somewhat like worker threads that are created specifically to handle long running background tasks (like playing music, or downloading data over the network, etc). There is absolutely no need to go through any "multistep navigation" to quit apps, nor do non-visible apps continue "using processor cycles and eating battery" (with the exception of course of apps that are supposed to be using processor cycles, ie, music players, etc. running in a background service process).

bmalicoat 17y ago
I have little Android experience so forgive me if this is obvious after using the device, but your description makes it sounds like you can't reliably know if an app will be in the state you left it, is that true? Meaning sometimes the OS will kill the app if necessary but other times it will not. If that is the case I'd prefer the iPhone way wherein the onus is on the developer to preserve the state and if they have, the app will always return to the way you left it or, if they haven't it will always be restarted from scratch. For me, knowing is better than not knowing. However, if it is the case that the OS rarely kills apps then the Android method seems preferable.
- theBobMcCormick 17y ago
  That would be highly unusable, but fortunately that's not the way Android works. Roughly what happens is that when an app (actually an Activity.. but we won't get into the difference right now) is no longer visible to the user, the OS automatically saves most of the apps state, and calls the apps onStop method to signal the app to save any app specific state. If the app is later killed, the next time it's started one of the items passed to the app by the OS is a reference to the previously saved state. The effect for the user is much like you describe it for the iPhone. It's as though your apps never die. Whenever you restart them, whether it's 5 minutes from now or 5 days, everything is exactly as you last left it. Except that, unlike on a PC, those "background apps" don't take up any resources. Obviously there is room for poorly written apps to flub up, or for apps to override the normal behavior for specific reasons.

bmalicoat 17y ago

I have little Android experience so forgive me if this is obvious after using the device, but your description makes it sounds like you can't reliably know if an app will be in the state you left it, is that true? Meaning sometimes the OS will kill the app if necessary but other times it will not. If that is the case I'd prefer the iPhone way wherein the onus is on the developer to preserve the state and if they have, the app will always return to the way you left it or, if they haven't it will always be restarted from scratch. For me, knowing is better than not knowing. However, if it is the case that the OS rarely kills apps then the Android method seems preferable.

theBobMcCormick 17y ago
That would be highly unusable, but fortunately that's not the way Android works. Roughly what happens is that when an app (actually an Activity.. but we won't get into the difference right now) is no longer visible to the user, the OS automatically saves most of the apps state, and calls the apps onStop method to signal the app to save any app specific state. If the app is later killed, the next time it's started one of the items passed to the app by the OS is a reference to the previously saved state. The effect for the user is much like you describe it for the iPhone. It's as though your apps never die. Whenever you restart them, whether it's 5 minutes from now or 5 days, everything is exactly as you last left it. Except that, unlike on a PC, those "background apps" don't take up any resources. Obviously there is room for poorly written apps to flub up, or for apps to override the normal behavior for specific reasons.