Getting rid of quit/close requires the user to learn entirely new metaphors every time they use a program in order to know how to get a program to stop taking up resources. In a system with effectively limitless resources this is fine, but in lower specced systems, not so much.
Also "effectively limitless" means equivalent to the specs of the worst system the designers use, which will likely skew things. Where I'm sitting we share 384K down / 128K up between about 40 people. Updaters that refuse to stop downloading when you close them really bog down the network. Now, you could try and put in some custom menu to control that sort of thing, but that's going to be a mess of configuration and hard choices, and developers will have to do that for every single app.
Quit/Close are two well-defined commands that give the user a well defined way to say when they want something to go away vs. when they want something to go away and quit doing anything. Re-implementing "go away and quit working" on a case-by-case basis is going to end up with every app either having a nonstandard interface for doing so, or no way to do so at all (like most update managers.)
Personally, I think "some apps don't quit properly" is a description of a problem with the apps, not with the "quit" command. Comparing to mobile is a red herring, because you can in fact quit background services on most mobile platforms, and it's a necessary thing to do. It's only programs that by design, always gracefully suspend, full stop, and resume later that make sense to not have a quit command.
As someone who has used Matlab, and someone who has used Eclipse, you can take my "get your fat ass out of RAM already" command when you pry it from my cold, dead fingers.
Actually, on my Android phone I'm constantly using a third party task killer to stop services and apps running in the background that I thought I 'quit' by backing out of them. I also use the quit option on apps that have it.
I don't entirely trust Android to manage battery life as efficiently as possible yet, especially when iPhone still does it so much better, and when every time I check the services running on the phone, there seem to be tons I had never even started in the first place.
I consider that at least partly a UI/UX issue.
(On a side note, that's my only complaint about Android so far, using 2.3, otherwise it's great.)
Your task killer might be hurting your battery life rather than helping it. In any case, in recent versions (2.1+ I think), Android is better at managing tasks than a third-party app, and overzealous background task killing doesn't help anything.
I heard this as well so when I got my android I didn't install one. But the battery life was horrible. Often, if I used the phone regularly during the day the battery would be dead by 9-10pm. I installed a task killer and killed everything when it booted up and killed a couple times a day. After that I suddenly have ~1.5 days worth of battery available. I'm not sure which app was being such a hog (I suspect it's an app that was refusing to let the phone go into sleep mode) but the task killer was most definitely necessary.
You're killing a mosquito with a howitzer, and you may have better battery life by letting Android do what it's supposed to, and find the offending application.
Download "Spare Parts", go into its battery history section, and select "partial wake usage".
You'll find out what (if any) app is keeping your phone in partial wake lock status.
Thanks for that article, very informative, but not necessarily conclusive. There are also a ton of comments that resonate with my concerns, about how random apps I haven't touched seem to constantly start themselves and run in the background doing who knows what - using CPU (battery), bandwidth, whatever.
At least one comment mentioned a significant battery life improvement after installing Advanced Task Killer and turning on its autokill feature, which I've been using a few months. I think I'll experiment a little and turn it off, and see if there's any noticeable difference in battery life.
I agree with you. It was one of the hardest things for me to wrap me mind around. I'm constantly looking for the quit button on apps and I always have the urge to use a task killer to kill off tasks. I have seen a visible degrading of the user experience when I leave tasks running in the back ground. I also suspect app developers are not managing tasks correctly leading to inconsistent behavior.
... to its detriment, at times. I have a very good app on my iPhone that plots out bike paths around London for me. Sadly, when I have reached my destination, and "close" the window, it continues to use the GPS and other battery sucking things to the point where I have to manually go and kill it via the kill-menu (which is all I ever use the fast-switch menu for).
I'm not saying this is Apple's fault, but that it's very hard to work out when someone has "finished" with an app that could continue to, say, provide information about what the user is doing to a third party, or sucking battery life, or making annoying noises, for example. And apps that do this after I'm "finished" with them annoy me to no end. I'd consider that "broken" :)
Maybe it's confirmation bias, but I had to learn the metaphor of "no quit option", and I welcome the quit button/option on apps that have them. I have seen many, many users; particularly new Android users; that wonder where the quit button is, and what happens when they just "leave" the current application.
So, no, it may not have "broken" anything, but it has caused significantly wide, if not deep, cognitive dissonance.
Also "effectively limitless" means equivalent to the specs of the worst system the designers use, which will likely skew things. Where I'm sitting we share 384K down / 128K up between about 40 people. Updaters that refuse to stop downloading when you close them really bog down the network. Now, you could try and put in some custom menu to control that sort of thing, but that's going to be a mess of configuration and hard choices, and developers will have to do that for every single app.
Quit/Close are two well-defined commands that give the user a well defined way to say when they want something to go away vs. when they want something to go away and quit doing anything. Re-implementing "go away and quit working" on a case-by-case basis is going to end up with every app either having a nonstandard interface for doing so, or no way to do so at all (like most update managers.)
Personally, I think "some apps don't quit properly" is a description of a problem with the apps, not with the "quit" command. Comparing to mobile is a red herring, because you can in fact quit background services on most mobile platforms, and it's a necessary thing to do. It's only programs that by design, always gracefully suspend, full stop, and resume later that make sense to not have a quit command.