ZEDRAY

“You did well on Twitter…” was the first thing I heard after taking absolutely no questions from a room packed with Android developers.

They had come to hear a real Android developer actually talk about Android development, as opposed to push some product or service (all the real developers were at yesterdays BarCamp).  I wasn’t trying to sell them anything, other than cram the benefit of several years of Android experience into the twenty minute attention span of the average conference attendee.

I had the slides (OpenOffice impress, not PowerPoint), I had source code (open on GitHub of course) and even an app on the market they could download while I demoed my framework on stage.

My plan was to keep it simple.  Concentrate on the hardest, and ironically most basic parts of the platform (i.e. keeping components with different life cycles held together), show where people often go wrong (service leakage, unnecessary RPC, etc), and top it off with a working demo for them to take away and learn from.

My greatest fear was for someone at the Google I/O (which I couldn’t attend) to have covered the same topic, or worse having recommended something contradictory (still waiting for Google to put those session videos up).  Additionally, a part of me kept wondering if someone was going to stand up and shout Balderdash (or some German equivalent) as I made my most bold claims and controversial recommendations.

But on the other hand, in the weeks I had to prepare the main slides (after finishing the framework code), I realised that I was going to be able to demo a bunch of things people normally don’t think about while developing.

Things like:

• How should your Service update your UI?
• When do you end your app?
• How do you make your app come back from the dead after your process has been killed?

I had turned up twenty minutes early to turn my development laptop onto a presentation machine (I knew the Dell/Windows XP/NIVIDA drivers would start fighting each other for control as soon as I plugged in the projector).  I set up my laptop screen orientation (no daylight glare), resolution (medium), projector (clone mode), brightness (full), Android emulator (correctly sized to fit the screen), mic (a nice wireless wraparound model provided by the technician) and tried out a cool little Logitech laser pointer/slide controller gizmo that (somewhat surprisingly) worked with OpenOffice as soon as I plugged the USB dongle into my machine.

It helped that I had tested my slides out on the same projector that same morning, and realised that my original colour scheme made the component diagrams illegible.  An issue easily solved during the days welcome keynote.

I checked the clock, and realised that I was ready with five minutes to spare (much better than trying to set up with everybody watching).  So I put the title slide up and sat down in the front row, looking over my equipment as the room began to fill.

I calmed my nerves by breathing slow and thinking through my main points, before someone politely asked me to vacate my seat.  Standing up, I turned around to see a packed room, with people shuffling around in the isles, and newcomers starting to chose their places on the floor.

Around now, it dawned on the organiser that the allocation of a “small” hundred seater room was going to be somewhat inadequate.  Instead of disrupting other parts of the conference, the moderator apologised to the room and opened up the double doors so people could watch from the corridor.

By my reckoning, there must have been north of a hundred and eighty people trying to watch in a room designed for half as many (I only found out later that some of my colleges had been turned away), which meant as I spoke I could taste the moisture in the air.

I kept calm, and walked the audience through my slides, skipped through some of the code examples  (20 minutes is not much time) and ran the framework demo with whatever time was left over.  The demo worked flawlessly, which I considered to be lucky as better men then me had seen their demo’s die that day (not needing a working internet connection always helps).

Surprisingly, when it was all finished no one put their hand up to ask a question.  Instead I was greeted by the sound of people quietly shuffling away to make changes to their apps.  Above all, developers don’t like to look stupid compromise their ego in front of their peers.

Presentation of “Architecture your Android Application” DroidCon 2010 are on Slide share, source code on GitHub, demo on the Market.

Oh, and that Twitter feed:

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.