Mike “I’m-English-I’ve-brought-my-passport-to-prove-it” Jennings gave a lovely and informative presentation on his new Android handset, which he kindly demoed during the keynote speech but subsequently refused to take out of his pocket during the rest of the day.

Apparently Mike only got authorisation to show this phone in the last 2-3 days, with this being the first time the device has officially been shown in Europe (thanks guys).  Apart from the keynote at the beginning of the day, no one was allowed to view the device close up.

A few notes taken from where I was sitting:

• It’s black (not white only, as some overzealous bloggers had feared)
• Supports Wi-Fi and 3g (or is that 3G?)
• The brand and operator logo were taped out, although logo size and phone form factor would be consistent with the HTC/T-mobile/‘Dream’ device we have already seen.  It appears Mike was trying not to steal the wind from next weeks *official* device launch.
• All Android devices will have GPS (although this will not be compulsory), but no GPS demo was possible as the device couldn’t get a signal under the Wembley conference hall.  Kudos however goes to Google Maps for automatically switching over to cell-id (or is that Wi-Fi) based position information (and visualisation).  It would be interesting to know if this was a feature of Google Maps for Android, or something baked into the platform.  As discussed before, this kind of position approximation will be vital for all those location based social applications we have been promised.
• Mike demoed an accelerator app called blue dot, similar to the Nokia bouncing ball.
• Web browsing was in landscape mode, not portrait, although Mike didn’t choose to demo the slide out keyboard for us.
• Ironically Mike didn’t demo an actual phone call, even when prompted.  His explanation was that he only had a data SIM card in the phone.  To date, I have never seen any Android voice, audio, or text to speech capabilities, which is a situation oddly reminiscent of the old iPhone release joke.

Mike spent the rest of the morning making the most out of his public relations training, as he faced a tough audience hungry for meaty technical details.  Having to field the now obligatory-at-Android-pre-release-conferences “Operators are bastards” question (actual quotation) and taking it in his stride.

Video now on youtube

What made the event was the free food, friendly presenters and the chance to make some quality Android contacts.  Highlights being Mike “I’m-not-an-American-I’m-Canadian-with-a-British-passport” Jennings’s Android keynote/device demo/Q&A, meeting some up and coming Android consultants from novoda.com and a rather solid discussion on application traceability with alsutton.com.

A note also goes to Reto Meier who is writing (or frantically updating for 0.9) his book titled: “Professional Android Applications”.  By the sounds of things, the book will definitely be worth a read and made for a good excuse for the speaker to pick on the author while fielding some of the more technical questions.

Unfortunately I only got to *watch* the lightning talks, and not demo Snowball as I had already upgraded my laptop to Android SDK 0.9 and hadn’t had time to bring all my code up to spec.  This was a problem shared by many (to varying degrees), and is a reminder to inventors to always carry around their elevator pitch/product demo on PowerPoint.

According to an unnamed Google employee, constant SDK updating is just one of many Android problems that will be “solved by the launch”.

Download here:
http://code.google.com/android/

Existing developers should follow the upgrade guide:
http://code.google.com/android/intro/upgrading.html

A few observations:

• Updated user interface/home screen (looks pretty as ever), messaging and picture applications now present. Hopefully this will mean less peering into grainy YouTube videos to see the user interface in action.
• App store still missing (see comment about grainy YouTube videos).
• Applications must be cryptographically signed, so as to identify the developer. This is a new and important feature, but lacks any mention of how this fits into the Android ecosystem. Historically the Java ME implementation of application signing was appallingly bad, so I will be keeping a close eye on how this develops.
• Bluetooth support is conspicuous by its absence. Bluetooth is hard to get right (just look at all those buggy phones over the years), so this was somewhat expected. We are told to wait until version 1.0 for this feature, but I could imagine this sort of thing holding up the whole show.
• Network access now requires explicit permission at install time. Perhaps all those developers with unlimited 3G data plans forgot about the little guys.
• GTalk is now officially *gone* from this release (citing security reasons), which will kill a lot of developers who were taking this shortcut to peer-to-peer.
• There are unspecified changes to the installer, so I will have to do some experimentation with the “adb” to see how flexible this will be.
• They have *fixed* the long startup times bug. Although I didn’t seem much difference with startup time, this always seems to happen when I am giving a presentation (see Murphy’s law).

I will follow up with more detail once I start developing.

Snowball:
I promised myself that I wouldn’t touch Snowball until Google released an improved emulator. Now here it is, I will have to schedule some development time after my vacation next week.

For this SDK release, my Snowball “to do” list looks like this:

• Implement the Wi-Fi Channel, so handsets can share content with Wi-Fi base stations and other users in a peer-to-peer fashion.
• Create a Snowball development kit, including the “Snowball Engine” client application and example code so other developers can try it out.
• Bluetooth support will have to wait for 1.0.

15-17 August 2008: The *First* Düsseldorf Balloon Festival
Here are some photos from the day we *almost* went for a balloon ride over Düsseldorf.  Taken from the Oberkassel side of the Rhine, you can see the Altstadt, TV and the Mediahafen in the background.

Note: Click on a photo to add a comment.

At least when the new iPhone comes out (around July) we will get to see multi-user GPS tracking in action, and I will be getting ready to eat my words (click) if Apple can produce a GPS device significantly better than the one currently included in the Nokia N95.

Otherwise those pins on the map might turn out to be inaccurate or hopelessly out of date.

I wonder if they will include the option to track users via Cell ID instead of GPS?

Based on Google group discussions here and here, it seems that Mobeegal and Commandro (both ADC winners) were considering these issues when developing their applications.

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

At the risk of sounding like a sore looser (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.

Conclusion…
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.
Mark

* Measurement based on N95 tracking performance

Having some Flash experience makes that tempting, although realistically the iPhone would be an opportunity to dive into a more complete platform.

Both have merit, although I stand by my decision to build a prototype for Android, as it’s the only platform that promises to run Snowball freely and without restrictions.

However will all have to wait a year to see if any of Google’s “openness” promises actually materialise in the market.