OpenSocial / Google Gadgets API: Teil 1 – Grundlagen

Gadgets und Applikationen in Social Networks wie StudiVZ, Xing und Lokalisten.de sind das nächste große Ding im Web 2.0. Im Selbstversuch erlerne ich die Google Gadget und OpenSocial-API und alles drum und dran. Hier möchte ich zeigen, wie ich auf meinem Weg zum Gadget Developer vorankomme und wie man solche Gadgets überhaupt baut.

In Teil 1 dieser Reihe zeige ich, wie man ein recht simples Gadget erstellt, das Inhalte per Request von einer dritten (nämlich normalerweise Deiner eigenen) Seite empfängt.

(Ach ja, und Leute, die das alles nicht lesen, sondern nur das Beispiel haben wollen, um selbst draus schlau zu werden, können sich auch den Ergebniscode im Ganzen ansehen.)

OpenSocial Gadgets sind kleine webbasierte Applikationen, die man in eine Reihe von Social Networks einbinden kann. Auf Facebook sind ähnliche Applikationen seit einiger Zeit sehr beliebt, studiVZ zieht am 07.12.2009 mit einer Implementierung des OpenSocial-Frameworks nach. Voraussetzung zur Entwickung solcher Gadgets sind solide Grundlagen über HTML, Javascript und AJAX, später ist sicherlich eine serverseitige Sprache wie PHP sinnvoll. Außerdem braucht ihr einen offen zugänglichen Webspace (der dann später auch die besagte serverseitige Sprache unterstützt).

1. Die Testumgebung

Irgendwo muss uns ja das OpenSocial-Framework zur Verfügung stehen, damit wir sinnvoll entwickeln und testen können. Hier bieten einige Social Networks, so auch StudiVZ, eigens eine Developer Sandbox an. Doch bis man sich dort angemeldet hat, dauert; und der Deploy erfolgt meines Wissens aufwändig als gepacktes Archiv auf irgendwelche studiVZ-Server.

Da kommt uns doch ganz gelegen, dass Google ein bisschen weniger restriktiv ist, und jeden alle möglichen Gadgets ganz einfach per Feed in seine iGoogle-Startseite einbinden lässt. Solltest du also noch keinen Google Account haben, ist jetzt der richtige Augenblick gekommen, dich zu registrieren und mit iGoogle, der anpassbaren Google Startseite vertraut zu machen. Ich warte hier so lange.

2. Der Aufbau

Bereit? Gut. Auch wenn ich es eigentlich überspringen wollte, eignet sich ein klassisches Hello-World-Beispiel doch recht gut, um den Aufbau eines jeden Gadgets zu zeigen. Das ist nämlich zunächst nichts anderes als eine XML-Datei:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs title="Mein erstes Gadget">
    <Require feature="dynamic-height" />
    <Require feature="opensocial-0.8"/>
  </ModulePrefs>
  <Content type="html">
    <![CDATA[
       <p>Hello World</p>
    ]]>
  </Content>
</Module>

Was da passiert? Ganz einfach!

Innerhalb des <Module>-Tags finden sich die Knoten <ModulePrefs> (“Moduleinstellungen”). Dort wird als Attribut der Name des Gadgets geliefert. Anschließend legen wir fest, dass das Gadget nur eingebettet werden darf auf Seiten, die uns das Feature “dynamic-height” sowie die “opensocial-0.8″-API bereitstellen.

Der Content mit dem darin enthaltenen CDATA-Block ist im Prinzip nichts anderes als der <Body>-Konten in HTML und wird später – wer hätte es gedacht – allen Inhalt und alles Javascript des Gadgets enthalten. Speichern wir das ganze doch mal auf unserem Webspace als “myfirstgadget.xml”.

Gadget-XML zur iGoogle-Seite hinzufügen

Gadget-XML zur iGoogle-Seite hinzufügen

3. Der erste Test

In iGoogle siehst du oben rechts den Link “Gadgets hinzufügen”. Dahinter verbirgt sich eine Auswahlseite, die uns wiederum einen Link zum Hinzufügen von Gadgets oder Feeds via URL bereitstellt. Draufklicken, URL zum soeben erstellten XML hineinpasten, hinzufügen und gut is’.

Schau doch mal, was deine Startseite jetzt sagt! Buenos Dias, Mundo!

Und Mundo bist in diesem Falle du.

4. Requesting

Wir wollten ja ein Gadget bauen, das seinen Inhalt dynamisch per HTTP-Request erhält. Das klingt nach AJAX, ist es irgendwie auch. Passiert also in Javascript. Fügen wir also den folgenden Script-Block unter den öffnenden <Content>-Tag in unserem Beispiel ein:

