Last week I wrote a simple WhereAreYou? application that used the Google Ajax APIs ClientLocation API to access your location via your IP address.
At the same time, we announced support for the Gears Geolocation API that can calculate your address using a GPS device, WiFi info, cell tower ids, and IP address lookups.
Add to all of that, the W3C Geolocation API that Andrei Popescu of the Gears team is editing. You will notice that it looks similar to the Gears API, with subtle differences. The ClientLocation API is quite different.
To make life easier, I decided to put together a shim called GeoMeta that give you the W3C Geolocation API, and happens to use the other APIs under the hood.
If you have the Geolocation API native in your browser (no one does yet, future proof!) that will be used. If you have Gears, that API will be used, and finally, with nothing the ClientLocation API will be used behind the scenes.
To you the API will look similar:
// navigator.geolocation.getCurrentPosition(successCallback, errorCallback, options)
navigator.geolocation.getCurrentPosition(function(position) {
var location = [position.address.city, position.address.region, position.address.country].join(', ');
createMap(position.latitude, position.longitude, location);
}, function() {
document.getElementById('cantfindyou').innerHTML = "Crap, I don't know. Good hiding!";
});
At least, that is what I would like. Unfortunately, there are a few little differences that leak through.
The W3C API only seems to give you a lat / long, so you have to do the geocoding to get address info
The Gears API gives you an additional gearsAddress object attached to the resulting position object. This can contain a lot of information on the resulting area (street address to city to …) however for certain providers the API returns that as null, the same as the W3C standard
That gearsAddress object has slightly different information from the address data that the ClientLocation API returns. NOTE: I would love to see this just called ‘address’ to help the shim.
To give you control when you need it, you can ask the navigator.geolocation object what type it is. navigator.geolocation.type will be null if it is native, but ‘Gears’ or ‘ClientLocation’ if a shim kicks in. You can also check navigator.geolocation.shim to see if it is augmented code.
Implementation
There is some fun implementation code in there if you poke around. For example, for the ClientLocation API, when you make a call, it will be added to a queue if the Google Loader hasn’t fully loaded yet, and it will kick off that call when finished. Dealing with dynamically creating <script src> as a loading mechanism sure is fun!
I like the idea of jumping straight to the W3C standard and updating the shim as the APIs change. That way, when browsers catch up, the code will still work using the native APIs and you don’t have to change a thing.
I also hope that we get general reverse geocoding in place, which would enable me to even take the native “standard” and strap on useful address info to the bare bones lat/long.
Google and Adobe have been working on improving the indexing of Flash applications. In the past we could simply look at the SWF files and try to grab strings out of them, but there was zero context.
To go further Google uses the SWF Searchable work from Adobe to be more of a ‘human’ actor on the application.
This is what it doesn’t do:
Googlebot does not execute some types of JavaScript. So if your web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed.
We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.
While we are able to index Flash in almost all of the languages found on the web, currently there are difficulties with Flash content written in bidirectional languages. Until this is fixed, we will be unable to index Hebrew language or Arabic language content from Flash files.
This is good news for all rich applications. One of the common worries when it comes to richer application development is “what do search engines see” and we sometimes see people go back to the simpler world just to make that happier. With the search engines stepping up themselves, we can go back to writing applications that make sense for our human users, and hope that the computers catch up. Of course, we always have to do so in a practical way.
Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!
I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.
Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!
At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.
When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:
Caching can be done correctly, and once, by us... and developers have to do nothing
Gzip works
We can serve minified versions
The files are hosted by Google which has a distributed CDN at various points around the world, so the files are "close" to the user
The servers are fast
By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.
This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.
Details of what we are launching
You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.
The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.
For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:
You will notice that the version used was just "1". This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.
Specifying a version of "1.8.2" will select the obvious version. This is because a fully specified version was used. Specifying a version of "1.8" would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for "1" will end up loading version 1.9.1.
Note, these versioning semantics work the same way when using google.load and when using direct script urls.
By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the "uncompressed" parameter like so:
Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.
Here I am, talking about what we are doing in two short slides:
The Future
This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.
If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT'd ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don't have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.
The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.
Acknowledgements
I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don't use our project hosting facilities.
Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.
Doctype is an exciting beast, and for many reasons. Having a place to collect this data is key, and as I said yesterday, I can't wait to see it grow as an open resource.
The other cool part of Doctype is that there are tests to backup claims. This seems like a "no brainer" as some of my 'sherman' friends would put it, as it is the corner stone of science.
Mark Pilgrim has released Google Doctype, an open encyclopedia and reference library. Written by web developers, for web developers. It includes articles on web security, JavaScript DOM manipulation, CSS tips and tricks, and more.
The reference section includes a growing library of test cases for checking cross-browser and cross-platform compatibility.
This is just the beginning for the ambitious project, which is open source, and open licensed (Creative Commons). Now it is out there we, the developers, have the option to add valuable data to grow the corpus.
Congrats to Mark on the launch. I know that it has been a huge amount of work for him, and I am excited to see it out there. Below is Mark talking about the project:
You may also notice the document reader application, which is driven by GWT.
Today we have Bruce Johnson of the GWT team talking to us about GWT 1.5. He discusses the new features, such as the long awaited Java 5 language support, performance improvements, and much more.
It is very nice to take an application, run it through the new GWT 1.5 compiler, and get an instantly faster running application "for free".
There are terms of use that you should abide by, and some other comments:
An area to pay special attention to relates to correctly identifying
yourself in your requests. Applications MUST always include a valid and accurate http referer header in their requests. In addition, we ask, but do not require, that each request contains a valid API Key. By providing a key, your application provides us with a secondary identification mechanism that is useful should we need to contact you in order to correct any problems.
Check out the updated documentation for more details on each API:
I had a funny feeling that we would see frameworks and tools starting to support Google App Engine. Appcelerator has added support into their SDK, so you can now create an App Engine project.
<divclass="logo" on="click then script[window.location.href='http://www.appcelerant.com/?p=54']"><h1style="display: none">App Tunes</h1></div>
<divclass="powered_by" on="click then script[window.location.href='http://www.appcelerator.org/']"><h4style="display: none">Powered By Appcelerator</h4></div>
</div>
<divid="body"style="visibility: hidden" on="l:app.compiled then visible">
<app :as_flexflow id="flow" on="r:get.albums.response then execute or r:select.album.response then select"
I have been really looking forward to seeing the Google App Engine launch, and get in the hands of developers. This is just a preview release, and I obviously would like to see more languages and frameworks above and beyond Python and what we have now. The non-Pythonistas will all be saying "what about [insert my language and framework]". Slowly, slowly, catchy, monkey.
What is the Google App Engine?
Google App Engine lets you run your web applications on Google's infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it's ready to serve your users.
You can serve your app using a free domain name on the appspot.com domain, or use Google Apps to serve it from your own domain. You can share your application with the world, or limit access to members of your organization.
App Engine costs nothing to get started. Sign up for a free account, and you can develop and publish your application for the world to see, at no charge and with no obligation. A free account can use up to 500MB of persistent storage and enough CPU and bandwidth for about 5 million page views a month.
During the preview release of Google App Engine, only free accounts are available. In the near future, you will be able to purchase additional computing resources.
You have to understand the limitations, and the model that is being used. In my mind this is very different than other solutions like EC2/S3. There are very different use cases at work choosing between a low level (and hence very flexible!) provisioning system like EC2, and a deployment solution that gives you a sandbox to deploy applications. Google App Engine is a full stack.
The stack gives you access to Bigtable, which also means that you are not in the world of booting up MySQL. You do things "the Google way" and some people will like it, and some will not. That is fine!
What excites me about this, is that I often have a bunch of little applications that need a host. Sometimes it can be a pain to setup. Other times you would like to make the service public but don't want people to go hog wild and give you bandwidth costs and contention for your other apps on your host. Now I have a simple place to put these little apps, and this is where Ajax comes in.
As we develop richer applications with more client side logic, and natural service separations, we can create these modules as Google App Engine apps that do one thing well. There will be a natural fit for applications built with GWT, Flex, and other rich component toolkits.
Google App Engine doesn't give you something that you couldn't do in an Ajax application, but it does give you a place to throw up these services in short order. This is one step on the way to the world of DEPLOY. There are other services with different tradeoffs, such as Heroku.
I would love to see JavaScript on the server as an option, but that is back to language wars....
NOTE: Google I/O is a conference being held at San Francisco on May 28-29 2008. APIs like this will be talked about. I will be there. And lots of good folks will be there (Steve Souders, Mark Lucovsky, Guido van Rossum, Jeff Dean, Chris DiBona, Josh Bloch).
The team used a lot of the principles from Steve Souders book: High Performance Web Sites and ended up with a nice gain:
According to our latency measurement stats, the user-perceived latency on Google Code dropped quite a bit, anywhere between 30% and 70% depending on the page. This is a huge return for relatively small investments we've made along the way, and we hope you'll find these techniques useful for your own web development as well.
The changes were low hanging fruit that most of the sites could also implement:
Combined and minimized JavaScript and CSS files used throughout the site
Implemented CSS sprites for frequently-used images
Implemented lazy loading of Google AJAX APIs loader module (google.load)
I have seen the huge batches of cell phones that companies keep around to test their applications on. Companies like UI Evolution have come along to try to help out the madness of getting something that works across more than a couple of them.
Not only do you have the problems of handsets, but you also have the network lock-downs and the hoops you have to go through to get an application onto a large set of devices.
Since the iPhone, I have strongly believed that history is going to repeat itself, and the Web is going to win on the mobile.
Today we're announcing the launch of Google Gears for mobile, a mobile browser extension for creating rich web applications for mobile devices. The first version is now available for Internet Explorer Mobile on Windows Mobile 5 and 6. It's a fully functional port of Google Gears v0.2 that can be used to develop offline capability into your mobile web applications. You can also create slick and responsive applications by hiding latency issues through controlled caching of data and storage of information between sessions. We're also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers.
There are already a handful of Windows Mobile web apps that use Google Gears for mobile, such as the social payment service Buxfer and online applications provider Zoho. Read more about these applications and how they use Google Gears for mobile on the Google mobile blog.
I got to fly back home to London to talk to members of the mobile team. Below is an interview with a couple of the engineers, and there is also a high level look at the news:
I am really excited about what this means for the future of mobile development. I want to be able to develop applications using Ajax on the phone, and see tools like Gears give me access to native APIs on those devices. I really hope that the iPhone SDK also offers more on the JavaScript API side too (as well as Cocoa). How nice would it be to take your iPhone app and finally get some onPinch goodness, and camera.takePhoto.
Ben Lisbakken, who sits 100 feet away from me, developed gearsAJAXHelper, a library that bridges the AJAX search and feed APIs with Gears, to get a speed improvement:
We decided it would be cool to write a small library to make it easy for you AJAX APIs developers to write quick-loading, always fresh searches/feeds. The gearsAJAXHelper has two main features - it allows you to store and return key/value pairs from the local database, and it allows you to choose whether you want all resources files on the page (images, CSS, Javascript, HTML) to automatically be cached in the Gears cache.
The key/value pair database feature let's you store the query/results as a key/value pair. Then, the next time the query is made, the results can be served from the database while fresh results are being retrieved. This dramatically reduces the latency in queries/feed grabs.
The (optional) automatic cacheing of resource files will make it so that each time the user visits your webpage they will be getting resources served from their Google Gears cache, not new versions from the internet. Be careful when using this feature, as you might not want stale content to be served. There is also a refresh function, to clear the Google Gears cache of old files.
You can take a look at the sample, that saves the content for presidential candidates so if you click back on an area, you get instant loads.
Gears gives you all of the components that you need to take your application offline. If you have the type of application that for now wants to just take some of its content offline, that should be trivial to do right?
That was Brad Neuberg's position, so he created Gears PubTools as a way to make that happen. These tools are for content authors that don't even want to touch JavaScript.
How you use it?
Point to a Gears manifest file (a special file that lists all the pages to take offline) with a simple HTML attribute:
NOTE: This shows the Desktop Shortcut API that you can use in any offline application.
You don't even have to write the manifest file yourself! PubTools includes a simple bookmarklet that developers can drag to their browser's toolbar. Just navigate to the web pages you want offline, press the "Generate Manifest" bookmarklet, and a dialog will appear with the full manifest file generated for you ready to cut and paste into a file.
The core Google Gears gives us the building blocks that we can then build on top of to give users really easy tools and APIs. It has been great to see Brad join the Gears team and see him work on some of these issues. I expect to see much more from him in the future. What would you like to see?
, Google
