ZEDRAY

Flurry is a great tool for tracking the users of your mobile application, producing the sort of data visualisation that makes marketing men smile with glee.  Unfortunately, I have discovered that the Android API is good for monitoring usage of Android Activities, but not suited for tracking Android Home Screen Widgets.

The main issue here is that Widgets have a very different (i.e. much longer) life-cycle.  For Activities, Flurry documentation recommends tying into the “onStart” and “onStop” life cycle methods, which provide a clear mapping with the creation and subsequent deletion of a given Activity context.

For widgets it’s a little more complicated.  What you want to do it tap into the “onEnabled” and “onDisabled” life-cycle methods, so you know how long at least one of your widgets has been installed on the home screen.  The problem here is that the widget does not maintain the same context between these two calls, and (if well designed) shouldn’t spend much time being in memory at all.

Take for example a Clock widget, which is triggered repeatedly by an AlarmManager intent and manages to update its UI within the short permitted time span of a BroadcastReceiver.  This is extremely efficient from a saving battery perspective(AlarmManager can be configured not to wake up the device), but gives Flurry no scope to maintain a session, or report back usage data over the network (I have no idea how Flurry have implemented this functionality?).

Hence I am seeing incorrect session length values in my Flurry reports, i.e. Flurry is reporting 3-10 seconds (probably the time it takes to initialise my widget) and not the time the widget spends being shown on the home screen (in this example several days).

Unfortunately Flurry have locked down their own forums, and are not returning my support emails.
Does anyone know if this kind of tracking is this possible?  Would it help if I spun up a service or cached the context (i.e. leak some memory)?  As Flurry reports are delayed, this is very difficult to debug.  Could anyone suggest another usage tracking tool that supports Android Home screen widgets?

Posted on Android Developers forum.

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.**

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.

State: Off

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

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).

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.

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

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.).

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

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.

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.

A code contained in a Data SMS is required to authenticate the MSISDN of the device running my product.

When I receive a data SMS on the Samsung Galaxy, the Intent “android.intent.action.DATA_SMS_RECEIVED” is not thrown and the Data SMS arrives in the Inbox as a blank text message.  Any data contained in the Data SMS seems to be lost once it arrives in the Inbox.

Here is a little app I wrote which detects the MSISDN (not working on many devices) or lets you enter it, then send either a Data SMS or a Text Message.  The app will then display any incoming Data or Text SMSs by the intent they throw and allow you to interrogate the native Inbox to determine what data was saved.

Time to file a bug!

Bug Report
Forum

The original Android phone, which came shipped with Android version 1.0 but promptly performed a seamless self update to Cupcake after I took it out of the box and connected it to the internet for the first time.

This device is only interesting for testing (post Cupcake) because it has a hardware keyboard which by default will restart the running Activity every time you flip it out.  This uses a slightly different event notification system to the rotate listener, which is the only way of changing screen orientation on the other 3 Cupcake devices.  The hardware keyboard makes it currently the best available Android phone for writing messages, but the retarded amount of on board memory means you must start deleting stuff after downloading your tenth application.

A lot of developers have a “Android Developer Phone 1” device (now out of stock) which is essentially a pre-rooted HTC Dream, giving developers full Linux level access so they can install their own firmware.

Please note, that a rooted phone is not required if you are only intending to develop Application level software, as any Android device will run a self signed application as long as you check “Unknown Sources” in Menu > Settings > Application settings.

There is no 3.5 audio jack on this device, instead use the ExtUSB connector with the headset provided.  Some editions of this device come with a 3.5 headset and ExtUSB adapter, allowing users to use their own headphones to listen to music.

Device specific test cases:

• Flip out that keyboard a couple of times on each screen.  Badly written applications will lose UI state (form data, selected tabs, etc), or freeze if they are in the middle of a long running process started from within the Activity (consider using a service in this case).
• Try and perform all actions using the keyboard (as if the touch screen were broken).
• Test for trackball slide clicks (i.e. when the user mistakenly presses the trackball when they intended to slide it).  The proper way of handling this is to ignore all trackball clicks that occur less than half a second after a trackball drag.  This test is useful for games that implement trackball events themselves, as we are used to the native Android UI handling this on our behalf.
• Flash your Developer Phone firmware and test your Application on an early build of Donut.

