These essentially all boil down to the same issue - search quality.  I need to do more filtering of results to try to wipe out irrelevant or unwanted photos.

My current thoughts go like this:

• Add “underwear” to the negative keywords list.  I don’t really want to see people in their undies on my phone.
• Add “indoors” to the negative keywords list.
• Remove images that weren’t given proper titles by the person who uploaded them.  If you didn’t care enough to name your photo, I don’t care enough to see it.  This includes all-numeric titles, and titles which contain only IMG_XXXX.

There’ll be an update this weekend if all goes well.

Yahoo’s feed is damn good; it has flaws, but it also has huge benefits to us - the most important of which is that Yahoo’s weather API provides current conditions and the sunrise/sunset times in your location.  This means that as of 2.4, we started preferring photographs of sunrises and sunsets whenever the weather was clear or cloudy.

As of 2.5, we’re again increasing the number of queries we perform on a search, and that’s going to increase the amount of time we spend updating; but the upside is that we’ve got more images to choose from, and as of now, we’re going to stop preferring what Flickr thinks is interesting, and start randomly selecting from the set of selections we have at the nearest location to you we can get them.

For a while, I was seeing the same photos, day after day - now, I don’t think I’ve seen the same thing twice.  At the moment, I have a particularly beautiful view of Leicester Square, taken by maistora.

I look forward to hearing your opinions on the new version.

First, foremost, and most recent is the change to Flickr’s weather API.  Google’s is free-text, and there’s no clear listing of what, exactly, it returns.  Yahoo has a nice, clean API and a simple enumeration of possible conditions, making my life much, much easier when it comes matching conditions to an appropriate set of search terms.

Changes to the “about this image” view when you double-tap the screen now shows the weather conditions at the moment the image was gathered, which should help me diagnose when people see volcanos.  Also, the weather condition associated with a volcano is now “Imminent volcanic death”.  I look forward to seeing that bug report.

Last, there have been some changes to the way preview works.  People expect an instantaneous preview, but as of right now, the process of fetching an image is anything but instant; also, we use lots of data, and Flickr’s APIs are blocked by some carriers.  I’ve replaced preview with a carefully rendered view explaining these and other issues to users.

I’ve got some very positive feedback as of late, but as always, more is better.  I look forward to hearing from you.

It also takes the text off of the background image, which leaves a prettier desktop, and we improve the image quality while we’re at it.

I look forward to your comments, which you can send using the support form, or on Flickr.

You’re forgiven for thinking that there’s been no progress on Weathrman as of late; in fact, there’s quite a bit going on behind the scenes, including:

• Translated search terms, to pick up tourist photos.  EFIGS first.
• Status bar notification while the desktop is visible to provide better UI discoverability
• UI showing details of the current photo and linking to it on Flickr
• Some kind of resolution to the updater problem

I still need some kind of resolution to the updater problem, but that might not happen until 3.  At worst, I’ll build an intent that explains the nature of the application and gives the user a one-button way of udpating wallpaper.

But first, I need a haircut.  And to start Darksiders.

I hit three different kinds of issues:

• Unnecessary updates.  If the offsets applied were the same as those currently set, I was forcing a redraw when there was nothing to draw.
• Backing store size.  Evidently, the ‘optimal’ canvas depth is 565; up until now, I’ve been keeping ARGB_8888 canvases around.  Shifting down to RGB_565 results in a massive improvement of the performance loop.
• Image load.  The flickr image was being loaded in ARGB_8888, even though we were never going to make use of the transparency data in the backing store.  As the rest of the visual change has moved to 565, I do so here, as well.

The net effect is to massively reduce the amount of time we spend rendering, and the size in memory of the backing store.  In addition, we’re less peaky when we load a fresh image from Flickr.

All of this should result in fewer cases where Android decides to eject the live wallpaper due to ANR.

While I was at it, I added a few more tweaks; we now track how long we’ve been asleep for, and on becoming visible, reschedule our background timer.  You should find that the app is much more likely to keep itself current, now, and should begin updating itself within moments of the phone ‘waking up’.

As always, I’m gagging for comments from users, here.  Either leave them here, or mail them using the support tool.  I look forward to hearing from you.

On the cards is:

• Lots of tests.
  Right now, I’m testing non-android code fairly well, but I’m not currently thrilled with the state of testing of android-level functionality.  To keep things clean, I’ll be isolating android behaviour into provider methods that return the answer I wanted - injecting, for example an @Named(SHOULD_UPDATE) boolean shouldUpdate, for example, which checks preferences and network availability before returning a simple, injected boolean, isolates the android weirdness from the perfectly normal code beneath.
• History.
  Right now, you only see a new image if Flickr decides there’s something more interesting than what you saw yesterday at the same time in the same place.  Most of us spend a lot of time in the same places, day in, day out - but we always want to see new things.  I’m going to keep a history of stuff I’ve seen recently, and exclude that.  This means that double-tap won’t reload the current image, it’ll choose a new one.

At that point, I think I’ll be ready to re-look at the frontend/backend separation; it may well be time to start looking at a content provider implementation to wrap up the fetching behaviour and history implementation in a nice, neat package.

The other is tougher.  I’m making some changes to the queries we perform against Flickr’s API in the hopes of improving the quality of results, especially under clear conditions.  Some of these are as follows:

• For queries performed at night, AND() in a set of words that are likely to be associated with night photography.
• Add a list of “banned” terms, including “naked” and “nude”.  I don’t mind looking at them on the web, but I don’t want someone’s naked butt hanging out of my phone.  Your mileage may vary.
• Separate daytime descriptions of “clear” from nighttime ones; include in those things you only see during the day/night cycle.  (Nights, for example, might include stars, constellations, or the moon.)

These and other tweaks will hopefully improve the quality of search results returned, and they should feel more relevant; the negative side of this is that it might be much harder to find a well tagged local photo.

If you have good ideas, as always, I’m listening.

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.

Also included in that how-do-people-live-without-this-stuff list is decent dependency injection.

I didn’t notice until I was a long way into the project that Guice now has support for Android.  At the moment, I’m using Guice 2.0 without AOP, Multibindings support, and assisted inject, and quite frankly, the code is almost instantly better for it.  Constructors now only contain what the local object needs to use to do its job, and everything is an awful lot more readable.

It’s also nice not to have to pass around awareness of the fact that Android’s context classes are a pig’s ear of methods.  There’s nothing wrong with using composition instead of inheritance, folks; your application classes shouldn’t need to be a combination of implementations every single interface in the SDK.  That’s not discoverable, that’s just a wall of noise.

Anyways, four hours of un-hardwiring class construction resulted in a much easier second refactoring to start splitting foreground from background services, which took all of an hour and only involved creating a new module for the new service class, and poof!

I still wonder how people get on without DI, and why on earth this isn’t core java yet.  Mind you, I wonder that about Joda, too.  And closures.  And just about any other modern feature that doesn’t make it into the now-overpoliticized trial by fire of the JDK.