Ultimately, I think it boils down to a few things in a nutshell (and my guess is that we agree here):
A) The user should have a good understanding of which applications are hindering performance (running smoothness. "Why is my home screen so jerky?") B) The user should have a good understanding of which applications are hindering battery life C) The user's anxiety or feeling in control or being comfortable is a goal but not at the expense of the right technological decision. Then I suspect these may be more of the points of disagreement: D) It's up to the developer of an application to offer the user controls to tweak performance sapping or battery draining. E) A user uninstalling an app that performs poorly and offers no controls to fix unwanted execution is preferable to a user living with the application and periodically killing it. F) If the user has good insight into A) and B) above they should have no need to be able look "under the hood" of the phone to see how it's operating. Then I made some comments in-line On Oct 29, 1:28 am, mort <m...@sto-helit.de> wrote: > On 29 Okt., 04:49, Eric F <ericfrie...@gmail.com> wrote: > > > I think there are two problems here, both of them psychological and a > > problem adapting from the desktop. > > Regarding the problem "when the hell is an app doing something when I > don't see it", it's not just psychological... This is a separate problem of notification. The notification APIs already have good ways to notify users when something happens. And if an app doesn't notify then the user needs to be able to be able to find out that it's draining performance in some other way. I was trying to suggest that RAM management and RAM management only on a self managing device is the psychological placebo. > > My recommended solution, in all APIs and OS screens that report > > "active applications" should only show/return applications that are > > consuming more than an idle amount of CPU, not just any application > > that has a PID. > > If you'd do that, you'd get the same result as listed in "running > services". Android stops *every* app that doesn't have a running > service. I don't believe this is entirely true. If you want more of a guarantee that your process keeps running without a foreground activity you must use a service, but I don't think onPause/onStop automatically stops all your threads immediately (I could be wrong). If you go to settings -> applications -> manage application -> running tab, I think you will see something very different from running services. > That's where another "psychological problem adapting from the desktop" > comes in: People are used to use task managers for managing *their* > tasks, like, I've got Word, a browser, and a file manager running, and > want to switch between them regulary. Long press home combined with pressing an applications icon accomplish already have a parallel for this. > That's why Bob and me proposed the task manager with status > information, which I extended with ways to "kick" apps from a "user > task list" without changing anything about the actual system task > management. So simply a user reconfigurable list of most recently used apps. Sounds like a reasonably harmless placebo. > And then there's the problem with AlarmManager: If the app's not too > badly written or doing really long lasting stuff, you'll rarely see it > in such a task manager, nontheless it will regulary do something that > might drain your battery or slows down the device. Your mixing problems. Asking "what's eating my battery life" is a different question from "what's running". My sole argument is that users should never ask "What processes exist on this system". Because that's not helpful and confuses the user, because some apps shouldn't be considered running simply because they are cached in memory. The battery life problem is a lot more complicated than a "what's running" problem. Android needs some serious improvements in this area, but I think they know that. > > 2) People associate, just like on the desktop, not wanting a function > > of an application to quitting the application. Earlier mort was > > suggesting the same thing. Twitter should have an "exit" button so > > that a user who wants it to temporarily stop fetching tweets can do > > so. This is wrong. If the user wants it to stop temporarily retrieving > > tweets there should be a button that says "disable background updates" > > in the application.. > > That would technically be correct, but isn't that just talking about > words? There are lots of technically wrong terms to make things easier > for users already. So why not stay with "exit" or "stop", which seems > to be interpreted (sufficiently) correct by most users? "Disable > background updates" (or any other "background work") is long and too > technical for most users. Android's too close to a nerd system in some > regards anyway... Yes it is, and the problem is not a technical one, so I think the solution is apt. The concept of "exiting" is no more. The two new concepts are "Take me back to the beginning of the application" (because state is always saved, so one can't quit an application and restart it to get to the beginning), and "Don't do some stuff when you're not in the foreground", of course developers are responsible for implementing these in their applications or users will get frustrated and yearn for an "exit". But "exit" is no longer the right concept. In an environment without virtual memory it has no place anymore. Android's low memory killer and virtual memory perform the same feat. Allow the user to do whatever they want without ever displaying a "I'm afraid I can't do that, there's no more memory" to the user. A side effect of virtual memory is the onus of task management burdened on the user. It is not a feature, or a goal, it's a side effect of the virtual memory medicine. > > Solution is to have a Android Developers Blog post about why an "exit" > > button is wrong, > > I don't think so. There were blogs, posts in this and other forums, > etc. But only (some) developers read them, and maybe some users so > frustrated with Android they feel the need to let off steam in some > user forum, where they might get helpful answers (or be advised to use > a task manager...). > As long as the users feel they've got no control about when an app is > "running", they'll want an exit button, even if there was no app with > one at all. You are correct many users will want an exit button. And they will continue wanting them while the technologically minded refuse to accept that the notion of users managing system resources is antiquated and not fit for mobile. Once all the developers manage to educate themselves (and I think the desire for task managers is worse for people who consider themselves "in-the-know") and respond uniformly on the issue the average users' understanding will shift too. I've read every Android developer blog post and I don't think they've directly addressed this issue. Certainly if you look at stack overflow you can find a few examples of programmers with big egos thinking they are far brighter than the whole Android team combined on this issue. The idea of needing a task manager is going to continue to trickle down from people who know enough about desktop computing to be dangerous to the general masses for a while. > btw, I want to notice there's a third reason for an "exit" button: > Take an app like the default browser. Sometimes you'd need dozens of > "back" presses to actually leave it. The other alternative is only to > keep it loading the current page in background after leaving with > "Home", even though you don't care about that page anymore. Agreed. Which brings me back to wanting a blog post that addresses "User interface concerns in a system with no quitting". Uniform UI in the platform isn't the result of a common API, it's the result of a common understanding between developers. > > (...) Maybe talk about when it's > > appropriate to terminate Threads or AsyncTasks as the application > > lifecycle changes. Should the app finish downloads that are only > > relevant to the active UI when the UI hides? What if the user is > > coming back in 2 seconds, what if not? When should they be interrupted > > and cancelled? I think this would be an excellent topic, certainly > > some advise I could use in my own applications. > > Good point. It wouldn't help with the psychological problems, but sure > might improve performance and battery live. Well I think my general idea here is, decrease the number of misbehaving applications results in users feeling less anxious not being the overseer of their phone's internals. -Eric -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
