Bachelorarbeit

Twitter Widget
für die PLE der Tu Graz

Autor:Jörg Sandriesser
SS 2010
Inhaltsverzeichnis
1.Einführung...........................................................................................................................2
2.Aktueller Stand der Technik................................................................................................3
2.1.Hauseigene Twitter Widgets....................................................................................3
2.2.Twitter für iGoogle...................................................................................................5
TwitterGadget........................................................................................................5
Twitter....................................................................................................................5
Twitter Reader.......................................................................................................6
2.3.Twitter Clients und Desktop Widgets......................................................................6
Twadget (Windows Vista & 7)...............................................................................6
Tweetdeck.............................................................................................................7
Turpial(Linux)........................................................................................................8
Gadfly(Silverlight)..................................................................................................8
Saezuri(plattformunabhänig)................................................................................8
Skeet(Google Chrome).........................................................................................8
Weitere Clients......................................................................................................9
2.4.Twitter auf mobilen Geräten....................................................................................9
3.Die Umsetzung des Widgets.............................................................................................10
3.1.Theoretische Grundlagen......................................................................................10
Die Twitter API.........................................................................................................10
MVC Pattern............................................................................................................12
Authentifizierung......................................................................................................14
oAuth...................................................................................................................14
Einsetzen von oAuth...........................................................................................14
3.2.Praktische Umsetzung..........................................................................................16
Aufbau und Struktur der Applikation.......................................................................16
Authentifizierung......................................................................................................17
Initialisierung und grundlegende Abläufe................................................................18
Abläufe der View.....................................................................................................19
DM, RT und @....................................................................................................20
Ausgeben neuer Informationen..........................................................................21
Funktionen und Requests im Controller..................................................................23
Model.......................................................................................................................25
Server......................................................................................................................25
4. Anwendungsbeispiel/Diskussion......................................................................................27
4.1.Anwendungsbeispiel.............................................................................................27
4.2.Diskussion.............................................................................................................29
5. Zusammenfassung und Ausblick.....................................................................................30
5.1.Zusammenfassung................................................................................................30
5.2.Ausblick.................................................................................................................31
6. Literatur............................................................................................................................32

2
 Abstract

Nowadays social networks like Twitter, Facebook or YouTube are available on different
possibilities, and not only on their own websites. This is offered by interfaces called API
which allows any external software developer to communicate and work with these
networks. This thesis is about the implementation of a Twitter Widget for the Personal
Learning Environment of the Tu Graz. The PLE is a social learning platform, which offers
the possibility to use different widgets, depending on the preferences of the user. The
small Twitter-application should provide the full basic Twitter functionality to the users. Very
important issues for the widget are: a good User-Interface, a simple Handling and a clear
overview. The authentication was realized with the open authentication protocol(oAuth),
which is a security protocol for API notification. The server-side communication with the
API is realized with php, on client-side html and javascript (Ajax) are in use. First a short
introduction is given, then existing Twitter clients and applications are discussed and
explained.

Soziale Netzwerke wie Twitter, Facebook oder YouTube sind heutzutage durch
verschiedenste Möglichkeiten erreichbar, und nicht nur über ihre Webseiten. Dies wird
ermöglicht durch offene Programmschnittstellen (APIs). Diese Schnittstellen ermöglichen
externen Entwicklern mit dem Netzwerk zu kommunizieren und auf Daten zuzugreifen.
Diese Arbeit handelt von der Implementation eines Twitter Widgets für die “Personal
Learning Environment”(PLE) der Tu Graz. Die PLE ist eine personalisierte Lernumgebung
welche den Benutzern verschiedenste Wigets anbietet. Das Twitter Widget soll die
komplette Twitter Grundfunktionalität anbieten. Besonderes Augenmerk wird hier auf ein
gutes User-Interface, einfache Handhabung und eine gute Übersicht gelegt. Die
Anmeldung erfolgt über das “open Authentication” (oAuth) realisiert. serverseitiger Code ist
in php geschrieben, clientseitger in html und Javascript. Am Anfang wird eine kurze
allgemeine Einführung gegeben, dann bestehende Twitter Clients diskutiert und der
abschließende Teil erklärt die technische Umsetzung des Widgets.
1. Einführung
Ziel des Projektes ist es, ein Widget für die Personal Learning Environment (PLE) der Tu
Graz umzusetzen, welches den Benutzern Zugriff auf das Twitter Netzwerk gibt, und
sämtliche grundlegende Twitter Funktionen anbietet. [Link 8]
Die PLE der Tu Graz(Abbildung 1) ist eine online Lernumgebung die von ihren Benutzern
individuell gestaltet und genutzt werden kann. Dies geschieht durch so genannte Widgets
(Window Gadgets) welche kleine abstrahierte Applikationen unterschiedlichster Art und
Funktionsweise sind. Die PLE erlaubt den Benutzern diese kleinen Applikationen so
einzusetzen und zu kombinieren, dass eine individuell optimale Umgebung für sie/ihn
entsteht. Jeder User kann Widgets nutzen, die im Moment für ihn interessant sind. Dies
kann auf eine bestimme Lernveranstaltung, ein bestimmtes Semester oder auch auf eine
ständige Nutzung (z.b.Kalender-Widget) ausgerichtet sein. So bietet die
Verwendung/Benutzung einer PLE unterschiedliche Vorteile. Beispiele wären: Lern-
Organisation, Lern-Ziele definieren, Lern-Unterstützung, Kommunikation mit anderen
Benutzern, Termin Planung, Nutzung für den Privaten Bereich (z.B. Facebook), uvm..

Natürlich darf in einer solchen Lernumgebung eine Schnittstelle zu sozialen Netzwerken

wie Twitter oder Facebook nicht fehlen. So bestand die Aufgabenstellung darin einen
Twitter Client zu implementieren, der bei Bedarf in der PLE verwendet werden kann, und
seinen Benutzern eine gute Möglichkeit bietet auf deren Twitter Accounts zuzugreifen.
Eine besondere Bedeutung kommt hier natürlich dem User Interface zu. Da die
Fenstergröße eines Widgets sehr klein ist (ähnlich mobilen Applikationen), beschränkt dies
die Möglichkeit Twitter Funktionen einzubauen. Denn so ein Programm soll natürlich in
erster Linie benutzerfreundlich sein, sprich die Funktionsweise selbsterklärend,
übersichtlich und für jedermann beim ersten Mal bedienbar sein.
Aplication Programming Interfaces (APIs) von sozialen Netzwerken bieten die Möglichkeit
nahezu die komplette Funktionalität des jeweiligen Web 2.0 Dienstes mittels einer eigenen
Anwendung zu implementieren. Beispielsweise dem User die Möglichkeit zu bieten
Einstellungen am Account zu ändern.

3
 Abbildung 1: Ausschnitt PLE Tu Graz

2. Aktueller Stand der Technik

Derzeit bieten die meisten sozialen Netzwerke APIs an, um die Verbreitung ihrer Dienste
voranzutreiben.
So auch die Twitter. Im folgenden Abschnitt möchte ich bereits existierende Widgets und
andere kleine Anwendungen präsentieren, die mit der Twitter Schnittstelle arbeiten. Ich
werde kurz ihre Stärken und Schwächen erläutern und die Unterschiede zur vorliegenden
Arbeit näher beschreiben.

2.1. Hauseigene Twitter Widgets

