Weathrman 3.1: The Freshmaker

Lots of minor tweaks going into this.

For a long time now, doubletapping has been problematic.  I install a double-tap handler the same way anyone else would, but end up seeing events that belong to the foreground application.  Android has a mechanism for wallpapers to see only two possible gestures out of all of the ones an Android can handle: a tap, and a drop.

I’ve constructed a (very) simple double-tap handler out of the tap events sent via onCommand(), instead of installing a gesture detector, in the hopes of getting rid of these ‘false positives’ that result in the information-about-this-image dialog appearing too often.

I’ve also removed, you might be happy to hear, all analytics tracking.  Its primary use was to send back stack traces and errors back, so that I could track down client problems.  New features in the Android Marketplace for publishers means I should be getting stack traces directly in the publishing console… but I don’t, because they’re not being seen, because I’m sending those stack traces (in a much less efficient form) to Analytics.

So, analytics is gone, which will result in a better experience for all.

I’ll be pushing this onto the market shortly.

Of Clouds and Silver Linings

I’ve updated the AppEngine app that weathrman uses to perform its searches to a later version of the SDK; hopefully people will either see no change, or see improved response times; I’ll be monitoring the service over the next few days to ensure that all is well, and that error rates stay roughly where they were (or drop).

Fingers crossed.

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.

Weathrman 2.5: In the mix

So I’ve made a few more small tweaks since the 2.x series started, the biggest of which is in who provides our weather data.

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.

Incremental updates: Weathrman 2.3

Three more releases since I last posted; each picked up on small feature requests and things on my TODO list.

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.

Weathrman 2, and the Pile of Shame

Shadow Complex is done; and while I’m happy that I’ve managed to take another game off of the pile of shame, which is currently shrinking faster than its rate of growth, I feel a bit funny about playing an Orson Scott Card title, given his political slant.  I wish Chair wouldn’t do that; it’s not like that ending was so good that they needed OSC’s involvement - that was one of the worst endings I’ve ever seen in a videogame.

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.

Weathrman 1.7: Performance Optimisations

I noted that every now and then, Weathrman would get killed due to not being responsive enough to a change of wallpaper offsets (finger scroll, etc.), and decided to take a walk and look at the performance of what we were doing.

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.

Weathrman 1.5 hits the Android Market... now

This update is fairly experimental.  One small change - ensuring that we don’t try and fetch data when we haven’t got a connection established - should hopefully improve performance under edge-of-network behaviour.

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.