<script type="text/javascript">
function init() {
    var params = {};
    params[gadgets.io.RequestParameters.CONTENT_TYPE]
                        = gadgets.io.ContentType.TEXT;
    params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 5;
    var requestUri = "http://www.example.org/apitest.php?random="
                        + Math.floor(Math.random()*11);
    gadgets.io.makeRequest(requestUri, testApiResultHandler, params);
}
function testApiResultHandler(data) {
    document.getElementById('articleText').innerHTML = data.text;
    gadgets.window.adjustHeight();
}
gadgets.util.registerOnLoadHandler(init);

</script>

Wieder einmal: Was passiert hier?

Erstens erstelle ich eine Funktion init(). Die ist für den eigentlichen Request zuständig. Wie aus der OpenSocial-API-Referenz ersichtlich, wird der HTTP-Request mit der gadgets.io-Klasse vollzogen und darf eine Zielurl, eine Callback-Funktion und Parameter als Argumente erhalten. Ein passende instanz der gadget-Klasse stellt mir das Framework übrigens automatisch bereit.

Bauen wir uns also zunächst die Parameter zusammen. Hinter den langen Konstantennamen, die dem params-Objekt als Keys mitgegeben werden, stehen gültige Schlüssel aus dem Optionenkatalog der gadgets.io-Klasse. Ich definiere also, dass ich als Content-Type für die Antwort meines Requests simplen Text erwarte.

Außerdem stelle ich klar, dass Google die Request-Antwort für maximal 5 Sekunden cachen darf. Dieser Wert ist für Developmentzwecke super, kann aber im Livebetrieb extrem serverauslastend wirken. Denkt daran! Das Framework gibt uns schon eine Spitzenmöglichkeit, einfach zu cachen, so sollte man sie auch benutzen.

In der requestUri-Variablen steht – welch Wunder – die Adresse, an die der Request gehen soll. Ich füge außerdem eine Zufallszahl als Get-Parameter an, sodass noch einmal das Caching wunderbar umgangen wird.

Schließlich rufe ich mit der makeRequest-Methode der gadgets.io-Klasse den tatsächlichen Request auf. Das erste und letzte Argument kennt ihr bereits, der zweite ist der Name der Callbackfunktion, also der Funktion, die aufgerufen wird, wenn der Request eine Antwort geliefert hat.

Die Zweite Funktion wird aufgerufen, nachdem wir eine Antwort auf unseren Request erhalten haben. Der Wert für “data” wird uns reingeschmissen und enthält das Result-Object – und das, ohne dass wir noch etwas dafür tun müssen!

Wir könnten “data” an dieser Stelle einmal im Firebug inspizieren – außer dem später benutzen Attribut “text” gibt es nämlich noch ein paar andere, wie den HTTP-Statuscode der Antwort und mehr. Doch dazu ein anderes Mal.

Jetzt injizieren wir nämlich erstmal die Response in unser DOM, nämlich in ein Element mit der ID “articleText”. Das solltet Ihr natürlich erstellen, zum Beispiel als <div> unterhalb des “Hello World!”-Containers. Als neuen Inhalt für dieses Element dient – wie gerade angedeutet – der Inhalt des “text”-Attributs von “data”.

Die letzte Zeile dieser Funktion greift wieder auf die gadgets-API zurück, um die Höhe des Gadgets (z.B. auf der iGoogle-Startseite) automatisch dem Inhalt anzupassen. Genau dafür brauchten wir nämlich auch die erste RequireFeature-Zeile im Grundgerüst.

Schnell den onLoadHandler definiert (ebenfalls aus der gadgets-API): Hier wird gesagt, dass die Funktion “init” aufgerufen werden soll, sobald das Gadget geladen wird.

Fertig. Wenn das zu schnell ging, könnt ihr euch das gesamte Listing nochmal ansehen.

5. Und Serverseitig?

Diejenigen, die schonmal mit AJAX-Technologien gearbeitet haben wird es kaum wundern – meine apitest.php, die der Request in meinem Beispiel aufruft, macht nichts anderes, als irgendwelchen Content auszugeben (z.B. in PHP per ‘echo’). Das bedeutet – statt auf eine .php-Datei zu requesten, könnten wir auch jede beliebige HTML-Datei oder was auch immer anfragen. Cool, aye? Ein Beispiel dazu wäre:

<?php echo "Schau, der Server spricht mit mir!"; ?>

6. Außerdem beachten

Irgendwie wird anscheinend doch mehr gecached, als man denkt. Daher nicht verzweifeln, wenn die neueste Änderung immer noch nicht zum richtigen Ergebnis geführt hat, sondern ein Käffchen kochen und danach nochmal auf F5 drücken ;-)

In Teil 2 speichere ich Daten, die ein Benutzer in meinem Gadget eingeben kann, um einen einfachen Notizzettel zu basteln.

One Comment to “OpenSocial / Google Gadgets API: Teil 1 – Grundlagen”

  1. OpenSocial / Google Gadgets API: Teil 2 – Persistent speichern – lukx.de

    [...] ich in Teil 1 gezeigt habe, wie man einfache Get-Requests benutzt, um sein Gadget mit Inhalt zu versorgen, werde [...]


Leave a Reply