(Suggestion) Let's save the final remaining percentages of the battery

1 view
Skip to first unread message

Julian

unread,
Jul 17, 2010, 5:55:36 AM7/17/10
to JuiceDefender
Most of us know the problem of wrong time management: When presented
with a given time for a project we at first use our time lavishly just
to find out a few weeks before the due date that we need to do more
than anticipated. I like to call this the parabel of learning as I
often experienced this "problem" when learning for tests.

And I think that the way we use the battery is similar. At 100% most
don't care about lowering brightness, not using the battery intense
streaming app or turning on the phone every couple of minutes to check
whether someone has commented on the pictures you have posted of your
drunk friend falling over on Facebook.
At 50% most of us start to reconsider: "Should I really watch this
vid? Yeah 50% is plenty".
But once it reaches 20% with a reasonable amount of day left to pass,
preserving battery becomes the utmost important issue.

Of course JD can't induce better usage patterns in users, but it could
really help with saving the last percentages of battery once it runs
really low.
The given "Disable if lower than X" method is very crude albeit very
effective and should be revamped. My suggestion would be to offer
different settings once the battery goes below X. Meaning different
settings for Timeout, Schedule, APN and WiFi once the battery reaches
a critical level.

Opposed to completely turning off apn and wifi this would make it
feasible to change the pattern with more battery left. i.e. one could
leave wifi disabled and only run on APN once the battery reaches 40%
and / or change the schedule from non-quick to quick or even increase
the scheduling time.
An option to change the display brightness could also be highly
beneficial although I have to admit I am quite confident with the auto-
brightness settings of my galaxy S

Greetz to all,
Jules

Ignacio

unread,
Jul 17, 2010, 2:25:20 PM7/17/10
to juiced...@googlegroups.com

This is almost philosophic :) great post

Enviado desde mi "peazo móvil"

Mark Lowne

unread,
Jul 20, 2010, 6:04:05 AM7/20/10
to JuiceDefender
Nice post indeed! I've added a couple of new settings in v1.8.3 to at
least partially address your suggestions.
But it's a crude solution... On one hand, one might want to stop
Pandora streaming ('ignore on battery' under 'apps') when battery gets
to 30/40%, but having no internet at all ('ignore on battery' under
'screen') seems more like a 10%-threshold thing.
On the other hand, having different thresholds (or a wholly different
configuration for low battery) would be overly complicated to
implement.
Moreover, the Schedule is currently completely disabled once the
threshold is reached - again, probably not a good solution for >30%
thresholds, especially since the schedule usually doesn't drink all
that juice.

A couple of ideas from the top of my head to encourage a higher 'low
battery' threshold:
- instead of disabling the schedule outright, change it (if needed) to
a minimum frequency of 15 or 30 minutes, 'quick' - it'd have little
impact on the battery anyway
- disable the 'traffic' trigger to avoid potential quick drain because
of large background downloads
- if 'ignore on battery' is on for both 'screen' and 'apps', instead
of completely disabling the 'enabling' apps change the trigger so that
only foreground apps (with a visible - usually full-screen - window)
are considered

The last point especially would allow to have a high threshold while
still being able to check gmail/browse/etc without having to resort to
the manual toggle data widget.

Also, an option to keep WiFi always disabled in low battery might
indeed be sensible.

Discuss! :)



On Jul 17, 8:25 pm, Ignacio <soyunpla...@gmail.com> wrote:
> This is almost philosophic :) great post
>
> Enviado desde mi "peazo móvil"
>

Julian

unread,
Jul 21, 2010, 4:56:00 AM7/21/10
to JuiceDefender
I like the thinking behind the new addition, but I don't think this is
the way to go.

In my opinion the easiest way to implement low level battery saving is
to offer the user with the possibility to adjust ALL settings for a
certain battery level.
UI-wise this could be implemented with simple tabbing. One tab for
"normal" settings, and another optional tab for low battery settings.
With everything adjustable it is now the users choice what he needs
and want to do and furthermore offers a clear view of what exactly
changes ones the battery gets to the user definied level.

But why just 1 extra tab? If you offer the possibility to add tabs
this gets fully customizable, while at the same time presenting no
necessity to do so!

Mark Lowne

unread,
Jul 22, 2010, 4:08:21 AM7/22/10
to juicedefender
Exactly - many tabs, infinite reconfigurability!
The 'overly complicated' part is not writing the UI - it's tedious but
fairly straightforward. The real problem is that it'd mean a complete
rewrite of the Service, with 'dynamic' loading of rulesets, an
entirely new conflict-resolution logic, etc.
If there's one thing coders love (and I'm no exception - just ask
Location), it's the Big Rewrite; but experience time and again shows
that this is generally a Bad Idea (again, ask Location). Joel Spolsky
does a fairly good job at explaining why - for those of you who're
interested: http://www.joelonsoftware.com/articles/fog0000000069.html.
So, I'd be tempted to try and 'retrofit' the thing into the existing
code-base; it might not be impossible, but it would be like trying to
fix a broken lawnmower engine using a dishwasher one. Hardly fitting.

While the Big Rewrite might well be the way to go for a hypothetical
2.0 (or more probably 3.0) 'next generation' series, let's try and see
first how far we can get with piecemeal additions like the ones I
described above. After all, finding something that works for 80% of
users would already be a superb improvement.

Pawlye

unread,
Jul 22, 2010, 5:04:07 AM7/22/10
to juiced...@googlegroups.com
You know you'll get the detractors that'll say your app is "too complicated", right?  I know that's why there's a Simple and Advanced option, but I think JD does a superb job at maximizing battery life.  Adding this or that or making the code so smart as to read your mind is a bit overkill.  I'd love to see it work the way it's designed today...sans bugs.

You've done a great job with the improvements over the first release to the Market.  And, with the exception of 2.1 screwing it all up for us, it was rock solid and provided me sufficient battery increase the way it was then.  Add too much more and people will run down their battery life due to display usage configuring the hell outta JD.

Kudos, Mark.

-E
Reply all
Reply to author
Forward
0 new messages