dw2

15 August 2010

Co-existing with Android

Filed under: Android, Nokia — David Wood @ 9:51 pm

For some time, I’ve wanted to learn more about Android.

Not just theory, or second hand knowledge.  I wanted my own, direct, practical knowledge – obtained by using an Android device “in anger” (as the saying goes).

Playing with a device for a few minutes – for example, at a trade show – fails to convey many of the real-world strengths and weaknesses of that device.  But it’s the real-world strengths and weaknesses that I want to experience.

It’s important for me for work reasonsAccenture Embedded Mobility Services are involved in a stream of different Android projects.  (Among other things, I want to be able to install and use various experimental Android apps that some of my colleagues have been writing.)

It’s also important for me for personal productivity reasons.  If an Android phone turns out to be a smarter phone than any I’ve been using so far, I want to know about it – so I can use it more often, and become a smarter person as a result.

But there are sooo many Android devices.  Carphone Warehouse had a large selection to choose between.  For a while, I struggled to decide which one to pick.

In the end, I chose a Nexus One.  That’s because it is the device most likely to be quickly updated to whatever the latest version of Android is.  (Other Android phones include customisation layers from device manufacturers, which seem to need to be re-done – and painstakingly re-tested – whenever there’s a new Android version.  Unsurprisingly, that introduces a delay.)

For help with a Nexus One, I owe a big debt of gratitude to Kenton Price of Little Fluffy Toys Ltd.  I first met Kenton at a recent meeting of the London GTUG (Google Technology Users Group), where we both listened to Google’s Wesley Chun give an upbeat, interesting talk about Google App Engine.  Later that evening, we got talking.  A few days afterwards, Little Fluffy Toys became famous, on account of widespread publicity for their very timely London Cycle Hire Widget.  Kenton & I exchanged a few more emails, and the outcome was that we met in a coffee shop next to the Accenture building in Old Bailey.  Kenton kindly leant me a Nexus One for a few weeks, for me to find out how I get on with it.  Just as important, Kenton quickly showed me a whole raft of fascinating things that the device could do.

But then I got cold feet.  Did I really want to stop using the Nokia E72, which has been my “third brain” for the best part of a year? My fingers have learned all kinds of quick, useful methods for me to get the best out of this device.  (Many of these methods are descendents of usage patterns from even earlier devices in the same general family, including the E71 and the E61i.)  I also heard from many people that the battery life on the Nexus One was poor.  What’s more, during the very first proper phone call I did with this phone, the person at the other end told me several times “you’re breaking up – I can’t hear you”.  (Of course, a sample size of one proves nothing.)

It was the transfer of all my “phonebook contacts” from the E72, to be merged (apparently) with my email contacts on the Nexus One, that gave me even more reason to hesitate.  I wasn’t sure I was ready for that kind of potential restructuring of my personal data.

So I’ve compromised.  I already have two SIMs.  One lives in my E72, and the other usually sits inside my laptop.  Well, I’ve taken the SIM from the laptop and put it into the Nexus One.  For the time being, I’ll keep using the E72 for phone calls and text messages.  And probably for lots more too.  But I’ll use the Nexus One for lots of interesting experiments.  (Like showing friends and family members Google Goggles…).

I expect this usage pattern will change over the weeks ahead.  Let’s see how things evolve!

Earlier this evening, I used my E72 to take the following picture of the Nexus One perched next to my “second brain” – my Psion Series 5mx.  Hmm, that Nexus One battery indicator does look worryingly low.  (Maybe I should turn down the screen brightness…)

10 February 2010

The mobile multitasking advantage

Filed under: Android, Psion, applications, architecture, iPhone, multitasking, universities — David Wood @ 11:48 am

How important is it for a mobile device to support background multitasking?

Specifically, how important is it that users can install, onto the device, applications which will continue to run well in background whilst the user is simultaneously using the device for another purpose?

Humans are multitasking creatures.  We get involved in many activities simultaneously: listening to music, browsing the web, holding conversations, taking notes, staying on the alert for interruptions… – so shouldn’t our mobile devices support this model of working?

One argument is that this feature is not important.  That’s because the Apple iPhone fails to offer it, and the sales of the iPhone don’t seem to have suffered as a result.  The applications built into the iPhone continue to operate in background, but downloaded apps don’t.  iPhone apps continue to sell well.  Conclusion: mobile multitasking has little importance in the real world.  Right?

But that’s a weak argument.  Customer sentiment can change.  If users start talking about use cases which the iPhone fails to support – and which other smartphones support well – then public perception of the fitness of the iPhone system software could suffer a significant downturn.  (“iPhone apps – they’re so 2009…”)

