ZEDRAY

Now most of the votes in the 2010 UK Election are in, we can now look past the media spin and take a detailed look at how the results were counted.  Raw data curtsey of BBC News.

Here are votes cast (i.e. popular vote) against seats gained in parliament.

The first question you might ask is why did Liberal Democrat supporters (like myself) lose 92 representatives?

This difference is caused by Britain’s First-past-the-post system which allows the incumbent to redraw constituency boundary’s for electoral gain in a process called Gerrymandering.  Looking at the next chart its obvious that both the big political party’s (Conservative and Labour) benefit greatly from this practice.

With the pitiful state of British democracy, its no wonder that 35% of the electorate didn’t vote.  This is the Elephant in the room that media and politicians don’t like to dwell on, because when you factor these people in, its clear to see no party received anything like a mandate to govern.

But who are the disenfranchised and why didn’t they vote?

• Lack of voter power
  Looking at the voter power index (excellent link), its clear that people living in marginal consistencies (i.e. people with real voter power) were 12% more likely to turn out to vote than those in the safest seats.  This is due to their greater influence on the national outcome, and the disproportionally large share of campaigning (ads, leaflets, canvassing, etc) that they will have subsequently received.
• Emigration
  With an electoral system so unresponsive to peoples needs (i.e. both main parties are pretty much aligned on important matters: high house prices, immigration, war, etc.), many people instead choose to vote with their feet and move abroad.  Unfortunately, government agency’s have some difficulty tracking inward migration, and have even fewer tools for detecting people who decide to leave.  Hence, I believe the generally reported figure (around 400,000 pa) vastly underestimates reality (mainly because myself and many expatiates I know are not included in that figure).
• Lack of choice
  Who do I vote for if I want troops out of Afghanistan, or to break up of the land monopolies that make Britain such a difficult place to work and live?  Why can’t I vote in favour of immigration controls, or even for the Green party?  Its difficult to quantify this, but if people were given a legitimate choice of who to vote for (or to stand for election themselves), then more people would turn out to vote.

This is why the Liberal Democrats must use their leverage in a hung parliament to force a deal on Proportional Representation, which would benefit the British electorate by allowing them to vote for who and what they like.

Follow up (9/5/2010)
Looking at the last 2005 election (despite how its been reported in the media), the Liberal Democrats took slightly more votes this time around (0.9% more) but managed to lose 5 seats.  Perhaps this election was really decided when the electoral commission redrew the boundary lines in 2006.

Suppose you’ve been asked to pre-load your application onto a forthcoming Android device, so that end users will see your handy work on the Home Screen as soon as they start-up the device.  This means excellent placement for your application an extra selling point for the device (i.e. your application can be shown on the product marketing!).

First off, lets forget about including your actual application, as it’ll take ages for your software to be approved by an operator, be embedded by the firmware developers, pass QA, ship, then sit around in a storeroom before being finally sold to a customer.  By this time, your development team will have published a much improved version of your application onto the Android Market.

No, what you need is a so called “Market-Stub” application that will direct your new customer straight to your application on the Android Market.  The added benefit of this, is that applications downloaded by the user in this way are automatically registered with the Android Market application, allowing it to take care of future upgrades on your behalf.  Of course, if you still want your application to work out of the box (and for customers fussy about their internet connections) you can integrate the MarketStub into your existing application and periodically prompt the user to upgrade (no matter how annoying this might be).

First off, all this code is open sourced in my GitHub repository:
http://github.com/zedray/Android-Market-Stub-Application

Iteration one:
Create a project with a single activity that points to the given Application name space using its Android Market URL (using the Hand Warmer as an example).  This URL will go directly to the application’s Details screen, bypassing any Search UI and saving the user one click (see documentation).

public class HandWarmer extends Activity {
private static final Uri TARGET_URI =
Uri.parse("market://details?id=com.zedray.handwarmer");

@Override
public final void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
startActivity(new Intent(Intent.ACTION_VIEW, TARGET_URI));
finish();
}
}

Criticism #1 Activity Intent path issue:
Its a known issue with older Android Home Screens (<1.6) and those based on it (HTC Sense, etc.) that short cut icons are not updated with the application (i.e. the Home Screen does not listen for the ACTION_PACKAGE_CHANGED intent).  This means you should ensure that the entry point activity for your Stub application (which is cached by the Home Screen) is exactly the same in your new application, and that you don't change it at some point in the future (watch out for this during refactoring).  If the cached activity path is different, your customer will see a "This application is no longer installed" Toast error when trying to run your newly installed application via the Home Screen, although it will still work fine if they run it via the application list menu.

