Archive for March, 2010

Hand Warmer on Android Market

Monday, March 15th, 2010

Problem:
So you need to verify the upgrade life cycle of the Android Market *before* you launch your product, so you give yourself the goal of putting a completely new application together in the space of one hour.  It can be anything, preferably something original (iFart has already been done), so long and you can turn it around from concept to release in 60 minutes and don’t include any of your own company branding.

**Remember the goal is to evaluate the Market, not to spend time dwelling on the code.**

Handwarmer icon

So behold world, I give you “Hand Warmer!”

A one word concept, of an App that warms up your device (and doesn’t require any permissions to do so).  The idea came from an early product build that deallocated too many Java objects in a loop, which as  a by product would run the Android Garbage collector like crazy.  The overtaxed processor on the HTC Magic then generate a lot of heat… toasty.

Screenshot 1

State: Off

Disclaimer

State: Warning - show disclaimer to user before enabling the warmer.

screenshot 2
State: On.

Implementation:
Version 1.0 did nothing but show the hot water bottle (warming metaphor) go from black (off) to orange (on), and of course show the longest legal disclaimer I could write (i.e. will drain your battery, I do not take liability if you melt your device, etc.)  Apart from the welcome Activity, most of the code ran as an ongoing service, which displayed a “warming” notification in the top bar when the application was active.

I also went with the following (if partially untrue) tag line:
Causes the device to warm up in your hands.  Useful in winter.

Version 2.0 was an opportunity to test the upgrade life cycle and see how well it worked on the range of devices available at the time.  I will discuss the strange Android Market side effects in more detail in a later post.

I added the following claims to the description:

  • QVGA and WVGA support.” - Upgraded from 1.5 to 1.6 SDK, with the new “supports screens” Manifest tags.
  • Fixed Service Leak bug” - First time around my application “leaked” unused services (i.e. kept them running), this was due to an ambiguity in the SDK documentation which I have since fixed.
  • Now App is 25% hotter!!” - Mostly true, as I doubled the speed of a wasteful object deallocator loop which was providing the heating, although I’m sure the screen was using more energy (and thereby providing more heat).

Battery

Version 3.0 was particularity interesting because I added the Flurry Agent, so I could collect more interesting analytics that what I could get out of Google Market.  Also to encourage downloads (or upgrades), I added the claim: “Now App is now 20% hotter than before”.  Of course, for an application that doesn’t actually do anything, your results may vary.

Critical reaction:
Considering that this was an hour off work, I was absolutely gob-smacked by the shear volume of downloads.  Review were mixed (obviously) with many highlighting the dangers this application posed to the device.

Moral review

And of course this being the Android Market, I got my fair share of…

Bad review

Obviously if I wanted to warm the device I would lock the screen to maximum brightness, vibrate constantly and probably max-out the processor as much as I could.  Other supposedly “copycat” applications which have sprung up since, even tie-in the temperature sensor API (available on some devices) which would make such an application workable (i.e you can’t control what you can’t measure).

Also, in our development team any battery draining code is now said to be “taken from the Hand warmer app”.

Learnings:
Quite a lot actually…

I was able to write up the Market publishing process from end to end, with its capability’s, quirks and outright bugs.  This drove the direction of the company’s product publishing strategy (more in a later post).

Flurry is also a great (if legally dubious – again, more in a follow-up) tool for tracking your users.   I was able to deploy and track a real world deployment, before writing up recommendations for other platform teams (Flurry supports iPhone, Blackberry, etc.).

Flurry User Data

Look at my massive user base, giving stuff away for free on Android actually works (try that on JavaME or Series 60!).

User locations

Android is still a North America (read USA) based operation, which should change as more (and better) devices become available in the rest of the world.  This will be helped greatly if Google role-out their (currently quite limited) coverage for paid applications on the market.

Events

The interesting part here is that 2.2% of sessions ended without the user enabling that application.  That tells you how effective legal disclaimers (even nasty ones) are in real world settings.

Finally, I end with a promise to be publishing (and blogging) some of my *serious* applications in the near future.


Geo Visitors Map