I'm waving!!
Not an earth-shattering confession, obviously. Seems that everyone is. Just an excuse to legitimise the inclusion of a picture of Kim Jong Il in a blog about software development.
Anyways, my previous entry discussed the relative ease of writing Robots for Google Wave. This was clearly written before I had an account and therefore wasn't tested, and as a consequence I am now wiping metaphorical egg from my face.
Thankfully, though, I received an invite on Friday, courtesy of Neil Saunders (many thanks, Neil) and set about to work. I'd already been alerted by a curious tester with far too much time on his hands that my Robot was an embarrassing failure, and quickly discovered this for myself as I added it to my first Wave.
The first problem (#1) was that I hadn't created an implementation of ProfileServlet, effectively identifying the Robot, giving it a name and an avatar and whathaveyou. I used the now clearly obsolete approach of marking all of this up in the capabilities.xml file. Still, dead easy to fix, and the source code for the ProfileServlet is available.
After a cheeky redeploy, the Robot was indeed visible and "worked" to a fashion, in so far as, on submission of a Blip, it matched UniProt names and attempted to append appropriate applet code to the end of the Blip. Problem #2, however, appeared to be that the applet code was either stripped from the Blip or never added. Using the appendMarkup() method of TextView, I was able to add hyperlink markup (a tags), but unable to add object tags. (I attempted to append an object tag embedding a YouTube video and this failed.) It's also not just a case of clicking on View Source Code to attempt to uncover what's gone wrong - I'm rather spoiled with Eclipse and Java coding as the debugging facility clearly allows programmers of moderate abilities to write something half decent without really trying. Debugging the Robot was/is largely done using the "trial-and-swear-lots" approach.
Undeterred, I noticed that one of my "Welcome to Wave" Waves contained an embedded YouTube video. Eu-bloody-reka. The key to my embed-an-object quandary was - as I first suspected - to wrap the applet up in a Gadget. This proved to be fairly straightfoward, following the tutorial provided. Effectively, a Gadget is written as an XML file, accessible in the same way that standard html files are accessible (from the war directory), in which HTML and JavaScript can be embedded. I wrote one, proteome.xml, which contained the markup for my applet object, and some JavaScript to parse the query string containing parameters for the applet. The only Gadget-specific task was to ensure that the Gadget would resize itself appropriately, depending upon the size of the applet (thanks to another tutorial entry).
The upshot of it all is that it kind of, nearly, possibly, maybe works ...ish if you squint hard enough...
There are still issues of varying magnitudes (the applets take ages to load, randomly fail to load at all, or - most annoyingly - load and then disappear virtually immediately). Also, multiple applets can be loaded for the same protein, which is pointless as they all show the same data. I'll get on to these, but would love to know more about the life cycle of a Blip / Gadget - who or what is calling 'stop' on my applet?
More importantly, I've twigged that applets are pretty rubbish in this context. I'm using about 2% of the facilities of Gadgets, and my main concern is that I'm using no concept of shared state between users. This doesn't matter so much in this context - viewing data - but if we wanted to do anything more sophisticated, manipulating data and sharing the outcome, I'd have to learn of all that fancy JavaScript that so far I've studiously ignored as it scares me. I also have no idea how to generate anything graphical in this context (what on Earth is that chess game example written in?!?).
Still bugs to fix and still lots to learn.