Zu Beginn möchte ich die von Twitter selbst angebotenen Widgets vorstellen. Sie sind in
der Fußzeile der Twitter Webseite unter dem Menüpunkt Goodies erreichbar. Größtenteils
werden sie von Personen verwendet, welche wenig bis gar keine Programmiererfahrung
haben, denn sie sind einfach zu konfigurieren und schnell in der Applikation oder Webseite
der Wahl einzubinden. Man benötigt weder ein Wissen zur API, noch
Programmiersprachen oder andere spezielle Kenntnisse um diese Dienste zu verwenden.
Ein großes Manko an diesen kleinen Widgets ist, dass sie sehr wenig Funktionalität
bieten, dies bedeutet jedes von Twitter angebotene Widget stellt quasi nur eine Twitter
Funktion dar. Das macht es natürlich unmöglich mit den Widgets sinnvoll zu arbeiten, und
stellt in weiterer Folge keine richtige Verbindung zum Twitter Netzwerk her. Es gibt
beispielsweise das Such-Widget für die Twitter-Suche, ein Profil-Widget um Profile
anzeigen zu können usw. Alleine dadurch kann kein Vergleich zu dem Widget der
vorliegenden Arbeit hergestellt werden, welches alle Twitter Möglichkeiten bietet.
Folgende Widgets werden angeboten:
Profil-Widget: Zeigt letzte Updates auf jeder beliebigen Webseite an

4
Such-Widget: Darstellung von Suchergebnissen einer Anfrage
Faven-Widget: Es werden tweets des Benutzers angezeigt, welche er als Favoriten
markiert hat
Listen-Widget: Man kann Twitter User einer Liste hinzufügen und dieses dann anzeigen
lassen
Konfiguration der Widgets
Hat man sich für eines der vier oben erwähnten Widgets entschieden, wird man durch
einen Konfigurator (Abbildung 2) geführt, welcher einen das Widget nach eigenen
Wünschen zusammenstellen lässt.

Abbildung 2: Konfiguration und Source Code von Widgets

Am Ende kann man sich mit einem Klick auf den Button „Fertigstellen & Code Schnappen“
das fertige Widget in Form von Javascript Code kopieren und in seine gewünschte
Webseite einfügen. [Link 1]

2.2. Twitter für iGoogle

Selbstverständlich werden auch für die personalisierte Google Seite Twitter Applikationen
(Google Gadgets) von verschiedenen Entwicklern angeboten. Es werden drei interessante
Beispiele herausgenommen und näher beschrieben bzw. verglichen.

5
TwitterGadget
Dies ist das meist verwendete Twitter Widget für iGoogle (Abbildung 3). Die
Authentifizierung läuft wie für die meisten Twitter Clients mittels oAuth ab, und dies
geschieht im Prinzip nach dem selben Ablauf wie bei dem Widget der vorliegenden Arbeit..
Dieses Gadget kann ebenfalls in den Gmail Account und Google Chrome eingesetzt
werden.
Die grafische Aufbereitung des TwitterGadget ist schlicht und übersichtlich.
Die Funktionsumfang ist ebenfalls schlicht, es werden viele grundlegende Twitter
Funktionen geboten. Jedoch fehlt beispielsweise die Verwaltung von Followern und
Friends alleine, als auch in Kombination mit Listen. [Link 3]

Abbildung 3: Twitter Gadget für iGoogle

Twitter
Dieses Widget hat keine nähere Bezeichnung als lediglich „Twitter“ und ermöglicht die
Anmeldung mittels oAuth (siehe Kapitel oAuth 14). Negativ wäre zu bewerten, dass dies
nicht über ein pop-up Fenster erfolgt sondern direkt auf jener Seite wo man iGoogle
geöffnet hat. Zurück geleitet wird man jedoch auf die Webseite des Widget Betreibers.
Man verliert also das zuvor noch offene iGoogle Fenster, was bei oAuth unerfahrenen
Benutzern für große Verwirrung sorgen könnte.
Ist man wieder auf die iGoogle Seite zurückgekehrt, zeigt sich ein Widget, welches
grafisch deutlich verbesserungsfähig wäre, worunter natürlich User Interface und
Benutzerfreundlichkeit leiden. Der Werbe-Banner im Kopfbereich sollte an dieser Stelle
auch erwähnt werden. Es werden fast alle Twitter Möglichkeiten geboten, jedoch die
Verwaltung von Listen wurde auch hier nicht implementiert.[Link 4]

6
 Abbildung 4: Twitter für iGoogle
Twitter Reader
Ein wie der Name schon aussagt sehr einfaches Widget Es ist nur möglich Tweets von
Freunden zu lesen (Abbildung 5). Die Anmeldung hier erfolgt nicht über oAuth, dies sollte
aber laut Twitter bereits Standard sein. Außer dem Lesen von Tweets wird keine weitere
Funktion angeboten.

Abbildung 5: Twitter Reader für iGoogle

2.3. Twitter Clients und Desktop Widgets

Im folgenden Abschnitt werden Twitter Applikationen welche für den Desktop Einsatz
erstellt wurden näher betrachten. Da es gerade in diesem Bereich unzählige Twitter
Applikationen gibt, werden nur die bekanntesten näher betrachtet.

Twadget (Windows Vista & 7)

Hier handelt es sich um ein Desktop Gadget für die Windows Vista & 7 Sidebar, welches
sich zeitweise unter den Top 10 der Windows Gadgets einreihen konnte. Es ist einen
Twitter Client der ersten Stunde, erste Versionen erschienen bereits 2007.
Die Installation des Gadgets ist nicht ganz einfach, jedoch mit Hilfe der Anleitung schnell
durchzuführen. Speziell bei Windows 7 kann es hier schnell zu Komplikationen kommen.
Ist das Tool erstmal installiert, ist es durchaus einfach in der Verwendung und gut nutzbar,
auch wenn es nicht den kompletten Twitter-Funktionsumfang bieten kann. Es ist als
Twitter-Stream für den Desktop durchaus empfehlenswert. [Link 4]

7
Tweetdeck
Tweeddeck(Abbildung 6) ist ein übersichtlich und funktionell gestalteter Client, der seinen
Benutzern das Arbeiten mit Twitter entscheidend erleichtert, speziell wenn man mit einer
großen Informationsflut oder mit mehreren Accounts umgehen muss. Dieser Client wird
auch mittlerweile unter anderem für IPhone und IPad angeboten, und kann auch bereits
mit anderen sozialen Netzwerken wie Facebook, Youtube oder Buzz umgehen. Dadurch
verbreitete sich dieses Tool im Vergleich zu unzähligen anderen Twitter Clients relativ
schnell.[Link 5]

Abbildung 6: TweetDeck

Ein besonderes Feature von Tweetdeck ist die Verwendung von mehreren Spalten, deren
Inhalt der Benutzer selbst verwalten und filtern kann(Abbildung 6).
Neben der kompletten Twitter Funktionalität, werden nützliche Erweitrungen wie zum
Beispiel ein URL Shortener zum Kürzen von Webadressen oder eine Verbindung zu
twitPic (Service welches es ermöglicht Bilder auf Twitter zu veröffentlichen) angeboten.
Tweetdeck läuft auf allen gängigen Betriebssystemen, unter der Verwendung von Adobe
AIR. Adobe AIR ist eine Art Laufzeitumgebung, welche entkoppelt vom Betriebssystem
betrieben werden kann.

Turpial (Linux)
Um auch einen Client vorstellen, der nur auf Basis von Linux betrieben wird, viel die Wahl
auf Trupial. Da es eine Applikation ist, die gut durchdacht wirkt, und eigentlich keine

8
Wünsche offen lässt. Das Design besteht nur aus einer Spalte, in der Informationen
dargestellt werden können. Das Tool kann man sehr gut nach eigenen Wünschen
konfigurieren. Beispielsweise die Intervalle der Aktualisierung, Anzahl von Friends,
Followern und Tweets lassen sich vom Benutzer einstellen.
Eine Anbindung an den URL-Shortener bit.ly und an TweetPic muss man hier ebenfalls
nicht vermissen.[Link 9]

Gadfly (Silverlight)
Gadfly ist eine Twitter Applikation die für Microsoft's Silverlight entwickelt wurde. Sie ist
derzeit einer der wenigen Clients, die auf einer Desktop Plattform verwendbar ist, und
nicht Adobe AIR benutzt.
Benutzer können sich diesen Client sowohl im Browser als auch am Desktop einrichten,
wobei die Unterschiede hier eher geringfügig sind. Am Desktop fällt nur das Browser
Fenster weg. Die Anwendung wirkt sehr gut aufgeräumt und benutzerfreundlich. Die
komplette Funktionalität von Twitter wird geboten.
Das User Interface ist ähnlich wie bei TweetDeck in Spalten aufgebaut. [Link 10]