This is a review of all the mobile phones currently being sold (outside of China) that run Android Cupcake.  I am an Android Third party Application developer (i.e. not a Google employee or handset manufacturer) and will be reviewing various technical differences that affect developers like myself.

With the late arrival of the Samsung Galaxy, I now finally have the full set to play with.

The Samsung Galaxy comes in a bigger box because it comes with a “PC Studio” and drivers CD.  You shouldn’t need a CD to develop on an Android device, because the ADB and USB drivers are included with the Android SDK (more on this in the Galaxy review).

Comparison table:

Additional information, including unrelased devices is avalaible here (documented by Eric Wong).

Comparison notes:
All devices have roughly a 3.2” HVGA (480×320 pixcel) capacitance touch display, support 3G, WiFi, GPS, Bluetooth, accelerometer, digital compass and Micro-SD memory cards.   Only the HTC Dream and HTC Magic are Google experience phones which support automatic updates, the others instead come bundled with software customisations (both good and bad) developed independently by their respective manufactures.

Internal storage
Currently applications cannot be run off the SD Card (unless you have root access), and I don’t expect this situation to change any time soon.  That means the internal phone storage represents the upper limit on how many applications (including contacts/mail/calendar storage & Web Browser cache) that you can install on your phone.

The Samsung Galaxy’s ~6.7GB internal SD card isn’t included here, because you can’t install Applications onto it.

If you have less than 10MB of space remaining, you will get a low space notification and all synchronisation tasks will stop.  To find out this value for your device, look in the device settings:
Menu > Settings > SD Card & phone storage
Look for “Available space” under the “Internal phone storage” header.

All these values are for a fresh device (i.e. reset to the factory settings) and are running a similar retail Cupcake build.  Your results may vary.

Camera
More Mega-pixels usually denotes a better result, but having a flash is important when taking pictures indoors.

Battery
Bigger the better really.  Android background processes can eat up a lot of juice, but us software developers are working on improving this situation.  Actual battery life was not tested.

Connector
MicroUSB is the new standard (according to the EU), so get ready to replace all your chargers and connection cables once again.  All the HTC devices use the ExtUSB which is a proprietary connector is apparently under some debate.  Also, don’t confuse this with the older Mini USB which you probably already have chargers for, as these will also have to go into the bin.

Keyboard
Cupcake comes with a usable on screen software keyboard, which makes it possible to type one handed with your thumb.  This works quite well as long as you remember that you only type a character when you *remove* your finger from the screen.  This makes accurate typing a click, and then drag affair.

The HTC Dream comes with a flip out keyboard (for use in landscape mode), with a good key layout design but effectively requires two hands to use (i.e. typing with your thumbs).  This is much better for data entry, as you get some good tactile feedback from the keys, and the lack of soft keyboard leaves you with more screen real estate for your application.

Controller
For all practical usages, the click ball and the D-pad are identical.  I am yet to test if this makes any difference to Android game play.

OpenGL
All  the HTC devices come with OpenGL hardware “acceleration”, i.e. calculations are performed on a separate GPU chip.  The same code is implemented in software on the Galaxy, meaning that animations run proportionally slower (compared to processor speed) on this device than you would expect, and there is more animation judder when the processor is asked to perform other tasks.

While this isn’t a big issue today, I expect to see greater use if OpenGL in Games and user interfaces  in the coming year.  A good example  of what to expect would be the Rachael UI prototype from Sony Ericsson.

SD Card
Its nice when the device comes with a decent SD card, although only some applications will make use of this space.

Upgrade
Android is quite new, so new revisions and security fixes are coming out all the time and you want to make sure you are using the latest build.  Google experience devices will upgrade themselves, but it’s a bit unclear at this point how (and how often) non-Google experience devices will be upgraded.

