On 29 Okt., 13:14, Eric F <ericfrie...@gmail.com> wrote:
> 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.
No, I don't disagree. But I think there should be a common (user)
interface and good system support to reach the gains you listed above.
> This is a separate problem of notification. The notification APIs
> already have good ways to notify users when something happens.
Sure it has, but they're not always useful. I neither want a
notification bar icon while a twitter client checks every 15 minutes
for updates, nor do I want a toast message "no new mails". For some
tasks it's fine when I don't see them unless I'm explicitly looking
for "what's running in background".
> 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.
That's the problem...
> I was
> trying to suggest that RAM management and RAM management only on a
> self managing device is the psychological placebo.
OK, true. But it seems like Google knows that already.
> > 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.
There's no way to say for sure, but it's what I read again and again.
> If you go to settings
> -> applications -> manage application -> running tab, I think you will
> see something very different from running services.
I must admit I've no clue what they're showing there. Looks quite
random to me, but of course there has to be some system...
> Long press home combined with pressing an applications icon accomplish
> already have a parallel for this.
Yes, somewhat. But it's not managable ("I don't need this app anymore,
I finished the task"), often misunderstood as task list, and hard to
find.
> So simply a user reconfigurable list of most recently used apps.
> Sounds like a reasonably harmless placebo.
Well, that, combined with a list of apps doing background work and a
unified, but optional to the app developer, way to stop the background
work ("kill the app").
> Your mixing problems. Asking "what's eating my battery life" is a
> different question from "what's running".
Not completely. An app that doesn't do anything won't eat battery.
The battery consumption display also isn't always helpful. E.e. I
expect a game to drain lots of battery while runnig, but it's hard to
tell if it will still drain battery after it's been "closed".
> 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.
I think so far, everybody will agree.
But I think the question "which apps will do background work" is
valid. Because in most cases it's shortened standby time that confuses
users, and if you know what apps still keep working, you could check
their preferences or uninstall them.
> 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.
I does for memory management. But there's also the remaining user
experience: "I don't need this app anymore. Please stop doing anything
and start all over next time I run it." I'm not sure if it's a good
idea to split it into two separate concepts.
> 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.
Memory management is fine on Android already. If it was only for that,
I don't think so many people would stick to task managers even after
reading "you don't need task manager" threads in forums.
> 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.
But an app can't tell if a user wants it to still do something in
background or not. That'll always be up to the user.
If Google (or anyone here) can come up with an intuitive, unified way
to reach the two goals "leave and reset to start" (without having to
press back dozens of times) and "leave and stop background tasks"
separately, great. But I think the meme "exit = stop all work and
reset" isn't that bad as well, and an intuitive, unified way to reach
this is easier to reach and implement.
> 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.
Well, there'd be no harm with a "user version" of a task manager. It
might be unnecessary once the user has unified and simple control over
background jobs, but it would serve the psychological "need" without
messing up Android's memory management.
> 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.
So true... It's similar with the different handling of the back button
as well, btw. Sometimes it brings you back to the recent activity,
sometimes to the previous content. But that'd be another topic...
--
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
