Google I/O Wrapup

Android Demo at Google I/O

Photo by SeanOsteen AttributionNoncommercialShare Alike Some rights reserved

The two days I spent Google I/O were an exciting whirlwind of running from presentation to presentation, and much to my surprise, eating! I didn't think I'd ever praise the food at a tech conference but as a couple Googlers pointed out, with Google the food is always good. The usual conference fare is a box lunch consisting of a sandwich, apple, bag of chips and cookie. Not for I/O though, Google set up three "Cafes", a grill, a deli and a Mexican cafe. The tri-tip at the Mexican cafe on the first day was scrumptious and natural beef hot dogs and Angus burgers at the Grill on Thursday weren't bad either. Then there was the party Wednesday evening; sushi, pasta, grilled salmon and chocolate fountains washed down with a nice Charles Krug Rutherford Cab.

So beside noshing I picked up quite a few mobile tidbits. In the buzz around Android, I think some of the Google Gears announcements may have been overlooked. First of all Gears has been "debranded", no more Google Gears, it's just Gears now. The name change was made to stress the Open Source nature of the project which includes a community of over 500 contributors, many from outside Google.

During I/O Opera and Google announced that Gears is coming to Opera 9.5 on both the desktop and mobile. It with be Windows Mobile only at first, but both UIQ and S60 versions of Opera 9.5 with Gears are in the pipeline. Up to now we've mostly been hearing about using Gears' local server and database storage to provide off line browsing, but there's another piece than sounds interesting for mobile web apps. Gears provides asynchronous worker threads that can synchronize local data in the background without blocking. I can see this being useful for things on mobile like live sports updates, RSS readers and Webmail.

The Gears team is working on something else that should really get mobile web developers salivating - a location provider accessed by a simple JavaScript call. It returns the device's current location using data from any of several sources including GPS, cell ids, the database of WiFi locations that Google has been building or IP address. There was no timeline given for when the location api would be released but working code was shown and demoed at I/O

Other new Gears features in development that were demoed included the ability to resume uploads and downloads, and a new file picker dialog supporting selection of multiple files. Gears is coming to Safari and Android too. As they are both WebKit based, I imagine that means we will see it on Nokia's WebKit browser eventually.

