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.

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: Any issues?

I’ve heard of two kinds of problems so far; a user reports that on a clear day in London he got a photo of stormtroopers, and another, travelling with roaming off in California, got a crash.

I’ll see if I can investigate and patch next week for the latter crasher. As for the stormtroopers, I fear nothing short of thumbs up/down will do. That will take a (wee) bit longer.

Post if you’ve seen something you think needs fixing.  Personally, I want preferences, and maybe support for wifi-only updating.

Weathrman 3.01: Amsterdamn, I broke the build

Users in non-English locales, particularly those that were in locales that format decimals with commas instead of periods, and periods instead of commas, were sending date information over the air in locale-specific format.

I’ve sent out a new release that should fix this issue; I’ll be watching the logs over the next few hours to ensure that all is well.

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.

Open Issues

I’ve seen some strangeness lately, brought on by the fact that we’re no longer making direct use of Flickr’s interestingness to choose which photo to show.

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.

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.