You want users to complain less? Then get rid of task managers
entirely. They are the problem - they are the ones "listing" "active"
apps, when the app is simply just in memory doing nothing.
You want to get less complaints? Stop writing crappy apps and learn
the proper App lifecycle. It's not rocket science.
-niko
On Oct 30, 1:47 am, mort <m...@sto-helit.de> wrote:
> 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
