Android Developer Challenge Critique
[img_assist|nid=3462|title=|desc=|link=none|align=right|width=128|height=96]At the risk of sounding like a sore loser (who wouldn’t be, after missing out on $25,000) and ignoring for a moment the shortcomings of my own application (of which I am intimately aware), I am going to discuss the limitations of the ADC itself.
As I understand it, by holding the ADC Google was trying to achieve the following:
(a) Stimulate the development of innovative applications that build upon novel Android specific capabilities (openness, interconnectivity, Google services, mapping, etc).
(b) Generate cool looking applications that can be shown to the media now, and eventually be used to help sell Android phones.
(c) Create a community of developers to test and provide feedback on the Android operating system (which is still very much a work in progress).
(d) Quantify the size of the Android development community, so the platform can’t be written off as insignificant fragmentation by the more established development platforms (i.e. Symbian, JavaME and iPhone).
I think we can all agree that the ADC succeeded in meeting and exceeding all of these goals.
However, I think many developers (some of whom are seasoned mobile industry experts themselves) had an extra goal in mind when the signed up for the challenge:
(e) Develop applications that go above and beyond what is currently possible, and make them work in the real world.
By going through the winners, I think many observers (some less impartial that others) have noticed that in many cases Google really tripped up on this last one. In my opinion, despite putting a lot of work into building an objective, fast and fair judging process - the competition contained some fundamental flaws:
- Some of the Judges weren’t industry experts, and few had sufficient time to examine each entry in sufficient depth. This would have benefited applications with quick workflows and flashy interfaces.
- Lack of emulator support for crucial functions (camera, voice, accelerometer, etc) and no flexibility in the judging hardware. Criteria that effectively disqualified some of the more technically competent entrants (i.e. Enkin).
- The practice of simulating GPS data was effectively a huge bias towards apps focused around location based services, allowing them to ignore how issues like cold start fix, battery drain and lack of signal would kill many of these applications workflows (more on this issue later). Again, industry experts would have pointed these flaws out when they were applicable.
- Anyone who submitted an application framework, development tool or (dare I say it) a mobile positioning platform, was wasting their time.
Hence the ADC wasn’t about building a product that would work in the marketplace, but about appeasing the varying tastes of the evaluating judges. Some of which become quite clear when you go through the winners:
- How did three disaster preparedness apps (Em-Radar, FreeFamulyWatch, Lready Emergency Manager) get through the first cut?
- No social networking application should rely (or be based around) features only available on exclusive handsets.
- An app for taking pictures of whiteboards (Jigsaw), with automatic geometric orientation. My camera has that feature, and it’s like 3 years old?
- No location-less games. Games are an important driver of mobile handset technology and an application market in their own right. OmniGSoft ported over some high quality 3D games to Android that seemed to set the standard in this area.
- The Barcode reader (AndroidScan) and Iris scanning (BioWallet) applications look cool and serve as examples of how developers made innovative applications despite Android limitations. Without camera support in the current SDK, developers found that they could connect their web cams to a running emulator via an IP interface - Kudos to them. Luckily, this innovation was simple enough to get past ADC rules and be passed on to the judges.
A word on location…
Many of the winners built applications based on *positioning* or so called Location Based Services, which is an area I know a thing or two about.
Despite years of high expectations, industry promises and optimistic articles in the media, LBS haven’t managed to take off outside of Navigation. Contrary to popular belief, this isn’t because of a lack of hardware or well written applications (everyone and their grandma owns a Nokia N95 with built in GPS these days), but because of fundamental limitations of the technology itself.
Currently the simplest and most accurate way of positioning a mobile phone is via an inbuilt GPS receiver. Assuming for the moment, that all forthcoming Android phones will support GPS (they will have to if these winners are anything to go by) then a typical first experience might look like this:
Guy - “Hey, I’ve just installed an application that will show us the weather for our exact location”
Girl - “Cool, show me”
-Runs application-Application says “Searching for GPS Signal”
-Both wait for 2-3 minutes-
Application says “No GPS Signal found, are you indoors?”
Guy - “Maybe we should stand outside?”
-Both standing outside, guy restarts the GPS search-
-2 minutes of “Searching for Satellites” later-
Guy - “I can’t get a good signal on this thing, maybe it’s all these buildings?”
Girl - “Never mind, I think it’s just about to start raining anyway”
Let’s look at another commonly used Android feature:
Here are all your buddies running around, each with an Android phone running the same social networking client, each returning their current position based on GPS via a true peer-to-peer XMPP (or GoogleTalk) request.
- How many of these users will get GPS coverage while they are at home, at work, school or simply having their phones sitting in their pocket.
- Would you keep an application running on your phone if it meant your phone battery only lasted 6 hours*?
GPS is the wrong solution for many kinds of consumer applications where the user wants to get at information quickly and with minimum hassle. That’s not to say LBS are unworkable, as in many situations a position based on the current Cell ID provides good enough accuracy (e.g. you are in New York, here in the weather for New York).
Google has a “secret” (and probably the best) API for converting Cell ID information to position coordinates. They are reportedly having “no plans to release it”, and even if they do I wouldn’t want to invest in a company whose product is totally reliant on the good will of Google.
The desire to do better than Cell ID drove me to invent the Snowball platform, but that’s a topic for another post.
“Basically, you’re right, those problems exist and, for example, Commandro has some tricks inside it in order to correctly respond to missing signals, as well as it can be run as a background service (without UI at all) with minimal and rare GPS interaction in order to
keep saving battery.” - Alex Pisarev
Again this turns into a critique of the challenge, i.e. entries that implement intelligent workarounds are totally transparent to the judges.
Summary of points:
- Yes GPS technology will get better, but don’t expect a dramatic performance improvement within the next 3 years.
- Some of the winners used a background service (and other unspecified tricks) to achieve better performance, lower battery consumption and an overall better user experience.
- Intelligent LBS support needs to be baked into the platform, i.e. you shouldn’t have 5 background applications on your phone all attempting to do the same thing. Snowball is my attempt to make this work. I can’t wait to get my hands on real hardware to show what it can do.
If you worked hard and didn’t win the ADC take heart: there are many other platforms out there just begging for your support, and maybe in a few years there will be enough Android handsets on the street to make it worthy of your attention once again.
Also, if you fancy working in the green fields of northern Germany, we’re always looking for talented developers here at OpenKnowledge.
* Measurement based on N95 tracking performance