Saezuri (plattformunabhänig)
Saezuri ist ein weiterer plattformunabhängiger Client, der gleich wie TweetDeck auf die
Umgebung von Adobe AIR baut.
Das Layout der Applikation präsentiert sich einfach und übersichtlich. Es sieht den meisten
Clients am ersten Blick sehr ähnlich. Mehrere Accounts zu verwalten ist nicht möglich,
ansonsten werden aber eigentlich alle Twitter Features geboten, auf sehr
benutzerfreundliche Art und Weise.

Skeet (Google Chrome)

Ist eine Erweiterung (Addon) für den Internet Browser Google Chrome. Das Einrichten
dieses Dienstes ist einfach und funktioniert gleich wie bei jedem anderen Addon für den
Browser. Der Client ist dann über ein Icon in der Browserleiste zu erreichen, und zeigt
dem/der Benutzer/in letzte Tweets von Freunden. Diverse Reiter ermöglichen ein
Wechseln zwischen Direct Messages, Replies und Tweets. Volle Funktionalität kann auch
hier nicht geboten werden.
An dieser Stelle möchte ich noch zwei weitere Twitter Clients für Google Chrome
erwähnen. Brizzly und Chrome Bird. Sie können beide aus unterschiedlichen Gründen
(Funktionsumfang, User-Interface, Bedienbarkeit) nicht mit Skeet mithalten.

9
Weitere Clients
Zur Vollständigkeit möchte ich hier noch einige weiteren Applikationen namentlich
erwähnen, welche ich aber nicht näher testen oder betrachten konnte:
● Gwibber: Client für Linux
● Pino: Client für Linux
● Ada: Client auf AIR Basis, minimaler Funktionsumfang
● Multtiple: Client für Windows, Arbeiten mit vielen Reitern möglich
● MyTweets: Client für Windows
● MetroTwit: Client für Windows, in neuer Microsoft „Metro“ - Designlinie
● Twitterbar: Tool um aus der Firefox Adresszeile Tweets zu versenden
● Seesmic Look: Client mit etwas andere Gestaltung und Aufbereitung der
Informationen

Diese Liste könnte noch viel länger sein und müsste eigentlich ständig erweitert werden,
denn der Trend Twitter Clients zu entwickeln hält nach wie vor an.

2.4. Twitter auf mobilen Geräten

Aufgrund der raschen Verbreitung von Twitter Applikationen auf mobilen Geräten und des
enormen Potentials welches in dieser Thematik steckt, wird folgend kurz darauf
eingegangen.
Das Angebot an Applikationen (Apps) für IPhone, IPod und IPad mit Twitter Funktionalität
ist stetig wachsend. Twitter selbst hat durch Übernahme des Clients „Tweetie“ eine
offizielle IPhone Twitter App herausgebracht. Wie bereits oben erwähnt ist der beliebte
Client TweetDeck für fast alle Apple Plattformen verfügbar.
Ähnlich sieht es beim konkurrierenden Betriebssystem Android aus. Das Angebot ist
vielfältig und bietet jedem/er Benutzer/in die Möglichkeit zwischen unterschiedlichsten
Clients zu wählen.

3. Die Umsetzung des Widgets

3.1. Theoretische Grundlagen

Die Twitter API

Eine API (Application Programming Interface) ist eine Programmierschnittstelle, welche
anderen bzw. externen Anwendungen auf das eigene System definierte Zugriffe
ermöglicht. So gut wie alle derzeit verbreiteten sozialen Netzwerke bieten eine solche

10
Schnittstelle an, um sich selbst allgegenwärtig zugänglich und erweiterbar zu machen. Sei
es über externe Webseiten, kleine Desktop- oder Online Widgets/Gadgets, als auch durch
Applikationen für mobile Geräte. Es wird unter einfachen Bedingungen jedem Entwickler
die Möglichkeit geboten mit den Inhalten und Daten dieser sozialen Netzwerke zu
arbeiten, und sie zur Gänze in die eigenen Applikationen einzubauen. Das diese
Möglichkeit auch angenommen wird und sich voll etabliert hat zeigen unzählige
Webseiten, die direkte Verbindung zu Twitter, Facebook oder beispielsweise last.fm
haben. Dies wird auch oft als die dritte Evolutionsstufe von sozialen Netzwerken
bezeichnet.

