> If one of the top apps in your app store is a “app killer” application, then I think you have a problem.
(Quote from OP)
Yes, there is a problem. However in this case it is one of communication and understanding, as there is absolutely no need for a task killer on Android at all. I uninstalled the task killer I was using and haven't looked back, it's never a problem at all.
For those who don't know Android's internals that well, when you "tab" away from an application, it is sometimes terminated there and then. Whenever a pane is opened (can't remember the correct terminology) it is given a context object representing its state last time it was viewed. When a pane is closed (i.e. you go to another application), the O/S asks for a context object for it so it can be restored later. It will then be kept asleep in the background, but if the resources it is using are needed by another app, then it will be terminated without warning. That context item is the be-all and end-all, apps cannot rely on being notified by the O/S when they are terminated - only when they are hidden. It's a neat system IMO, optimising for responsiveness when resources are plentiful, and for resource usage when they are not.
Thanks for the clarification. As I commented on the post, years of "training" has taught me (us?) to manage memory manually. The question is, how does Google/Android go about retraining users, or does it not matter?
> If one of the top apps in your app store is a “app killer” application, then I think you have a problem.
(Quote from OP)
Yes, there is a problem. However in this case it is one of communication and understanding, as there is absolutely no need for a task killer on Android at all. I uninstalled the task killer I was using and haven't looked back, it's never a problem at all.
For those who don't know Android's internals that well, when you "tab" away from an application, it is sometimes terminated there and then. Whenever a pane is opened (can't remember the correct terminology) it is given a context object representing its state last time it was viewed. When a pane is closed (i.e. you go to another application), the O/S asks for a context object for it so it can be restored later. It will then be kept asleep in the background, but if the resources it is using are needed by another app, then it will be terminated without warning. That context item is the be-all and end-all, apps cannot rely on being notified by the O/S when they are terminated - only when they are hidden. It's a neat system IMO, optimising for responsiveness when resources are plentiful, and for resource usage when they are not.