The HTC Hero and Samsung Galaxy currently require PC software to download and install their latest updates.  I expect that most users wont bother (or know how) to upgrade, so Application developers should expect to support Cupcake devices for many years to come.  I will call these devices “Dead Ducks” until someone comes up with a seamless way of bringing everybody over to Donut, then Éclair, etc.

This is one area where owning a Google experience “in the cloud” Android device is advantageous, and I wouldn’t recommend any of the other devices until this issue has been resolved.

Screen
Physical screen display area of the device, measured with a ruler.

Edit
The virtual keyboard is essential, but uses up a lot of on screen real estate that your application must take into consideration.  Surprisingly this size varies considerably between firmware customisations, with the Samsung Galaxy using the greatest space with its oversized keyboard.  HTC Dream users have the option of flipping out their physical keyboards, nullifying this limitation.

I have measured the amount of usable on screen pixels available when the virtual keyboard is shown in portrait mode. This is the distance between the top of the virtual keyboard and the bottom of the on screen notification bar.  Fewer pixels means there is a larger virtual keyboard, but conversely, there is less area for your application to display data in.

Individual device reviews to come…

So you have a T-Mobile G1 running the Android 1.1 firmware, but you don’t have a T-Mobile SIM.  This means you can’t get past the Google Account sign in screen because you don’t have internet access.

Unfortunately you can’t yet access the phone settings to activate WiFi, so the only way to progress is to manually enter an “Access Point Name” configuration for your third party SIM.

Menu > APN Settings
Menu > New APN

Enter the APN settings for your current network.  This is easy if you happen to have another phone lying about, so you can boot it using your third party SIM and scribble down the settings of a relevant APN.

The official instructions for using your Android phone for development are here:
http://developer.android.com/guide/developing/device.html

So you plugged your Android phone into your Windows machine having forgotten to switch on USB debugging…
Menu > Settings > Applications > Development > USB debugging

Then Windows detected your device as a USB-Mass storage device and won’t change the settings, regardless of how many times you uninstalled the device. Thread on it here.

This solution worked for me and didn’t require editing the registry settings (I don’t know if the reboot is unnecessary).

(1) Plugin phone
(2) Uninstall any drivers that mention “HTC Android Mobile USB Device”
(3) Unplug phone and restart
(4) Install and run USBDeview
http://www.nirsoft.net/utils/usb_devices_view.html
(5) Using USBDeview find the Android device (for some reason Windows hides uninstalled drivers instead of deleting them), right click on it and uninstall.
(6) Follow the official instructions to the letter this time.
http://developer.android.com/guide/developing/device.html

Happy developing.

…I here by declare that I have not developed, sold or distributed applications or services over the Android Market and Google checkout payment system.  Please do not begin an investigation into my activities, as I am mealy a hard working bunny who only manages to file his German tax explanation forms on a semi-annual basis.  Please do not crush my dreams under weight of bureaucracy and threat of criminal prosecution.
Mark

[RANT]
It turns out that selling applications over the Android market seems to be a sure fire way of getting myself investigated by the tax man (all of them, not just the German one apparently).

Developers are required to set the sales-tax rate for the local where the customer is buying.  That means customising the correct rate for every state in the US (and individual city’s apparently), European country, province of Zanzibar, etc.  I do not happen to know the tax rate in California, and I expect that nobody would inform me if it were to change the day after I entered it manually into the Market web page.  Developers are not international tax experts, and Google have abdicated their responsibility by charging a blanket ~30% “carrier tax” without taking responsibility for Tax processing itself.

I can hear the sound of iPhone developers (who have this taken care of for them) laughing at us right now.
[/RANT]

P.S. Here’s an idea, how about Google do a *Tax* session at their Google I/O conference?

Some relevant links:
[Question: Legally, is the developer selling the app or is Android Market selling it to end user?]
[Campaign: Android Developers International & Tax Consultation]
[Question: Do I need company to sell applications?]
[MARKET QUESTION: Selling applications on the Google Market]
[MARKET QUESTION: Selling applications on the Google Market]

I realised today that I am probably the only Android developer NOT to have a book out at the moment.