This wasn’t an easy decision for me; but after much thought I eventually felt that it’s a necessary move - although it might be just temporary.

Rationale

The main reason is that I need a larger test base: I’m still getting odd logs from time to time, but it’s impossible to know if it’s the occasional hiccup on a phone that could use a reboot, or a more serious, reproducible problem that consistently occurs on, say, 1% of configurations (for once I’ll spare you the usual tirade about good ol’ Android fragmentation, irritating manufacturer “customizations” that sometimes even break the public API, etc).

If such a problem were to make it unnoticed to the “stable” Market release, it’d make lots of users sad (a little sadness * 1% of tens of thousands = waaaay too much sadness).

Secondarily, it’s taking too long to get v2.x to stable; again, there are too many Desire users with a not-really-working JuiceDefender v1.8.8 - and crappy battery life is a sadness factory. Most of them would be much better off with v2.x - having to deal with minor bugs here and there is certainly worth the added juice - but they don’t know about the beta or don’t care about installing apps manually; the Market release helps with both problems.

And lastly, it’s also an improvement for the current betatesters (automatic updates ftw - but see below) and for JuiceDefender development in general, as it will allow for more timely feedback on releases.

<3 tiers

JuiceDefender releases for the next few weeks will be three-tiered à la Chrome: stable, beta, and dev (why not alpha?)

The most experimental stuff (crazy changes or new features) will go to dev builds, for the exclusive enjoyment of the private beta group (they have what it takes to handle the risk) and their phones. Once reports of exploding phones become rare enough, the “non-explosive” dev build will go beta; and similarly for beta to stable. “Safer” tweaks and fixes will go beta directly.

As a consequence of this move, the beta group (which probably needs a new name now) will be somewhat transformed in scope: although I’m sure it will keep providing the top-notch, quality feedback that is invaluable (even more so for the uncharted territories of dev builds) for such a complex application, hopefully it will become a bit more of an idea forge, focusing on open discussions on the design side of things (UX, feature set, implementation decisions, etc).

So! If you’re still using v1.8.8 (the latest “stable” Market release), and you don’t mind the occasional bug, sending crash logs, or participating in the feedback forum, help improve JuiceDefender and go beta! See here for warnings and handy links ;)

About the “proper” website, I’m trying to organize things better and make information easier to find. For open, public, and hopefully community-rich support, I’ll test UserVoice for a while, force-fitting its intended use to my needs; I’m hoping it turns out to be a workable solution, as a full-fledged, dedicated support service would (again) increase my workflow overhead to the point I just wouldn’t be able to keep up with it.

Email too

The main objective is of course to divert support requests off my exploding inbox. Speaking of inboxes, I spent some time researching ways to optimize email workflow; Gmail is wonderful but it just wasn’t built for high volume, and Labs features or Chrome extensions/GreaseMonkey scripts only partially address this. (On the plus side, Chromed Bird should now help force me into actually using Twitter.)

So for now I settled on a very old-fashioned setup using Thunderbird and a couple of crucial add-ons. I’m spoiled by Gmail’s beauty and intuitiveness, and the desktop-client experience feels painful in many ways; but it’s certainly faster after some (re-)training.

Due to a mix of having to attend to unrelated personal urgencies, being busy with all the scaffolding work I’m describing, and (mostly) the well known, crushing feeling of hopelessness that leaves even the best intentioned, naively can-do guy completely devoid of energy when facing an overwhelmingly huge task, I’ve been neglecting my inbox for weeks. Negative feedback loop, glad to see you again…

JuiceDefender

With all this nasty stuff going on, I needed to relax a little, so I’ve been working on yet another rewrite of JuiceDefender’s internals; the architecture is now more clearly laid out and modular, so bug fixes and new features should be easier to do.

More importantly, I did some more performance profiling and had a couple of surprises: two Android core APIs - the sqlite database and the preferences - sport relatively poor performance. Now, JuiceDefender does use these two APIs somewhat heavily; also, I’m an optimization freak; also, every spared CPU cycle is a tiny little bit of saved juice ;) . So I spent quite some time rewriting all core “utility” functions to use my own ad-hoc, low level, fast implementations.

The new builds are certainly much faster - to give you an idea of the numbers, a “complex” trigger cycle went from 500/1000ms execution time to something around 200; just by getting rid of Android’s database and preferences! But there are probably some hidden weaknesses in the new barebones code, so it’ll take some time and extensive testing before the new engine makes it to the Market. 

(Note to self: to avoid a gloomy, depressing tone don’t write posts after a half-night of troubled “sleep”.)

And now, on to writing FAQs!