Strange restrictions on libraries in Android SDK v8

So the Android team finally get around to adding support for libraries to the ADK’s build process for froyo (2.2, or SDK v8).  Fabulous, you say - so now you can finally extract that chunk of, say, com.ctoforaday.common, rename it to something guicey like com.ctoforaday.guicedroid, and start extracting the reusable bits of guice coding you’ve been building in your application into a place others can use to start freeing themselves from the nightmare of singletons, subclassing, and oversized contexts that someone who much too much liked the word ‘discoverability’ choked on one morning and died from.

So I went and did that (splitting out the project, not choking and dying).  Even got a private github repository hosting it as a separate project, which eventually I’ll get around to open sourcing.

Here’s the gotcha:  Inevitably, someone who writes tests is going to have two implementations of a class, a real one, and for complex stuff, a fake one.

Here’s the limitation: A library can’t depend on a library.  So you either ship your mock/fakes in with your core library, and therefore straight into people’s binaries, enabling the possible mess of ending up with fakes used in production code, or you end up building the mock/fake implementations in each and every test project you create.

I don’t know what it is about testing that mobile developers just don’t seem to get.  It’s as though they assume that their time is worthless, and they’d really like to spend the rest of their lives debugging code.  Executing Android tests never gets easier, never gets faster, and actually writing android tests isn’t becoming a warmer or happier place.  It’s as though they’re just not expending any efforts to improve the testability of the product, or just assume that absolutely everything to be written for Android is either so trivial as to not require testing, or so complex that it’s “too hard” to do anything about.

Bloody frustrating.  Turns a half hour’s extraction into an entire morning of playing with Eclipse wondering why things don’t just work the way you’d imagine they would.

Weathrman 3: The Weather Cloud

One of the big problems with Weathrman’s current implementation is that the whole implementation lives in your phone; a worst-case search can trawl through literally tens of thousands of search results, searching for an image relevant to your weather conditions and time of day.

Many of those searches are common to others; city-level searches are the same all over London, for example; local searches are the same for everyone sitting near me.  Much of this can be cached aggressively, massively reducing the amount of time it takes to get good results, and allowing me to do more searches, more often, at less cost and lower latency to end users.

It’s not ready yet - I’m nearly ready, probably another day away or so, and I’ll probably test it out for a week or so.  Come Google I/O, though, I’ll be ready to ship.

It’s notably faster, and pushing the image scaling to the server has resulted in massive improvements in image quality, while turning hundreds of RPC calls to flickr into a single call to the weatherman service.

Weatherman 1.3 now available in the Android Market

I’m looking forward to getting some feedback.  It’s been… I think I opened the github account on the 28th of December.  I built and threw away a live background that ran cellular automata, which I really, really wanted to do, but Android’s drawing routines just aren’t good enough/fast enough to really allow for that.  (The automata itself was happily running at 15fps, but the UI update was <3.  Boo.

A commit on the 30th of December is really the beginning of this app’s life.  Today’s the 6th.  In that time, I’ve done more obsessing than I care to admit; I’ve had a really good time building this, and while it’s not perfect, I’m a great deal happier with the state of modern Android development than a year ago, and a good chunk of that happiness didn’t actually come until after I pulled Guice in as a dependency.  Shame that didn’t get built into a core part of the API, IMO, but I’m happy now.

I wanted to call this Weathr; that’s certainly the obvious thing.  Weathrman is just a bit too long for my taste.  But someone else appears to have had a similar idea, albeit for the web… it looks dead, but there’s no point risking it, and this does just as good a job.

I’m tracking exceptions and stuff to Analytics; I reeeeally wish there was a built-in exception logging API that pushed stack traces and bug reports back up to the marketplace.  Still, I’m looking forward to seeing how this works in the wild, and whether or not it’s an utterly broken experience in cities less populated than London.  I do my best to find local photos, but it will eventually do global searches…

I remain concerned over a few things.  I’d like to find some way to re-set myself as the active wallpaper if I’m the active live wallpaper and I update the binary.  If you know how to do that, ping me.  I hate the fact that every time I update this thing I have to go back to setting it as the current wallpaper again.

And I really ought to test this on a phone that isn’t a Nexus One.  Should you try this app on something other than an N1, do tell me what the experience was like.  Some things, methinks, won’t make sense - I should probably be more careful than I am, for example, about which image size I choose for download, rather than always assuming that bigger is better.

I look forward to hearing from you.