ZEDRAY

After several months of black out, it’s suddenly new Android SDK day!
This is important as it gives us ‘fan boys’ a chance to take a look at how the new mobile phone operating system from Google is progressing.

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.

Somewhat ironically, today I was asked if I was interested in taking on either an iPhone or a Java-Flash-Light-widget project.

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.

• Warm up the emulator and install all your required apps well before you are required to start. The emulator takes a while to startup, and can sometimes get stuck on the Cylon animation, which (for me at least) seems to require a reboot to put right. Don’t risk doing this messing around when you have 50 people already seated and waiting for you to start.
• Do not try and use the maps or browser feature if you have an intermittent internet connection (i.e. a conference Wi-Fi). There is a bug in the current release which means that no Google service will be able to achieve a network connection if it couldn’t find one on startup. If you encounter this bug, consider restarting the emulator (see above)
• Demo Snowball. At least it will keep working even after you’ve lost connectivity.

Tips for doing a presentation on the iPhone SDK

• Read those SDK terms and conditions again and you will find that you’ve signed a non-disclosure agreement with Apple“all information disclosed by Apple to you that relates to Apple’s products, designs, business plans, business opportunities, finances, research, development, know-how, personnel, or third-party confidential information” as “Confidential Information” — excluding specific information that is available elsewhere. You must agree not to “disclose, publish, or disseminate” any of the aforementioned Confidential Information, and not to use it “in any way, including, without limitation, for your own or any third party’s benefit without the prior written approval of an authorized representative of Apple in each instance.”

  This effectively means you’ve signed away your right to talk about iPhone when you signed on to Apples developer program.

• Maybe you’ve developing for the wrong platform?

Anybody got any more tips while we are at it?

Its official, I will now be presenting at the JAX08 Conference with a presentation entitled:

Where am I? Location Based Services
Location Based Services stellen einen der großen Benefits mobiler Devices dar, der weit über die Bestimmung der eigenen Position hinausgeht. Im Java-ME-Umfeld werden derartige Services u.a. mittels Location API (JSR 179) realisierbar. Die Session zeigt die Möglichkeiten und Grenzen Java-ME-basierter Location Based Services und führt sowohl in die theoretischen Grundlagen als auch in die praktische Verwendung der Location API ein. Darüber hinaus wird anhand einer auf der Androids-Plattform basierenden Beispielanwendung eine Alternative zum klassischen LBS-Ansatz aufgezeigt. (click)

I will be co-presenting with my CEO - Lars Roewekamp of OpenKnowledge GMBH.

A very exciting time to be in mobile development and location based services in general.
I will also slip in something on Snowball and demo a few Android proofs of concept applications.

A new year and a good opportunity to look at all the mobile related stuff in my portfolio since:

2004

• EdiMap (MSc Edinburgh University)
  Tourist map of Edinburgh, with downloadable POI.
• NotPacMan (Self training)
  The familiar PacMan game.

2006 (Starting at OpenKnowledge)

• 
  Barometer, Horoskop and Lovecheck (AirMotion)
  Fun and games, and a lot of device testing.
• MiniMove (BMW via BBDO)
  Rotate the BMW mini on your mobile.

2007

• 
  MobileAct (Sony Ericsson via AirMotion)
  Weekly magazine content to go with the Channel 4 series.
• 
  MiniMove China (BMW via BBDO China)
  Rotate the BMW mini on your mobile in Chinese.
• 
  
  Mitch&Co Blackbox (Tchibo via MINICK)
  Explore the latest Mitch&Co fashon range on either male of female models.
• NowHere (Burda Wireless)
  Photograph where you are and upload as a NowHere POI.

2008…

• Ads by a [big mobile network operator]*
  Important stuff
• Google Android
  Self training on the new mobile OS from Google
• Snowball - The Mobile Location Based Search API
  My world beating business idea.

* To comply with my company’s code of conduct for blogs, I have removed all references to customers and projects currently in progress.

From what I can tell so far, Android seems to be a well thought out architecture that can seamlessly join lightweight application components today and scale well to better hardware in the future. Personally, I hope it will blow away J2ME (or JavaME?) including the long awaited MIDP 3.0 platform, by offering multi-process control and application interconnectivity out of the box.

At the time of writing, Google have released an SDK containing an early implementation of most API’s and have asked for feedback. We are told that any final implementations and the first actual devices are as much as a year away.

Going through the published material, it seems that not much detail is being given about the security implementation, which perhaps should scare me a little.

If you hire a room full of security experts, ask them to review your platform (much like in the early Java days) and make recommendations, they will provide you with a list of security requirements that will lock up the platform and kill off a lot of potential innovation.

As Security requirements tend to be overriding, the functionality is locked down now and only rolled back later under intense pressure (if ever?).

This post is an appeal for balance.

An open platform
What is an open platform when it is installed on a preparatory hardware device, distributed by network operators (with a financial interest in maintaining control over their customer’s behaviour) and integrated into pre-existing content controls and enterprise requirements?

Will we see open content?
I have no idea how DRM can be implemented within an open source environment, but right now most phones that I’ve encountered prevent the user from sharing content in a way they would expect to share files on their PC.

Most ‘non-smart’ phones will refuse to forward media, e.g. receive a picture and then send it to a friend’s phone via Bluetooth. Nokia phones will refuse to forward or save JAR files. Samsung phones (the worst offender I have seen) will refuse to run any Java application that has not been downloaded via OTA. As a developer I can tell you that this is a real pain.

I don’t agree with the limiting mechanisms, but many companies have made a good living supplying ring tones, wallpapers, games, etc via OTA downloads. As a developer who has made advertising content intended to be distributed for free, it breaks my heart to see my target audience of teenagers perhaps paying €3 to download a Bluetooth application they have already seen installed on a friend’s phone.

It just illustrates that the current system is so bad you can’t even give stuff away.

Will we see open APIs?
Say I want to write a client application that seeks out other phones over Bluetooth, finds a phone with a similar client, and then quietly shares content over a peer-to-peer connection. Updating content in the background throughout the day and giving it to the user upon request.

In J2ME this can’t be done, period.
Not because the hardware can’t support it, not because of a failure of the API (JSR-82 implemented this functionality quire well), but because the security people decided that it was a security threat.

That means that the users would have to approve every peer-to-peer connection (making the application pointless), or the application would have to be signed. Signed applications will only install on the phone within a specified time period (a certificate might last one year) and if the correct code signing certificate is already installed on the phone (good luck with that one). Just to make things more interesting, it’s considered a security threat to let the user install new certificates on their own devices.

Don’t you just love security consultants?

The current system seems to benefit few outside of Veresign, who have somehow managed to get their certificates installed on most devices that I’ve tested. A Veresign (or handful of other company’s) code signing certificate is a heavy upfront investment for a university/garage based project prototype (the sort that make history) and the fallback functionality of the application refusing to install is pretty ugly.

I don’t know how to best control API permissions.
Nokia (the first to implement this API on a mass market phone, the 6600), assumed that the user was too stupid to know whether to approve this functionality or not (is this a fair assumption?). Other manufactures differ slightly, but tend not to document permissions implementations which can vary between firmware versions.

Perhaps Google don’t need my advice, but as they haven’t released their Bluetooth API implementations yet I can only guess what kinds of things they are negotiating with interested parties while I write this.

More on the evil world of crippleware.