Ohne einer dieser angebotenen Twitter API wäre die Umsetzung eines solchen Twitter-
Widgets natürlich unmöglich, denn sie stellt alle grundlegenden Funktionen zur Verfügung.
Die Twitter API gilt als sehr beliebte und gemeinsam mit Facebook am weitesten
verbreitetste Schnittstelle sozialer Netzwerke. Sie wird von Entwicklern deswegen so gern
verwendet, da sie als schnell, unkompliziert in der Entwicklung, ausgereift und sicher gilt.
Diese Vorteile bestätigen sich auch im direkten Vergleich zu anderen APIs, beispielsweise
der von Facebook. Viele Entwickler loben auch immer wieder die geringe
Einarbeitungszeit und die absolute Freiheit, die man mit der Twitter API hat.
Weiters ist noch der gute Support zu erwähnen, den man über das Web bekommt. Sei es
durch das Twitter hauseigene Wiki „apiwiki.twitter.com", die Twitter Support Webseite
„dev.twitter.com“, massenhaft vorhandene Foren und Diskussionsgruppen oder durch
Tutorials/Artikel. Gerade seit Sommer 2010 wird vor allem dev.twitter.com von Twitter
selbst erweitert und supported, hie wurde eine gute Anlaufstelle zum Thema Twitter API
eingerichtet. Die API kann mit allen gängigen Programmiersprachen umgehen, einzige
Voraussetzung ist, dass sie HTTP-Anfragen senden kann. Die derzeit am häufigsten
verwendete ist die serverseitige Skriptsprache php, da es hierfür bereits gut ausgereifte
Frameworks gibt(Zend Framework, Abraham's Williams Twitter library), die sehr
brauchbare Funktionen anbieten und gut mit der Twitter Schnittstelle umgehen können.
[1] [2] [3]

Grundsätzlich bietet Twitter drei unterschiedliche APIs an, die REST-API, die Search API
und die STREAMING-API. Unterschiede in der Handhabung gibt es aber kaum, und eine
Kombination aller drei ist problemlos und auch in der Praxis notwendig, um die volle
Funktionalität auszuschöpfen. Die REST API wird zum Senden und Empfangen von
Twitter Daten (Timelines, Benutzer Informationen, usw.) verwendet, die Search API für
sämtliche Twitter Suchfunktionen (Personen, Tweets, Listen) und die Streaming API bietet
die schnellste Möglichkeit Tweets zu aktualisieren.
Der Entwickler kann selbst entscheiden in welchem Format er eine Anfrage beantwortet
haben möchte, Twitter bietet folgende Möglichkeiten an: RSS, xml, json und Atom
(Abbildung 7). Hier muss erwähnt werden, dass nicht alle Methoden in jedem Format

11
erhältlich sind, Details sind in der Dokumentation ersichtlich. Ein Beispiel einer Antwort für
User Informationen von der API im Json Format wäre:

Abbildung 7: Antwort der API im Json Format

Eine doch recht gravierende Einschränkung gibt es bezüglich der Anfragen, denn Twitter
erlaubt pro Client eine gewisse Anzahl an Requests in der Stunde. Dies hängt von der
verwendeten Authentifizierung ab. Bei einer Anmeldung mit oAuth sind 350 Anfragen in
der Stunde erlaubt- Dies ist für einen durchschnittlichen Benutzer ausreiched, allerdings
kann bei außergewöhnlicher Benutzung das Maximum schnell erreicht sein. Dies löst auch
in diversen online – Communities immer wieder grobe Kritik an der API aus.
Die API bietet mittlerweile so gut wie die gesamte Funktionalität an, die auch auf der
Twitter Webseite zu finden ist, Beispiele wären:
– Tweets, Retweets, Direct Messages
– User folgen, Follower bearbeiten, Zeitleisten anzeigen, Details anzeigen
– Listen erstellen, verwalten, löschen
Einzig das Erstellen von Twitter Accounts ist über die API derzeit noch nicht möglich, über
eine Lösung wird laut dev.twitter.com aber bereits nachgedacht und diskutiert.
Auf die genaue Funktionalität und Code-Beispiele wird weiter unten im Kapitel „Umsetzung
Praxis“ genauer eingegangen.
Ein weiterer Vorteil der API ist es, dass sie mit dem Authentifizierungsprotokoll oAuth
umgehen kann, welches unter anderem speziell für Twitter mitentwickelt wurde (siehe
Kapitel Authentifizierung).[2] [3] [4]
Grundsätzlich ist dem Arbeiten mit den Informationen von Twitter keine Grenzen gesetzt.

12
Dennoch möchte Twitter, dass sich jeder Entwickler an gewisse Regeln hält:[2]
• Don't suprise User:
Man darf auf keinen Fall Informationen von Benutzern ändern, verfälschen und in
andere Art und Weise übertragen oder darstellen als im originalen Zustand.
• Don't create or distribute spam:
Diese Regel untersagt sowohl das Verbreiten von Spam als auch von bösartiger
Software, pornografische und gewalttätige Inhalten.
• Respect User privacy and be a good partner to Twitter:
Man sollte Benutzerinformationen wie Passwörter und Tokens nur unter sicheren
Bedingungen speichern. Man muss mit sämtlichen Informationen diskret umgehen
und darf sie nicht veröffentlichen. Weiteres sind speziell bei der Kommunikation mit
der API Regeln zu beachten, die Twitter vorgibt, diese sind auf der Webseite
ausreichend erläutert. [2]

Abbildung 8: dev.twitter.com, Dokumentation zur API

MVC Pattern
Das MVC Pattern (Model-View-Controller) ist ein Architekturmuster in der
Softwareentwicklung zur Kapselung des Codes in drei Komponenten: in das Datenmodell,
die Datenrepräsentation und die Geschäftslogik (Abbidlung 9). Grundsätzlich zielt das
Pattern darauf ab maximale Übersicht und Flexibilität zu erreichen, und findet
hauptsächlich in mobilen Applikationen, Webanwendungen und kleinen Programmen, wie
Widgets Anwednungen. Flexibilität bedeutet gute Wartbarkeit, Erweiterbarkeit und
Lesbarkeit der einzelnen Komponenten. Wie die drei Einheiten im Detail aussehen hängt
sowohl stark von der Umsetzung ab, als auch von der verwendeten Programmiersprache.
Für Webanwendungen hat sich das MVC Pattern in den letzten Jahren als Standard
durchgesetzt. Für das Twitter Widget wird das Pattern in Javascript umgesetzt (Details:
siehe praktische Umsetzung). Folgende Aufgaben sind jeder Komponente zuzuteilen:
• Controller (Programmsteuerung)

13
 Ist grundsätzlich für die gesamte Programmsteuerung zuständig, kommuniziert mit
dem Modell und View. Es ist auch möglich, dass ein Controller mit mehreren Views
arbeitet, jedoch kennt er immer nur ein Modell. Interaktionen, die der Benutzer in der
Präsentation tätigt nimmt der Controller entgegen und verarbeitet diese
dementsprechend (z.B. sende Twitter Request). Das Initialisieren der anderen zwei
Module findet ebenfalls hier statt. Daten dürfen hier auf keinen Fall bearbeitet und
ausgegeben werden. Controller und Präsentation bilden zusammen das Strategie
Pattern.
• View (Präsentation)
Die Komponente View hat im Prinzip zwei wichtige Aufgaben. Erstens die
entsprechenden Daten zu präsentieren, und zweitens Benutzerinteraktionen entgegen
zu nehmen und der Programmsteuerung weiterzugeben. Je nach Interpretation des
MVC Patterns kann die Präsentation mit dem Modell und dem Controller, oder nur mit
dem Controller kommunizieren. In diesem Falle arbeitet sie ausschließlich mit der
Programmsteuerung.
• Model (Datenmodell)
Die Einheit Model ist zum Speichern der erlangten Daten zuständig unabhängig von
deren Herkunft. Diese Informationen könnten aus Benutzereingaben oder HTTP-
Requests stammen. Die Programmsteuerung gibt Daten, die zu einem späteren
Zeitpunkt wieder benötigt werden an das Modell weiter, um sie dort zu speichern
(chachen). Dies spielt im Falle des Twitter Widgets eine bedeutende Rolle, so dass auf
Daten immer wieder zugegriffen werden kann, und nicht ständig neue Ajax-Requests
an die API geschickt werden, da diese Anfragen erstens zeitaufwendig und zweitens
durch die API in ihrer Anzahl begrenzt sind. Diese Komponente spricht mit keiner
anderen.[5]

Abbildung 9: MVC-Pattern
Authentifizierung
Die Authentifizierung in Verwendung mit der Twitter API spielt natürlich eine sehr wichtige
Rolle. Sie muss in erster Linie dem Benutzer eine sichere Verbindung zu Twitter
ermöglichen, als auch benutzerfreundlich und leicht zu handhaben sein.
Die Twitter API bot grundsätzlich verschiedenste Möglichkeiten der Authentifizierung

14
(teilweise auch abhängig von der Programmiersprache). Jedoch gab Twitter im Frühling
2010 bekannt, dass oAuth der Standard für den Login zur Twitter API ist, und alle anderen
Protokolle ab dem Sommer 2010 nicht mehr unterstützt werden.

oAuth
oAuth ist ein offenes, standardisiertes Protokoll, welches sichere API – Zugriffe
verschiedenster Dienste ermöglicht. Es wird derzeit vor allem für diverse Web- und Mobile
Applikationen eingesetzt, und gilt als sicherer Standard welcher 2006 von Blaine Cook
(arbeitete an OpenID für Twitter), Chris Messina und Larry Halff entwickelt wurde. Alle drei
arbeiteten damals an API Authentifizierung für unterschiedliche Dienste, und waren sich
einig, dass es zu diesem Zeitpunkt keinen sicheren Standard hierfür gibt.
Der Grundgedanke hinter diesem Protokoll besteht darin, dass der Benutzer Zugriff auf
seine Daten (z.B. seinen Twitter Account) bekommt ohne seine Benutzerdaten der
Applikation bekannt zu geben. Er benutzt dann sozusagen die Anwendung „anonym“,
ohne seine Identität preis zugeben. Dies spricht natürlich sicherheitsbewusste Benutzer
an, diese würden natürlich nie einer fremden Anwendung Ihren Benutzernamen in
Kombination mit dem Passwort überlassen. Ein weiterer Vorteil besteht darin, dass der
Anwender bei einem Passwortwechsel sämtliche API-Applikationen nicht mehr darüber
informieren muss. [6] [7]
In diesem Zusammenhang sind folgende standardisierte oAuth-Begriffe bekannt:

Service Provider: Ist jenes Webservice oder jene Website, von der aus der Zugriff
stattfindet. Der Anbieter ist für die sichere und korrekte Umsetzung von oAuth
verantwortlich. Bei ihm liegen auch die Informationen der Benutzer.
Consumer: Ist eine Applikation, welche Zugriff auf Daten des Benutzers erlangen möchte.
Protetcetd Resouces: Sind jene Informationen, die durch das Protokoll geschützt werden
sollen, hierbei kann es sich um Daten, Bilder, Dokumente usw. handeln.
Token: Ist eine Zeichenkette, die an Stelle von Benutzername und Passwort zum
Anmelden verwendet wird. Es wird zwischen Zugangs- und Abfrage-Token unterschieden.

Einsetzen von oAuth

1. Das Widget bei Twitter registrieren und identifizieren
Jede Anwendung, die über oAuth mit der Twitter API arbeitet, muss sich bei Twitter
registrieren (http://dev.twitter.com). Man erhält einen Consumer-Key und ein Consumer
Secret. Diese zwei Zeichenketten sind für jeden späterem Informationsaustausch von
Bedeutung, denn sie identifizieren die Anwendung.

2. Access – Token für Benutzer holen

Jeder Benutzer, der das Widget nun verwenden möchte, muss sich einen Access-Token
holen, dazu wird er auf die Webseite von Twitter geleitet, wo er gefragt wird, ob er dem
Wiget API-Zugriffe erlauben möchte. Er bestätigt dies durch Eingabe seines Twitter-

15
Usernamen und Twitter-Passwort. Er wird sofort zu der Applikation zurück geleitet, wo er
nun mit Token und Verifyer Zugang zu seinem Account bekommen kann.

Es wurde für den oAuth Zugriff mittels php das Zend Framework 1.10 verwendet, da die
Kommunikation mittels oAuth recht aufwendig, jedoch aber standardisiert ist. [6]

16
3.2. Praktische Umsetzung

Aufbau und Struktur der Applikation

Im folgenden Abschnitt wird der Aufbau des Widgets, die Ordner Struktur erklärt

Abbildung 10: Ordnerstruktur der gesamten Applikation

Abbildung 11: Das Twitter Widget

(Abbdilung 10), sowie die Aufgabe der einzelnen Komponenten und Dateien.
• Index.html
Wie der Name schon sagt, handelt es sich hier um die Repräsentationsseite des
Widgets. Der gesamte Inhalt wird hier repräsentiert, alle Informationen werden mittels
Javascript dynamisch geladen.
• twitter_style.css
Hier wird das Design des Widgets definiert.
• Config.xml
Dieser Datei kommt eine besonderer Wichtigkeit zu, denn hier werden die
Einstellungen definiert unter welchen das Widget in der gesamten Umgebung
ausgeführt wird. Unter anderem wird hier die grafische Größe des Widgets (width,
height) definiert sowie die ID unter welcher die Applikation in der PLE erkannt wird.
Alle Einstellungsmöglichkeiten für Endbenutzer sind hier dauerhaft gespeichert und

17
 können jederzeit geändert werden.
• Loader.gif
Animiertes Bild welches während des Ladeprozesses angezeigt wird.
• Ordner libs (Clientseitiger Code)
Hier liegt der Sourcecode des Widgets (Javascript) in Form des MVC Patterns, auf
welches im Kapitel „Praktische Umsetzung“ näher eingegangen wird. Jquery Dateien
sind hier ebenfalls zu finden.
• Ordner server (Serverseitiger Code)
Hier befindet sich der serverseitige Code (php). Die php Klasse twitterAPI bietet alle
benötigten Methoden um mit der TwitterAPI zu kommunizieren, und gilt somit als
Schnittstelle zwischen dem Client und Twitter. Diese Methoden werden über die Datei
Main.php aufgerufen, welche einen GET-Parameter als Kriterium für den
Funktionsaufruf hat. Die Klasse TwitterAPI ist auch für den gesamten
Authentifizierungsprozess über oAuth zuständig. Im Ordner „Zend“ befinden sich die
benötigen Dateien des Zend Frameworks.

Authentifizierung
Wie oben bereits erklärt läuft die Authentifizierung mittels dem
Sicherheitsprotokoll oAuth (Abbildung 12) ab, welches seit
August 2010 als alleinige Möglichkeit der Identifikation und
Registrierung für die Twitter API gilt.
Jede/r Benutzer/in des Widgets muss bei dessen erstmaliger
Verwendung folgenden Schritte tätigen:
Öffnet ein/e Benutzer/in das Twitter Widget, wird ihm die Abbildung 12: oAuth Logo
genaue Durchführung der Registrierung und Anmeldung
beschrieben. Klickt er auf den Link für die Anmeldung, öffnet sich ein Pop-Up in dem direkt
die Funktion oAuth der Klasse twitterApi aufgerufen wird. Diese nimmt die Weiterleitung
auf die Twitter Webseite mit Hilfe des Zend-Frameworks vor.
Nach dem erfolgreichen Eintragen des Benutzernamens und des Passwortes auf der
Twitter Webseite (Abbildung 13), schließt sich das Pop-Up Fenster automatisch und der
Zugangstoken wird als URL-Parameter an die Applikation übergeben und kann nun
gespeichert werden (in Datenbank, oder ähnlichem). Ab diesem Zeitpunkt braucht sich der
Benutzer keine Gedanken mehr über die Anmeldung zu machen, denn Token und Verifyer
sind nun auf Dauer gespeichert und müssen eigentlich nie wieder geändert werden. [7]

18
 Abbildung 13: oAuth: Anmeldung auf Twitter Seite

Bei jedem Aufruf des Widgets wird als Erstes überprüft ob der User bereits die oben
beschriebene Anmeldung durchgeführt hat, wenn nicht, wird ihm wiederum die Login Seite
des Widgets über die Komponente View angezeigt. Sollten bereits Eintragungen
vorhanden sein, werden diese im Controller als Membervariablen (Abbildung 14)
gespeichert, und dem User die Startseite des Widgets präsentiert.

Abbildung 14: Funktion onLoad() in index.html

Initialisierung und grundlegende Abläufe

Bei der Initialisierung des Widgets (Controller.init()) (Abbdilung 15) wird der Parameter
time übergeben. Dieser legt den Intervall in Minuten fest in dem das Widget Daten
aktualisieren soll, sprich eine Anfrage an die API senden soll. Dieser Intervall ist vom
Endbenutzer definierbar. Er/Sie kann ihn über die Einstellungen des Widgets eintragen
(per default: 3min). Informationen werden grundsätzlich in drei Fällen aktualisiert:
1. Wenn der angegeben Zeitintervall abgelaufen ist (time)
2. Wenn sie noch nie geladen wurden
3. Wenn der User eine Aktion setzte, um ihm zu zeigen, dass sie erfolgreich war (z.B.
Liste erstellen)

19
Im nächsten Schritt werden die Benutzerinformationen des angemeldeten Users mittels
des ersten API-Requests geladen und im Kopf des Widgets angezeigt

Abbildung 15: Funktion init() in Controller.js

(Funktion: interFace.userInformation(false)). Weitere Informationen dazu siehe Kapitel

API-Requests. Sollten Benutzerdaten nicht übereinstimmen oder nicht eingetragen sein,
wird an dieser Stelle wieder die Login Seite angezeigt.
In jedem Fall wird aber zuvor die View initialisiert (View.init()). Im folgenden Abschnitt
werden grundlegende Abläufe und diverse Ausgaben der View näher beschrieben:

Abläufe der View

Zu Beginn werden sofort mittels jQuery sämtliche Divs als Membervariablen festgelegt,
damit man später rasch auf sie zugreifen und ein- und ausbleden kann. Somit müssen sie
nicht jedes mal neu erstellt werden. Das bedeutet jede mögliche Seite des Widgets hat
einen eigenen Div-Container (z.b Follower, Following, Listen, Timelines, Search Results,
usw.) (Abbdilung 16).

Abbildung 16: Funktion: init() in View.js

20
Ebenfalls noch während der Initialisierung der View wird den Buttons im Kopfbereich die
Funktionalität gegeben. Die meisten werden natürlich mit Funktionen (Requests) im
Controller auf Benutzeraktionen reagieren, um Daten aus der API zu laden. Zuvor werden
alle anderen Bereich ausgeblendet (clearContent()). Der Parameter false, der an die
Funktionen im Controller übergeben wird bedeutet in diesem Falle, dass der Benutzer
keine Änderung der Daten vorgenommen hat, und die Informationen nicht von der API
sondern aus dem Modell zu holen sind (außer das Zeitintervall ist abgelaufen).

Abbildung 17: Funktionen der Buttons im Kopfbereich

Das bedeutet, der aktuelle Inhalt wird bei einem Klick einfach ausgeblendet, und der neue,
aktuelle eingeblendet, außer es gibt etwas zu aktualisieren, dann wird das neue Div
beschrieben. Wird ein Div lediglich eingeblendet, sind Funktionen in der View die mit dem
Namen „show“ beginnen zuständig. Ist ein Inhalt auszutauschen, beginnen die
Funktionsnamen mit „print“ (Vergleich: showFollower(), printFollower()).

DM, RT und @
Direct Messages (DM), Retweets (RT) und Replys(@) sind Link Lables, die unter jedem
angezeigten Tweet (Abbdilung 18) vorhanden werden und dem Benutzer einige
Möglichkeiten bieten.
Der Link DM ist zum Versenden von privaten Nachrichten an andere Benutzer. Dazu wird
„D @Username“ in das Textfeld für Tweets geschrieben
(interFace.prepareDirecetMessage()). Anschließend muss nur noch die gewünschte
Nachricht angefügt werden. Die Message kann dann auf dem selben Weg wie ein
„normaler“ Tweet versendet werden. Die API identifiziert dann die Nachricht als DM selbst,
und sendet sie an den gewünschten Empfänger. Genauso bei Replys (Tweets an einen
gewissen User).

Abbildung 18: ein Tweet

21
Retweets können vom User nicht weiter bearbeitet oder geändert werden und werden
sofort mittels eigener API Funktion versendet.
Dadurch stellt der Button „tweet“ (Abbdilung 19) eine Besonderheit dar, er besitzt spezielle
Funktionalität:

Abbildung 19: Funktion: click des "tweet" Buttons

Hier ist zu überprüfen ob das Textfeld leer ist, speziell zu beachten sind hier Direct-
Messages und Retweets. Will ein/e Benutzer/in eine private Nachricht an einen anderen
senden, wird das Textfeld für die Tweets mit einem „D“ beschrieben, nach dem Zeichen
kann er nun seine Nachricht schreiben (Abbildung 20). Das gleiche Prinzip wird auch bei
Replys angewandt. Hier wird „@“ in das Textfeld eingetragen. Natürlich ist in beiden Fällen
zu überprüfen, ob nach den Zeichen (D, @) auch wirklich eine Nachricht eingetragen ist,
ansonsten darf der Tweet nicht versendet werden.

Abbildung 20: Funktionen: DM und Replys

22
Ausgeben neuer Informationen
Sind Informationen gerade neu von der API übermittelt worden, müssen sie natürlich
dargestellt werden. Das alte Div wird hierfür gelöscht und gleich darauf neu beschrieben.
Grundsätzlich laufen alle „print“-Funktionen nach dem selben Muster ab. Anhand des
Beispiels „printFollower(follower, headline)“ (Abbildung 21) möchte ich nun das
Beschreiben eines Divs kurz erläutern:

Abbildung 21: Funktion: printFollower(), Darstellung der Follower und beschreiben des Divs

Alle aktuellen Inhalte (andere Divs) werden ausgeblendet (clearContent()). Der zu

23
beschreibende Container wird gelöscht, und gleichzeitig wieder eingeblendet. Der letzte
Inhalt (last_content) wird auf 3 gesetzt, um in weiterer Folge den „zurück“ Button zum
richtigen Ziel zu führen. Mit makeHeadline() wird eine neue Überschrift erzeugt. Parameter
sind: Die Überschrift, die Größe und das Div wo sie angezeigt werden soll. Durch die
Variable Area wird das zu beschreibende Div festgelegt, und dann werden die Json Daten
des API Requests mit einer „for“ - Schleife durchlaufen und angezeigt.

Funktionen und Requests im Controller

Wie bereits genauer beschrieben hält der Controller die Programmsteuerung und
kommuniziert mit Model als auch mit der View. Dadurch werden hier die grundlegenden
Abläufe definiert. Hier ist auch der gesamte Programmablauf am einfachsten zu erkennen.
Der Controller besitzt ein Modul „Helper“ als Sandbox, dessen Aufgabe es ist Ajax-
Requests zu versenden. Der Controller hält die drei Zeichenketten für die Authentifizierung
als private Member (token_, verifyer_, user_id_), welche bei jeder Server Anfrage mit
übergeben werden.
Jede API Anfrage wird durch eine eigene Funktion im Controller repräsentiert, ich möchte
an Hand folgender Beispiele ein paar verschiedene Methoden erläutern:

Abbildung 22: Funktion: UserInformation() im Controller

Die Funktion interFace.userInformatione() (Abbildung 22) ist die erste Methode, die beim

24
Öffnen des Widgets aufgerufen wird und führt dadurch den ersten API-Request aus. Sie
holt die User Informationen des eingeloggten Benutzers, und stellt diese dann im
Kopfbereich des Widgets dar. Deshalb besitzt sie auch spezielle Funktionalität.
Die erste „if“-Bedingung sieht bei allen Request-Funktionen des Controllers ähnlich aus.
Diese Abfrage soll überprüfen ob Informationen neu zu laden, oder einfach aus dem
Modell zu holen sind. Trifft ersterer Fall zu, wird das Ladebild eingeblendet, und der
Request mittels Helper versendet. Funktionsparameter sind: die Login-Daten, ein String
(„userinformation“) zur Identifikation im Servercode, die Callback-Funktion (wird beim
Eintreffen der Daten aufgerufen) und die User ID des Twitter Users von welchem
Informationen angefordert werden. Im ersten Aufruf ist das natürlich der angemeldet
Benutzer selbst.
Die Callback-Funktion ist ebenfalls bei vielen Controller Methoden gleich. Hier wird der
nächste Schritt nach dem positiven Empfangen der Informationen definiert und wie dies
durch die View dargestellt werden soll. Im Falle der Funktion userInformation() wird als
Erstes abgefragt, ob der Server einen Fehler retourniert, wenn ja, wird dieser ausgegeben.
Ein zweite Fehlermöglichkeit besteht darin, dass die empfangenen Daten keinen Namen
enthalten (screen_name), dann ist davon auszugehen, dass es ein Problem mit
Anmeldeinformationen gegeben hat und dem Benutzer wird die Anmeldeseite erneut
gezeigt. Hat alles ordnungsgemäß funktioniert („else“–Fall), werden die Benutzerdaten im
Header ausgegeben, im Model gespeichert und die nächste Methode
directMessages(true) aufgerufen. Sie repräsentiert den nächsten Schritt im Aufbau des
Widgets und lädt die empfangenen privaten Nachrichten des Benutzers. Nach dem
erfolgreichen Laden der Direct Messages, werden Retweets und letzte Statusmeldungen
der Friends („FriendsTimeLine“) nach dem selben Ablauf geladen. Diese Schritte sind das
Zusammenstellen der Startseite, können aber jederzeit durch Klick auf den „Home“ Button
wiederholt werden.

Abbildung 23: Funktion: _sendRequest(), im Helper des Controllers

25
Der Helper (Abbildung 23) ist zum Versenden sämtlich Ajax-Requests mittels jQuery
zuständig. Die GET–Parameter TOKEN und VERIFYER wurden bereits ausführlich
erläutert. ACTION legt die Aktion fest die vom serverseitigen Code ausgeführt werden soll.
INFOS, INFOS2 und DATA3 sind spezielle Parameter für die Twitter API. Diese werden
nicht immer alle benötigt, hier könnten beispielsweise Namen einer neuen Liste, ID des
Users welchen man folgen will, ID des Tweets den man löschen möchte, usw. übergeben
werden.

Model
Die Komponente Model besitzt Getter- und Setter-Methoden für sämtliche möglichen
Datensätze die im Wiget dargestellt werden können. Passend zu jedem Datensatz wird in
der Setter-Methode der Timestamp (akutelle Zeit) abgespeichert, der über die Getter-
Methode später abgefragt werden kann, um zu wissen ob die Daten zu aktualisieren sind.

Abbildung 24: Ausschnitt aus Model

Server

26
 Abbildung 25: Ausschnitt aus Main.php

Der Server ist für die tatsächliche Kommunikation mit der Twitter API zuständig, die er
mithilfe des Zend-Framworks ausführt. Dann werden sämtliche Antworten von Twitter im
Json Format ausgegeben. Alle Requests werden über die Main.php aufgerufen, wo mittels
dem Parameter ACTION entschieden wird welche Funktion der Klasse twitterAPI
ausgeführt werden soll. Sind die fünf GET Parameter nicht definiert worden, wurde die
Main.php durch die oAuth Rückleitung aufgerufen. Über die Funktion oAuth() der Klasse
twitterAPI werden dann die Zugangsdaten für den Benutzer gespeichert.
Wurde im Switch-case Block der passende Fall gefunden, wird in der jeweiligen Methode
von twitterAPI.php die Anfrage an die Twitter API vorbereitet und ausgeführt.

Abbildung 26: Konfiguration zur Identifizierung des Clients

Um überhaupt mit der API arbeiten zu können, muss man gewisse Informationen
(Abbildung 26) bei jeder Anfrage übergeben. Diese Daten erhielt man bei der
Registrierung der Applikation auf der Twitter Seite. Twitter benötigt diese Informationen um
die Anwendung zu identifizieren. Sie werden als Konstanten in der Config.php gespeichert,
und müssen eigentlich nie geändert werden. Das $configuration-Array ist eine
Membervariable der Klasse twitterAPI.
Anhand der Funktionen getFriendsTimeLine(), userInformation() (Abbildung 27) werden

27
nun Requests an die Twitter API näher erklären. Diese Anfragen sehen in allen Fällen sehr
ähnlich aus und unterscheiden sich nur durch die URL, die mittels HTTP Anfrage
angesteuert wird und den Parametern, die übergeben werden. Es wird ein Objekt des
Types oAuth_Token_Access des Zend Frameworks angelegt, Token, Verfiyer und das
oben erläuterte configurationArray werden gesetzt.
Die Funktion setUri() legt die API Funktion als HTTP-Requests fest. Mittels der Methode
setParamterGet() können der API noch weitere Parameter übergeben werden, diese
können auch mehrere sein, mittels request() wird die Anfrage versendet. Die Antwort wird
via print() im Json Format zurückgegeben und die Informationen können dann in der
Callback Funktion in Javascript weiter bearbeitet werden.

Abbildung 27: Funktionen: UserInformation(), getFriendsTimeLine() der Klasse twitterAPI

4. Anwendungsbeispiel/Diskussion

4.1. Anwendungsbeispiel
Im folgenden Kapitel möchte ich kurz an Hand der folgenden Beispiele die Funktionen des
Widgets näher erklären:

28
Die Startseite:
1) Menüleiste:
Follower: Personen die mir folgen
Following: Personen denen ich folge
Search: Suche nach fremden Usersn
Lists: Zum Verwalten und Erstellen von Listen
2) Kopfbereich:
Benutzername des eingeloggten Users und seine
letzte Statusmeldung
3) Dms Rts:
Dms: Direktnachrichten an mich
Rts: Retweets von mir, können gelöscht werden
4)Textfeld zum Versenden von Tweets, Dms und
Replys
5)Friends Timeline:
Die letzten Statusmeldungen von Personen
denen ich folge. Hier können eigene Tweets
gelöscht werden (Delete).
@: Reply – Tweet an einen User (über das Tweet
Textfeld)
DM: Direktnachricht an einen User (über das
Tweet Textfeld)
RT: Retweet zu diesem Tweet (wird dirket
versendet)
Friends/Follower:
1) Überschrift:
Anteil der angezeigten Users an der
Gesamtanzahl der Freunde.(Twitter kann max.
100 übergeben)
2) User:
Timeline: Zeigt die Zeitleiste eines Users
Profile: Zeigt Profil mit allen Details eines Users
Add to List: Zum Hinzufügen des Users zu einer
Liste, vorhandene Listen werden dann zum
Auswählen angezeigt
DM: Direktnachricht an einen User

