Dec 21

Gears Future APIs: Location API

Gears, Mobile with tags: , 7 Comments »

I have spoken at a bunch of conferences in Europe this quarter. From the Future of Web Apps, and @mediaAjax in London, to JavaZone and JavaPolis in Oslo and Belgium. When I speak about Gears there, I get a lot of questions about Mobile Gears.

A lot of the features of Gears arguably make even MORE sense on a mobile device. Allowing Web developers to build applications for phones has taken off well thanks to the iPhone. Gears can help out in these high latency devices.

One very handy API to have would be a Location API (although it would be useful in other contexts too):

The purpose of this API is to provide means to fetch the location of a device running a Web browser with Gears.

The Location API is an abstraction for the various LBS APIs that currently exist on mobile platforms (GPS-based, network/cellid-based). The API consists of the Location class, which encapsulates various location attributes (latitude, longitude, etc), and also provides the means to query the platform for a location fix. This API also adds a new event type that is fired every time the location changes. Location implementations can be straightforward mappings to native LBS APIs (e.g the S60 Location Acquisition API) or have a more complex design that combines several location providers (e.g a GPS-based provider and a cell id-based provider) and returns the location from the most accurate provider at any given time.

Here is the API as a code example using it:

// Getting the object
var location = google.gears.factory.create( "beta.location", "1.0" );
// Setting up a callback to handle "location changed" events
location.onlocationstatechanged = function() {
   switch (this.state) {
     case 1:
     case 2:
      case 3:
          SetStatusText("Location accuracy:", this.accuracy);
          MoveMap(this.latitude, this.longitude);
      case 5:
         alert("Unknown state!");
// Initiate a fix. This leads to the onlocationstatechanged event handler being called exactly once for each
// of the "connecting" and "acquiring" states and one or more times for the "fixed" state (for the initial
// fix and every time the location changes, after that).
location.startLocationUpdates(); // async call, initiates fix (powers up GPS if needed, etc)
// Getting the last known location
if (location.latitude != -1 &&
    location.timeUTC > threshold) {  // the location info is valid and not very old
  Foo(location.latitude, location.longitude);
// Cancel the request. This leads to the onlocationstatechanged event handler being called for
// the "canceled" state. This call will power down the GPS HW / close HTTP connection
// (depending on the location providers that were in use).

I can imagine the fun games that I could write here, let alone the interesting business apps that could take the location context into consideration.

Other Future APIs

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.

Nov 30

So happy to see a Erik Thauvin post

Mobile, Tech with tags: , , , , 1 Comment »

Erik Thauvin’s link blog was huge back when I was doing TheServerSide. If you read both the TSS feed and Erik’s you were pretty sure that you were getting a look at most of the interesting content in the Java, and Enterprise Java communities.

I had huge respect for him, and it was sad to see his link blog die out as he got interested in other aspects of life. I can’t blame him. I also moved on from the world of Enterprise Java and got into other technologies and interests. Ajaxian was born to fill my “I love working with communities” itch.

Erik was developing top notch mobile applications and as soon as I launched devphone I knew I had to reach out to him.

So, I can’t tell you how excited I am to see this at the bottom of a post on how Google Maps Mobile works:

devphone 11/30/07 11:00 PM erik Java Networks Windows Mobile

Welcome, Erik. Who know where the ride will lead, but whatever happens, I am honoured to have some fun with you along the way :)

Nov 05

Android: The GPhone is a Robot, and it isn’t a phone

Google, Mobile, Open Source, Tech with tags: , , , , No Comments »

One of the fascinating effects of working for a company that so many love to keep a look on is that you get to be on the inside watching the thoughts of “analysts”, press, and random folk.

Watching the speculation around the “GPhone” has been fun. I particularly loved it when people would come up with suggestions such as:

  • “The GPhone will read ads into your ear before each call”
  • “The GPhone will have scrolling ads through the screen”

Riiiiight. That would go down really well wouldn’t it! I love how some think that Google has to literally put ads everywhere to make it worthwhile. Google needs the web to keep expanding and to have more people on more devices on it. If that happens, Google will do well.


So there isn’t a GPhone, but instead there is the Open Handset Alliance, or Android (for a more fun name), which is an Apache licensed open source stack for mobile. No more walled garden. This is pretty huge. I can’t wait for the SDK to get out in the open on November 12th. I wish we could have gotten more information out there today to be honest. There are a bunch of usual suspects that people who read my blog also read that are a major part of this, so I am really happy for them that this is getting out in the open!

What I am looking forward to

The applications of course. Smart location-aware services will be fun, but what I really wish I could get is for a mobile digital wallet so I don’t have to use cash/credit cards. I want to use my phone for this just as they are able to do in parts of Europe and Asia. With an open platform that anyone can build applications for, I know it is going to happen.

Here is the fluffy look at Android, but for developers, please think about what apps you would like to see on a phone, and come back on November 12th for the real announcement that we care about… the SDK itself so you can see what you can do!