On 29 Okt., 04:49, Eric F <[email protected]> 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... > 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. 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. 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. 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. > So a user running a shelves like application and it > launches AsyncTasks to retrieve book cover jpgs. Then user hits home, > immediately goes to their Task manager application, they see Shelves > running consuming resources. Then the AsyncTasks finish, there are no > more UI events driving more processing and voila Shelves disappears > from the "running applications" list. Wow it "quit", user figures I > don't need a task manager. Right. But if a user uses a task manager to switch apps, he couldn't easily return to the Shelves app. That's where the "paused" status would come in. > 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... > not an exit button. It's the insistence that > these two need to be the same thing that's the problem for developers > and adding "exit buttons". It's the combination of both points you noticed, imho. > 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. 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. > (...) 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. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