Lists:
1) create List: zum Erstellen einer neuen Liste,
welche danach sofort dargestellt wird
2) Vorhandene Listen:
Bereits erstellte Listen werden angezeigt.
Members: User die sich in der Liste befinden
Subscribers: User die der Liste folgen
Nach Klick auf den Namen der Liste wird die
Timeline der Liste angezeigt, sprich die
Statusmeldungen der User die in der Liste sind.

29
Weiteres werden folgende Möglichkeiten
geboten:
Delete List: Ganze Liste wird gelöscht
Remove from List: User wird aus der Liste
entfernt.

4.2. Diskussion
Grundsätzlich kann man sagen, dass die gesetzte Ziele erreicht wurden. Das Widget
wurde wie von Anfang an geplant in Optik und Funktionsumfang umgesetzt. Es mussten
während des Arbeitsablaufes keine größeren Kompromisse eingegangen werden.
Erfahrungen aus der Testphase und Vergleiche mit anderen Twitter Clients und
Anwendungen zeigen, dass das Ergebnis benutzerfreundlich und gut einsetzbar ist.
Selbstverständlich kam es während der praktische Umsetzung auch zu kleineren
Komplikationen, die mit Sicherheit auf Unerfahrenheit speziell im Umgang mit APIs
zurückzuführen sind. Obwohl das Einlesen in die Twitter API als eher einfach gilt,
benötigte dies in meinem Fall eine längere Zeitspanne, da ich noch nie mit einer
derartigen Schnittstelle gearbeitet habe. Zu Problemen kam es beispielsweise bei der
Implementierung der Authentifizierung:
Als mit der Arbeit im Frühjahr 2010 begonnen wurde, gab es für die API mehrere
Möglichkeiten der Anmeldung für Benutzer. Das eine Anmeldung mittels oAuth von Twitter
später vorgeschrieben werden sollte, war zu diesem Zeitpunkt noch nicht bekannt und
dadurch wurde die anfänglich die Authentifizierung mittels cUrl umgesetzt. Als dann
feststand, dass oAuth alle anderen Protokolle ablösen wird, musste ich natürlich nicht nur
die Anmeldung ändern, sondern auch die komplette serverseitige Kommunikation mit der
Twitter API, da man durch oAuth einen ganz anderen Zugang bekam.
Eine spezielle Vorsicht muss im Umgang mit der API geboten sein. Denn obwohl sie sich
in diesem Belangen enorm verbessern konnte, kann es bei retournierten Informationen
nach wie vor zu Problemen kommen. Obwohl ein Fehlverhalten sehr selten auftritt, muss
es jedoch vom Client behandelt werden. Grundsätzlich gilt, dass man mit allen möglichen
Ergebnissen auf Anfragen rechnen muss. Die richtigen Daten im richtigen Format, das
richtige Format ohne/mit falschen Information, ganze „sinnlose“ html Seiten,
Fehlermeldungen und Timeouts könnten durch die API jederzeit retourniert werden.
Manche Informationen werden durch Twitter auf besondere Art und Weise repräsentiert
und brauchen dadurch eine spezielle Behandlung. Beispielsweise sämtliche Zeitpunkte
werden von Twitter mit einer Stunde Vorsprung gegenüber unserer Zeitzone übergeben,
im Falle von Sommerzeit beträgt der Vorsprung sogar zwei Stunden und muss deswegen
vom Entwickler dementsprechend angepasst werden.
Nach dem die Kommunikation mit der API funktionierte und das Grundgerüst der
Applikation fertig war, kam die zeitlich sehr aufwendige Optimierung des Widgets. Diese
Phase bestand aus: Performance Verbesserung, User Interface Verbesserung, Design
Verbesserung und Browser Differenzen auszugleichen. Diese Optimierungsphase dauerte