How about Android?  That offers background multitasking.  But does it do it well?

My former colleague Brendan Donegan has been putting an Android phone to serious use, and has noticed some problems in how it works.  He has reported his findings in a series of tweets:

I say, with all honesty that Android’s multitasking is a huge travesty. Doesn’t even deserve to be called that

Poor prioritisation of tasks. Exemplar use-case – Spotify [music playing app] + camera

Spotify will jitter and the photo will be taken out of sync with flash, giving a whited out image

Symbian of course handles the same use case flawlessly

Android really is just not up to doing more than one ‘intensive’ task at a time

Even the [built-in] Android music player skips when taking a photo

(Brendan has some positive remarks about his Android phone too, by the way.)

Mark Wilcox suggests a diagnosis:

sounds like the non-real-time, high interrupt latency on Linux is causing some problems in multimedia use cases

Personally, I find this discussion fascinating – on both an architecture level and a usability level.  I see a whole series of questions that need answers:

  1. Are these results applicable just to one Android phone, or are they intrinsic to the whole platform?
  2. Could these problems be fixed by fairly simple software modifications, or are they more deeply rooted?
  3. How do other mobile platforms handle similar use cases?  What about feature phone platforms?
  4. How important is the use case of playing music in background, while taking a photograph?  Are there other use cases that could come to be seen as more significant?

Perhaps this is a good topic for a university research project.  Any takers?

(Related to this, it would be interesting to know more about the background processing abilities of modern feature phones.  For example, it used to be the case that some feature phones would discard the contents of partially written text messages if there was an incoming voice call.  Has anyone looked into this recently?)

Regardless of the merits of these particular use cases, I am convinced that software responsiveness is important.  If the software system is tied up attending to task A when I want it to do task B, I’m frustrated.  I don’t think I’m alone in this feeling.

My 1990′s Psion PDA typically runs more than a dozen apps in parallel (several word processors, spreadsheeets, databases, plus an individual agenda, tube map app, calculator, and so on) and switches instantly between them.  That sets my baseline expectation.

Here’s another mobile use case that’s on my mind a lot these days.  It applies, not to a PDA or mobile phone, but to my laptop.  It’s not (I think) a device problem, but a wider system problem, involving network connectivity:

  • I frequently find myself in mobile situations where I’m browsing websites on my laptop (for example, on the train), and the pages take ages to load;
  • The signal indicator on the built-in wireless modem app says there’s a strong signal, but for some reason, wireless traffic is squeezed;
  • I sit watching empty tabs on my Firefox browser, waiting and waiting and waiting for content to appear;
  • In frustration, I’ll often open another tab, and try to visit the BBC website – to rule out the possibility that the server for the other web pages(s) has gone down – but that gives me another blank page;
  • Eventually, things recover, but in the meantime, I’ve been left twiddling my thumbs.

When I switch to a WiFi connection instead of a cellular connection, things are usually better – though I’ve had the same bitter experience with some WiFi hotspots too (for example, in some Starbucks coffee shops).

So what should the highest priority be for system architects to optimise?  Responsiveness comes high on my own wishlist.  I recognise that this will often require changes in several parts of the software system.

23 June 2008

Fragmentation is easy, integration is hard

Filed under: Android, fragmentation, integration — David Wood @ 2:13 pm

The Wall Street Journal reports today that “Google’s Mobile-Handset Plans Are Slowed“. The Inquirer picks up the story and adds a few choice morsels of its own: “Depressing news as Google’s Android delayed“:

However, life’s little crises just kept getting the Android down and now apparently some mobile network operators like Sprint Nextel, have abandoned any attempt to get an Android on the market until 2009. This is purportedly because the majority of Google’s attention and resources have been going to Sprint’s competitor T-Mobile USA, who still hope to have an Android mobile out by the end of Q4. We have it on good authority (from un-named sources of course) that Sprint actually asked Google “Do you want me to sit in the corner and rust, or just fall apart where I’m standing?”…

Director of mobile platforms at Google, Andy Rubin, gloomily noted that trying to develop software while the company’s irritating partners kept pushing for new features, was a time-consuming task. “This is where the pain happens”, he sighed.

I recognise this pain. It’s something that has occurred many times during Symbian’s history. That’s why I’ve emphasised a dilemma facing Android: Fragmentation is easy, but integration is hard. Coping with multiple forceful customers at the same time, while your codebase is still immature, is a really tough challenge. Glitzy demos of v2 features don’t help matters: they drive up interest that needs to be deflated, as you have to explain to customers that, no, these features aren’t ready to include in the software package for their next phones, despite looking brilliant on YouTube. Instead, the focus needs to go on the hard, hard task of integration.

Blog at WordPress.com.