There was more Android news too. The last session of the mobile track at I/O was a Fireside Chat with Andy Rubin who heads the Android project along with Engineering Director Steve Horowitz and six of the tech leads. The format was audience members asking questions which were fielded by various members of the team. Here are my notes:

  • Best Andy Rubin sound bite; "The world doesn't need another OS but it does need a really good open source embedded OS"
  • USB master support (for keyboards, etc) is planned but won't be in the first devices.
  • Concerning fragmentation; Carriers and OEMs are free to modify, remove or lock down any part of Android, but Google believes that most will see the value of the whole package and of maintaining platform compatibility and will deliver the OS intact.
  • There will be a compatibility test script that anyone can run on an Android device to determine which APIs are present and functional.
  • Google is thinking hard about content distribution and billing - and something is in the works. That sounds to me like some kind of on-device or web-based Application Portal.
  • The next SDK release will mainly be bug fixes and cleanup with not too many new features.
  • Regarding security, there will be support for developers to self sign applications. Signing will be free of cost and is not required for access to any API. Signing lets two apps signed by same key share the same process. Signed apps can only be replaced (upgraded) by another app signed with same key.
  • A core Google value is "Trust the User" and Android will give control of security back to users instead of carriers and OEMs. Google is working to make security dialogs easy for non-technical users to understand. They would like to see a system of community recommendations for application usability and security.
  • Gears probably won't be in the first devices shipped. Andy asked the audience if they'd rather have a device released sooner or a later release with more features. The response from the crowd was a roaring "Release"!
  • The built-in browser won't have JavaScript access to sensitive data like location. But it would be relatively easy for a developer to create a custom browser using Android's BrowserView which essentially is a full WebKit implementation. The custom browser could access (with the the user's permission) any data exposed by the core OS including location, contacts, etc.
  • OTA and USB updates are part of Android. The Kernel supports both full upgrades and diff based patches. By default, firmware upgrades must be signed, although an OEM or more likely a community based implementation could deliver a build that allowed unsigned firmware to be installed if they wanted.
  • Developer Challenge II will probably kick off early next year. As it was always set to occur after the first devices shipped this reinforces my belief that we won't see a device release until late in the year.

Speaking of the first device. Engadget thinks the prototype shown at the keynote was HTC's Dream. They're probably right, HTC has said that they will release an Android device this year. And I heard a comment from one of the Android Googlers that there would probably only be one phone released this year. It all points to HTC and Dream is only name I've heard associated with an HTC Android phone. Of course no one has any specs for the Dream or knows what it really looks like, so its all meaningless but fun speculation at this point.

A special thanks and shout out to John Musser at who made it possible for me to attend by giving out free Google I/O passes on his blog last month. ProgramableWeb is a great site for anyone interested in building web (including mobile web) mashups.

5 thoughts on “Google I/O Wrapup

  1. Pingback: Natalian » Blog Archive » Web versus Android

  2. Pingback:» Blog Archive » Carnival of the Mobilists #126

  3. Hi Denis,

    FYI... MIME filters are on the client side and integrate into the
    mobile browser. They are extremely difficult to build and get working
    due to the lack of documentation from the browser manufacturers. There
    is a reason for this. A MIME filter gets to see everything coming and
    going from the device. You can imagine what you can do with that kind
    of power - especially when the MIME filter has an Open API attached to
    it. This would enable a programmer to write a thin mobile client app -
    read any operating system API and then send that data via the MIME
    filter (API's listen for new data) to the web server.

    > 2. What mobile widget framework has access to
    location data on WinMo and BB and can pass that information back to
    the JavaScript running in the browser? Or is that not how it works?

    Ours. We've built a MIME filter with an Open API.
    Now you can code any widget in whatever language you prefer and then
    have it pass that data to our filter which then passes it directly to
    your web server via the HTTP Request Header. All you do on the server
    side is have Mod_Mobile intercept the data (decrypt
    it) and then pass it via CGI script to whatever web app needs it.

    >3. Do Mobile Windows Explorer and the Blackberry
    browser actually support MasterClass.System.Get_Location out of the box. I Goggled that method
    and got zero hits.

    No. Nokia is working on it with Symbian, however it won't work on WM
    or BB. But it could with a MIME filter that can read the incoming data

    >4. Are you aware of any mobile web sites or
    services that are currently using either technique?

    None using the technique above...

    >5. Can you point me to any more information on using either widgets
    or Get_Location() on mobile browser platforms?

    You can read more on our web site



    PS. We’ve also just added a new feature called Event Signaling. This allows the server to “signal” the client that an event has just occurred. For example – the client sends updated data from the mobile device to the server. With Event Signaling the server can now send a message back to the client that it has successfully received the data.

    There will be a couple of formats:

    [notify broadcast=374]

    That will 'broadcast' a Notification event with a value of 374 ( or whatever ) to any 'Widget' that is 'Listening' for our notifications. Any program that's using our APIs qualifies for receiving these Event Notifications no matter what you want to call it. Could be a hidden system module or a full blown GUI APP. The notification value could mean 'All client data saved safely to database' or it could mean 'Retransmit data' or whatever you want. It's a way for Servers to now communicate directly with clients and tell them things. There can be an unlimited amount of application specific notifications in any response document.

    [notify windowname='ABCcompanyWidget' message=374]

    That sends a SPECIFIC notification to a SPECIFIC application with a Window title of 'ABCcompanyWidget' running on the client.
  4. Hi Peter,

    Thanks for the comment. This is new to me and very interesting. I have a few questions though.

    1. About mime filters, are they server side or client?
    2. What mobile widget framework has access to location data on WinMo and BB and can pass that information back to the JavaScript running in the browser? Or is that not how it works?
    3. Do Mobile Windows Explorer and the Blackberry browser actually support MasterClass.System.Get_Location out of the box. I Googled that method and got zero hits.
    4. Are you aware of any mobile web sites or services that are currently using either technique?
    5. Can you point me to any more information on using either widgets or Get_Location() on mobile browser platorms?
  5. RE: a location provider accessed by a simple JavaScript call.

    It's been doable for quite sometime on Blackberry and Windows Mobile. There are two ways to do it:

    1) Token replacement e.g. The JavaScript call appears inside the HTML file like this: MasterClass.System.Get_Location. You intercept that call and then replace that "token" with the actual location from the device. All you need is a MIME filter that reads the incoming data stream and when it sees the location token it makes a call to the required Java method and places the correct data inside the HTML file for display

    2) The second way to do this (cross platform) is to use a MIME filter that has a set of Open API's which the programmer can use to send data to. You then build an ultra thin widget that gets the location data from the device, passes it to the API's and then from there directly back to the web server.

    The simplicity of the above two approaches allows increased flexibility by allowing the developer to read ANY system level API and pass that data in real time directly to either a web server or use the token replacement scheme to make it appear in the browser page.


    5o9 Inc

Leave a Reply

Your email address will not be published. Required fields are marked *