30
bis zum Schluss der praktischen Umsetzung und ging Hand in Hand mit dem Testen.

5. Zusammenfassung und Ausblick

5.1. Zusammenfassung
Ziel der vorliegenden Arbeit war es, ein Twitter Widget für die Personal Learning
Environment der Tu Graz zu implementieren und so ihren Benutzern Zugang zum sozialen
Netzwerk Twitter über das Widget zu ermöglichen. Die Ausbreitung dieser Netzwerke über
das gesamte Internet durch die Verwendung ihrer APIs läuft derzeit ungebremst. Social
Learning ist wichtiger Bestandteil des E-Learnings, und so ist die Möglichkeit einer
Anbindung an Netzwerke wie Facebook oder Twitter unerlässlich.
Die Schnittstelle zum Twitter Netzwerk, die so genannte Twitter-API, gilt als sehr
„entwicklerfreundlich“ und ist dementsprechend in der Community beliebt. Gründe dafür
sind,dass das Einlesen nur wenig Zeit in Anspruch nimmt, die Funktionalität sehr gut
dokumentiert und durch Beispielen beschrieben ist. Weiteres gilt die API als sehr
verlässlich und ermöglicht dem Benutzer eine Authentifizierung mittels oAuth. Dieses
Authentifizierungsprotokoll bringt in erster Linie den Vorteil, dass sich Benutzer über die
externe Anwendung anonym einloggen. Sie müssen dem Betreiber der Applikation weder
den Benutzernamen noch das Passwort bekanntgeben, sondern sich lediglich direkt auf
der Twitter Seite registrieren.
Da es sich um ein Widget handelt, war ein primäres Ziel größtmögliche
Benutzerfreundlichkeit zu erreichen unter der Voraussetzung, dass die wichtigsten Twitter
Funktionen dem User angeboten werden.
Die API arbeitet mit normalen HTTP-Requests, welche mittels der Scriptsprache php
realisiert wurden. Das Widget selbst wurde ausschließlich in Javascript umgesetzt. Daten
werde durch Ajax-Requests vom serverseitigen Code geladen. Das verwendete
Strukturmuster war das MVC Pattern, welches heutzutage in den meisten Mobilen-, Web-
und Widgetanwendungen Verwendung findet. Die Verwendung dieses Musters zielt auf
beste Wartbarkeit, Erweiterbarkeit und Übersicht ab.
Dem/r Benutzer/in des Widgets wird folgende grundlegende Twitter Funktionalität
angeboten:
• Tweets versenden
• Die Zeitleiste seiner Freunde anzeigen lassen
• Direct Messages, Replys, Retweets versenden
• Direct Messages, Retweets, Tweets verwalten und löschen
• Follower und Friends anzeigen und bearbeiten
• Nach Twitter Usern suchen
• Profile, Zeitleisten einzelner User anzeigen

