It’s been a very geeky week – only a couple of days after BathCamp, I was in London yesterday for Google Developer Day.
I was saying only a couple of days ago that I really need to get my head around some of the options out there for web developers, so this was well timed.
I learnt about web development tools and online APIs, talked a lot about where mobile development is going, and got to wander around Wembley Stadium. All in all, it was a good day. 🙂
The underlying theme for the talks throughout the day was showing how Google are trying to make the web ‘better’.
The messages were grouped into four key areas:
- “client” – making the browser more powerful – through Chrome, and Gears
- “cloud” – making the cloud more powerful – through the various APIs they make available
- “connectivity” – making web apps more powerful – through web development tools like GWT, and Android for mobile
- “social” web – making the web more social – through OpenSocial
I made a ton of notes throughout the day. Rather than write the world’s longest blog post, I’ve picked out a few interesting bits.
Chrome and Gears
There were several attempts to make reassuring noises about why Google is getting into the browser business.
These ranged from the fluffy (‘the web helped us, so we want to give something back’, or ‘don’t be scared, cos we’ve open-sourced it!’) to the economic (‘better web = more users = more usage of Google products = more money for Google’).
The demos didn’t show anything I haven’t already seen from trying it out for myself, and I didn’t hear anything in talks that wasn’t (very well!) explained in their comic. (That said, I missed a talk in the afternoon about the new Javascript engine, V8).
The message seemed to be “we want to do cool stuff on the web, and we’re frustrated because browsers are holding us back” – with both Chrome and Gears being ways they can add the capabilities they need.
They made some noises about HTML 5, and respecting the importance of standards. They characterised Gears as being how they do this stuff in the short-term, and HTML 5 as the way to do stuff longer-term – pointing at how some Gears-esque stuff has already been integrated into the HTML 5 spec. There were no details in how any migration might take place, but they did say that this was being thought about.
Gears for mobile
The session on Gears for mobile was very interesting. The argument was that the time for writing native apps for mobile devices has passed, and that web development is the answer now.
With so many different device operating systems, it is no longer effective to write an application for every possible platform.
Instead, the web is the platform.
However, on mobiles, web apps “suck”. This is because they are:
- “slow” : high network latency, low bandwidth
- “unresponsive” : Javascript is run the same thread as the browser, often making the whole browser unresponsive
- “blind” : they have limited access to device features
Gears for mobile is Google’s answer for this – making mobile web apps an option. They aim to make mobile web apps:
- “fast” – provides persistent controlled storage between sessions – by not re-fetching data across network, you can keep the UI responsive
- “fluid” – provides multiple background threads so you don’t block the UI
- “aware” – providing access to device features – the first of which is the new geolocation API
The storage idea is neat. With Gears, a web app always talks to a local database, and Gears keeps it in sync with online data. If the signal is slow, or drops completely – you don’t notice – as the app always uses the locally cached data.
The demo of ITN’s mobile news site was very convincing. A news site formatted for mobile phones is good, but still useless when your signal is unreliable like on a train, or non-existent like on the tube. Using the offline APIs, the ITN site lets you browse regardless of signal speed or reliability because you browse the local database. And using the geolocation API, the site can offer local news and weather.
There was also some discussion on how the site provides video – e.g. asking for confirmation before downloading large files, offering file formats appropriate to the device, etc. – which was interesting.
As an aside, a neat benefit of Gears as underlying technology means this isn’t mobile specific – you could use this on a laptop, too.
Google Web Toolkit
I’d vaguely heard of GWT before, and had assumed that it was another framework for developing web apps. That’s not quite right. Instead, it’s a way of writing web applications without needing to learn Javascript, AJAX or another web dev framework.
You write Java, and use GWT to compile it into cross-browser, highly-optimised javascript. Write Java, get AJAX.
The integration with Eclipse is quite neat – a couple of demos showed how Eclipse can be used to write and test web apps. Using the “hosted mode browser” you can launch your web app in a mock browser – running your app within an embedded IE or mozilla control. The neat bit is that when run like this, it is running the actual Java bytecode, rather than the compiled (and obfuscated) Javascript. This means that you can properly debug – breakpoints, step-through, and so on, etc.
As someone familiar with Eclipse who knows how to write decent Java, but doesn’t know much about AJAX, this sounds very cool.
There was a lot of talk about the effort that goes into the code generator – so that it generates AJAX ‘better than you’d write manually’. Examples include deferred binding (which means users only download bits they need to run – such as browser specific code libraries, and intelligent caching, so repeat visits can be very quick to load), handling of a vast array of cross-browser quirks without you needing to worry about it, ensuring no memory leaks, and adding browser history support even if users stay within a single page.
The idea is that even a lowly Java developer like me can produce some “very powerful, very ambitious AJAX” web apps. Neat.
Android SDK
There were a few talks on Android – I went to one on the Android SDK. Again, the Eclipse integration was very impressive. You can import a sample project into Eclipse, deploy it to an emulator, and be running in a few clicks.
It was interesting to hear about Content Providers. They provide an API for Android applications to persist data – to store and retrieve their data in a REST-like way. This means apps can provide a common convention to query for data, and a common convention to return results – allowing for application mashups on the device. I like the idea of an infrastructure that encourages apps to share data – and it seems appropriate given Google’s heritage in web APIs.
Other stuff I didn’t know Google was doing
Google Audio Indexing
Using speech-to-text technology to index the spoken words in YouTube videos, letting you jump to the right portion of the video where required words are spoken. Limited to selected videos at the moment, but still quite neat.
Google Visualisations
I’ve played with Google Charts before, but I didn’t realise they had this, too. There is a big range of ways you can represent data using this API, and I’ll have to give some of these a try. The annotated timeline, for example, could make for a very cool CurrentCost app.
Some random thoughts about the day
Overall, I had a very good day. I think Google could have done more to support the backchannel during the day. I know that this wasn’t a barcamp – we were there to learn from the Googlers (is that a word? Googlies? Googols? What do they call themselves?) rather than each other.
But even so, it all felt a little sterile. Even just saying “if you post stuff about the day to your blog / twitter / flickr etc. please use this tag” would have been an improvement. Someone really should have pointed them at backnetwork.
This is a small quibble though – I learnt a lot, met some interesting people, got inspired to try some new things, ate way too much chocolate, and got a neat new toy. Hard not to be pleased with that. 🙂
Tags: chrome, gdd, gears, google, google developer day, google web toolkit, gwt