Criticism #2 Task History issue:
Because of the way Android works, if the user presses the “Home” button to leave the Market Details screen they will inadvertently leave this Activity on top of the Activity Stack for your application.  That means that once your application finishes installing in the background, the user will try and run it by clicking on its icon and will instead be taken to the top of the Activity Stack, i.e. back to the Market Details screen.  This is confusing for the user, as they will now have to press the “Launch” button at the bottom of screen to proceed to the newly installed Application.

Iteration two:
This time add the FLAG_ACTIVITY_NEW_TASK flag to the Android Market intent.  This will push the user into a new stack, and prevent them having to return to the Android Market Details screen when starting the application for the first time.

startActivity(new Intent(Intent.ACTION_VIEW, TARGET_URI)
.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK));

Be sure to contribute any improvements to the open source code base.

Android is hotting up in the marketplace, and the Berlin DroidCon conference program is looking interesting this year.  Particularity as I will be presenting some research on Android application architecture and demoing a bit of source code.

Architecture your Android Application (30 minutes)
How should you structure your Android application? What components do you use (Activity, Service, Application) and how do you communicate between them (Binders, Handlers, RPC)? I will talk about how you can manage the different life-cycles of your components, share some experiences and show some code.

DroidCon, Seminaris Campus (Dahlem Cube), Berlin, Donnerstag, 27. Mai 2010.

UPDATE: I will also be attending the BarCamp on the 26th of May, so if anyone would like to suggest a topic for me to talk about let me know in the comments section.

The first thing my girlfriend asked when I handed her an Android phone was “how do I make a call with that?”  This is from someone familiar with the candy bar form factor with the ubiquitous green (call) and red (hangup) hardware call buttons (and no interest in finding the “phone app” on a busy home screen).

In the quest to make form factors with fewer buttons (i.e. more iPhone like), the device manufacturers have seen fit to remove calling buttons from their hardware and instead rely on software buttons integrated into the on-screen UI.  This is something typical of the second wave of Android phones (higher pixel density, 1.6 or above, etc.) that we have seen come out of late.

This got me thinking about what sort of phone-like use cases the home screen should be trying to fulfil.  The most useful being when the user returns to their phone after some time (or just a moment) and wants to see the current state of the call history.  Coincidentally, this is information you can already see under the “Call Log” tab, which (strangely) is around 2-3 clicks away from the user as Google did not include a short-cut for this screen.

Simple use cases for a “Call Log” Widget:

• Who called last? (include their name, phone number, how long ago they called)
• Did I miss an incoming call? (show if a call was incoming, outgoing or missed)
• One click to show more info (i.e. a short cut to call log screen, or should this go directly to the relevant contact?).
• One click to return the call (actually this should be two clicks to make it harder to call someone by accident)
• Align with UI of native widgets (i.e. keep it black and shiny on my Nexus)

Hence, I present the “Call Log Widget” for Android 1.5 or above.  This is by far the most useful widget on my home screen, and a nice visible platform on which I can add more “phone-like” features to the interface.

Your feedback is very much appreciated.

Android Market link (Android devices only)

The solution for the “Using Flurry with a Android Home Screen Widget” problem was to move over to using Google as an analytics provider.  This works because Google has kindly provided a dispatch() method in their API, so developers can choose exactly when the library should start reporting back to the server.

This is intended for developers wanting to optimise their network traffic, but in my case I can now spool up a new service from which to call the dispatch method.  Using a new Service context results in the library having sufficient time to complete its data transfer, without falling foul of the limited lifespan of the BroadcastReceiver life-cycle.

Interesting comment in this weeks bugle about the way electoral lines are drawn in the UK and how they favour a labour majority.  Here is a model showing Labour getting an 8 seat majority (largest party by 109 seats) from an even split of the popular vote (see Gerrymandering).  As usual for a UK election I expect the complacently party to win my a mile.

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.

“Insurance, security or extortion? The US is spending millions of dollars in Afghanistan to ensure its supply convoys get through – and it’s the Taliban who profit” (Guardian).

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