31
 • Listen erstellen, löschen, verwalten

5.2. Ausblick
Die Ausbreitung sozialer Netzwerke wird sicher noch eine Zeit lang in dem gleichen
rasanten Tempo voranschreiten, wie sie es bis heute getan hat. Der Einsatz von APIs
unterstützt die Ausbreitung dieser Netzwerke über das gesamte Internet weiter kräftig.
Netzwerke verbinden sich untereinander und gleichzeitig mit diversen externen
Anwendungen und Webseiten. Dadurch werden sich Informationen die über Netzwerke
wie Twitter übertragen werden in Art und Eigenschaften ändern. Das hat zur Folge, dass
sich Clients wie das Twitter Widget anpassen und erweitern werden müssen. Ohne diese
Anpassungen würden sie auf Dauer für Benutzer uninteressant und nutzlos werden.
Spezielle Erweiterungen für dieses Widget könnten aus Trend- und Analyse Funktionalität
hervorgehen, welche auch immer mehr in die API eingebunden wird. Andere
Erweiterungen könnten im Umgang von Daten wie Bildern und Videos durchgeführt
werden. Denn diese Objekte werden möglicherweise in den Tweets von morgen zu finden
sein.
Es muss jedoch immer beachtet werden, dass es sich um ein Widget für die schnelle
Nutzung handelt, und deswegen darf die Applikation zu keinem hoch komplizierten Twitter
Client werden.

