The API of Unintended Consequences

A change to the Android API that arrived in the KitKat is that alarms don’t necessarily arrive when your code requested them to. From the docs:

Note: Beginning with API 19 (KITKAT) alarm delivery is inexact: the OS will shift alarms in order to minimize wakeups and battery use. There are new APIs to support applications which need strict delivery guarantees; seesetWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent). Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.
Now, many apps won’t be especially bothered, but I have two apps with clock widgets that rely on the alarms being delivered exactly on time; otherwise, the clock widget is wrong until the alarm does get delivered. Which means that my widgets now need to use setExact() rather than just set().

Which is fine as far as it goes – but what’s not mentioned above is that there is no setExactRepeating(). Here’s another extract from that same page:

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whosetargetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.”

This means that my widgets must now reschedule their alarms every minute. Which means my widgets are now running more code every minute than they were before. Which means that my widgets are now using more battery than they were before – exactly the opposite of Google’s stated intent with this change.

Footnote #1: I should also mention that, in my testing, these inexact alarms occur on KitKat devices even if targetSdkVersion is set to 18. That’s not what the docs (quoted above) say, but that’s how it works on my Nexus 7.

Footnote #2: No, I can’t use AnalogClock and Chronometer to avoid these alarms (and use less battery). They’re too limited for my widgets. My analog clocks are 24-hour (the AnalogClock class is 12-hour only), and the Chronometer class really isn’t suitable for digital clocks.

Resistor Decoder

An app like Barcode Scanner but for resistor color codes: Using the camera (and probably requiring the flash), read the color bars off a resistor and output the resistance value.

I have little doubt that it’s possible, but at the same time, it’s probably a nontrivial problem in image processing and pattern matching. And, beyond its niftiness factor, it’s not something that very many people would pay for. So, not worth the effort, unfortunately.

It’s more the sort of thing that some geeky Googler should do in his 20% time. Or, some random geek with more time on his hands than me.

Meta Cloud Drive

After seeing yet another “sign up for our new cloud drive, get 20GB free” offer, it dawned on me: could you make a “meta” cloud drive that works purely by piggybacking off others?

The idea is that the MCD would have interfaces to loads of “normal” cloud drives, and would manage your storage appropriately. So if you had 5 or 10 GB from each of Dropbox,, GDrive, iDrive, SkyDrive,, Wuala, and so on, you could easily end up with a couple hundred gigabytes. Then your MCD would bring them all together, managing them as a single virtual drive, so you don’t have to worry about what’s actually stored where.

If you had enough space, it could even incorporate RAID-like functionality: replicate individual files across multiple cloud services so that, if one is unreachable, you wouldn’t lose your data.

Ideally, it’d also manage your accounts with the different services. If you had existing accounts you would go ahead and enter those credentials, but I’d like to see it automate the sign up process for others. IOW, you open an MCD account, and can then automatically sign up with 10 services behind the scenes. We might even be able to do something crafty with referral bonuses behind the scenes to leverage extra storage for our users.

Travel Weather

This idea was inspired by WUnderground’s Road Trip weather, but I envision something much more configurable, useful. Basically, to be able to set dates (and optionally, times) for a list of locations and see the current weather forecast for each time/date combination. Obviously, it would update with new forecasts as time passes.

It could be standalone (enter your itinerary manually), but would be better if it integrated with something like TripIt. It’d also be nice if you could enter endpoints for driving directions (for a multi-day road trip) and build from that.

FAD Followup

…where FAD stands for Free App of the Day, the Amazon Appstore’s program where they offer a different paid Android app free to customers every day.

This is a followup post to my original FAD thoughts, posted shortly after I had my first app in the program. Exact download numbers are Amazon-confidential, but suffice it to say that Moon Phase Pro got hundreds of thousands of downloads that day, which significantly boosted its visibility in the Appstore and led to a marked increase in paid revenue for weeks afterward. A good deal all around.

Some months later, Amazon offered me another FAD spot for another app, PolyClock – and since my first experience had been quite positive, I didn’t hesitate. This time things didn’t go nearly as well; the total downloads were much lower, and there wasn’t a significant sales boost after the day. I simply chalked it up to the app in question being more niche-oriented, with a narrower appeal. And since there really wasn’t a downside, I didn’t worry much about it.

Then came my third app in the Program, Convertor Pro, after Amazon extended FAD to their European markets. And unfortunately, I have to say that this was a downright disaster. Again, I can’t reveal exact sales numbers, but since around Christmastime Convertor Pro has been selling reasonably well in the UK; it’d been hovering in the top 5 in its category. Not paying for my retirement, perhaps, but a respectable earner.

Then came its FAD spot – and sales immediately plummeted, to a small fraction of what they’d been before. It’s been about ten days now, and its ranking in category is currently around #15 and still dropping.

Of course, I have no proof that FAD was responsible for the drop, but when you look at a graph of its ranking over time, the correlation is hard to deny:
That green bar there is its free day. (The numbers below are its ranking on a given day before FAD.)

So in summary, I’m nowhere near as impressed with FAD as I was a year ago. Perhaps it still makes sense for some apps – but my advice right now is: if your app is already earning any kind of money in Amazon’s Appstore, don’t risk it.

First-Person Minesweeper

That’s it, in a nutshell… Reorient the classic Minesweeper from top-down to first-person. It’d be surprising if nobody has done it before, but I don’t think that I have seen it. My vision is for it to have a maze/dungeon appearance, where the game play involves knocking down walls as the metaphor for clearing cells.

Not clear how you’d get “past” flagged cells… Maybe a 3D aspect?

Working title: Sweepminer

Nexus Q Bafflement

I have to confess, I’m baffled by Google’s new Nexus Q. I’m not lucky enough to have one myself, but everything I’ve seen indicates that it’s a well-engineered, expensive, one-trick pony. And it might not even be that good at its one trick (

Why isn’t it a Google TV device? Or better yet, why isn’t it the first “Google AV” device, marking the next step in GTV’s evolution: from just TV to full-on home media. The hardware could be identical*, the software very similar – but it’d be able to play any media, from any source, not just the tightly-restricted source list of the current Q. *And* it’d have access to the Google Play app store, meaning that average users could install a plenitude of other apps on it too. [From what I hear, the only way to install new apps on the Q is via ADB.]

And while the Q’s social-media trick is a good one, I have no doubt that it itself is just an app, running on the Q’s underlying Android OS. Which means that *the same app* could run on any compatible Google AV box. Or any other Android device, for that matter… you could run it on your own phone or tablet, with the output routed through bluetooth speakers, and get the same Q functionality with zero additional hardware cost.

Had it gone this route, the Q could’ve been a big win for Google, breathing new life into the floundering Google TV ecosystem with compelling new functionality, and providing it with a Nexus reference device to boot. Instead, it looks suspiciously like a dead end.

Maybe it’s not too late. I’d expect that the existing GTV OS would just run on the Q, so given that it won’t hit the public for another few weeks, Google probably still has time to make this change. Not that I think they will, but I’ll bet they could.

*As good as the hardware apparently is, though, any home media component *really* needs to be stackable.