Ob Twitter, Facebook oder StudiVZ , APIs sozialer Netzwerke werden ihren Siegeszug mit
Sicherheit fortsetzen und ihren Benutzern enorme Möglichkeiten auf den
unterschiedlichsten Plattformen bieten.

32
6. Literatur
1: Diving into the Twitter API, 2010, http://net.tutsplus.com/tutorials/other/diving-into-the-
twitter-api/, Zugriff: 10.7.2010
2: dev.twitter.com, Things Every Developer Should Know,
http://dev.twitter.com/pages/every_developer, Zugriff: 20.11.2010
3: Kevin Makice, Twitter API: Up and Running: Learn How to Build Applications with the
Twitter API. ISBN: 0596154615, 2009
4: Dusty Reagon, Twitter Application Development For Dummies. ISBN: 0470568623,
2010
5: Jeff Moore, Model View Controller, 2007,
http://www.phpwact.org/pattern/model_view_controller, Zugriff:10.8.2010
6: An open protocol to allow secure API authorization, 2010, http://oauth.net, Zugriff:
10.11.2010
7: Eran Hammer-Lahav, Explaining oAuth, 2007,
http://hueniverse.com/2007/09/explaining-oauth/, Zugriff: 10.11.2010

Link Verzeichnis
1. Twitter Goodies: http://twitter.com/about/resources/widgets, Zugriff: 2.8.2010
2. Twitter Gadget: http://www.twittergadget.com/, Zugriff: 20.7.2010
3. Ginga Widget, http://gingagadgets.com/, Zugriff: 20.7.2010
4. Twadget, http://arsecandle.org/twadget/, Zugriff 22.7.2010
5. TweetDeck, http://www.tweetdeck.com/, Zugriff 12.8.2010
6. oAuth allgemein, http://de.wikipedia.org, Zugriff: 6.7.2010
7. MVC Pattern, http://de.wikipedia.org, Model_View_Controller, Zugriff: 4.7.2010
8. PLE Tu Graz, http://ple.tugraz.at/, Zugriff: 20.11.2010
9. Turpial Client, http://www.webdomination.de/2010/05/turpial-schoener-twitter-client-
fuer-linux/, Zugriff: 10.8.2010
10. Gadfly Client, http://www.webdomination.de/2010/05/gadfly-twitter-client-auf-basis-
von-silverlight/, Zugriff: 10.8.2010

Abbildungsverzeichnis
Abbildung 1: Ausschnitt PLE Tu-Graz....................................................................................4
Abbildung 2: Konfiguration und Source Code von Widgets..................................................5
Abbildung 3: Twitter Gadget für iGoogle................................................................................6

33
Abbildung 4: Twitter für iGoogle.............................................................................................7
Abbildung 5: Twitter Reader für iGoogle................................................................................7
Abbildung 6: TweetDeck........................................................................................................8
Abbildung 7: Antwort der API im Json Format.....................................................................12
Abbildung 8: dev.twitter.com, Dokumentation zur API.........................................................13
Abbildung 9: MVC-Pattern...................................................................................................14
Abbildung 10: Das Twitter Widget........................................................................................16
Abbildung 11: Ordnerstruktur der gesamten Applikation.....................................................16
Abbildung 12: oAuth Logo....................................................................................................17
Abbildung 13: oAuth: Anmedlung auf Twitter Seite.............................................................18
Abbildung 14: Funktion onLoad() in index.html...................................................................18
Abbildung 15: Funktion init() in Controller.js........................................................................19
Abbildung 16: Funktion: init() in View.js...............................................................................19
Abbildung 17: Funktionen der Buttons im Kopfbereich.......................................................20
Abbildung 18: ein Tweet.......................................................................................................20
Abbildung 19: Funktion: click des "tweet" Buttons ..............................................................21
Abbildung 20: Funktionen: DM und Replys.........................................................................21
Abbildung 21: Funktion: printFollower(), Darstellung der Follower und beschreiben des
Divs......................................................................................................................................22
Abbildung 22: Funktion: UserInformation() im Controller....................................................23
Abbildung 23: Funktion: _sendRequest(), im Helper des Controllers.................................24
Abbildung 24: Ausschnitt aus Model....................................................................................25
Abbildung 25: Ausschnitt aus Main.php...............................................................................25
Abbildung 26: Konfiguration zur Identifizierung des Clients................................................26
Abbildung 27: Funktionen: UserInformation(), getFriendsTimeLine() der Klasse twitterAPI
.............................................................................................................................................27

34