Bachelorarbeit
Twitter Widget für die PLE der Tu Graz
Autor:Jörg SandriesserSS 2010
Inhaltsverzeichnis1.Einführung...........................................................................................................................22.Aktueller Stand der Technik................................................................................................3
2.1.Hauseigene Twitter Widgets....................................................................................32.2.Twitter für iGoogle...................................................................................................5
TwitterGadget........................................................................................................5Twitter....................................................................................................................5Twitter Reader.......................................................................................................6
2.3.Twitter Clients und Desktop Widgets......................................................................6Twadget (Windows Vista & 7)...............................................................................6Tweetdeck.............................................................................................................7Turpial(Linux)........................................................................................................8Gadfly(Silverlight)..................................................................................................8Saezuri(plattformunabhänig)................................................................................8Skeet(Google Chrome).........................................................................................8Weitere Clients......................................................................................................9
2.4.Twitter auf mobilen Geräten....................................................................................93.Die Umsetzung des Widgets.............................................................................................10
3.1.Theoretische Grundlagen......................................................................................10Die Twitter API.........................................................................................................10MVC Pattern............................................................................................................12Authentifizierung......................................................................................................14
oAuth...................................................................................................................14Einsetzen von oAuth...........................................................................................14
3.2.Praktische Umsetzung..........................................................................................16Aufbau und Struktur der Applikation.......................................................................16Authentifizierung......................................................................................................17Initialisierung und grundlegende Abläufe................................................................18Abläufe der View.....................................................................................................19
DM, RT und @....................................................................................................20Ausgeben neuer Informationen..........................................................................21
Funktionen und Requests im Controller..................................................................23Model.......................................................................................................................25Server......................................................................................................................25
4. Anwendungsbeispiel/Diskussion......................................................................................274.1.Anwendungsbeispiel.............................................................................................274.2.Diskussion.............................................................................................................29
5. Zusammenfassung und Ausblick.....................................................................................305.1.Zusammenfassung................................................................................................305.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ührungZiel 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
2. Aktueller Stand der TechnikDerzeit 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 WidgetsZu 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
Abbildung 1: Ausschnitt PLE Tu Graz
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.
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 iGoogleSelbstverstä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
Abbildung 2: Konfiguration und Source Code von Widgets
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]
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 3: Twitter Gadget 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.
2.3. Twitter Clients und Desktop WidgetsIm 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
Abbildung 4: Twitter für iGoogle
Abbildung 5: Twitter Reader für iGoogle
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]
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
Abbildung 6: TweetDeck
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ätenAufgrund 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:
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
Abbildung 7: Antwort der API im Json Format
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]
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
Abbildung 8: dev.twitter.com, Dokumentation zur API
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]
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
Abbildung 9: MVC-Pattern
(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 identifizierenJede 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 holenJeder 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
(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
Abbildung 11: Das Twitter Widget
Abbildung 10: Ordnerstruktur der gesamten Applikation
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 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 12: oAuth Logo
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.
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
Abbildung 13: oAuth: Anmeldung auf Twitter Seite
Abbildung 14: Funktion onLoad() in index.html
Im nächsten Schritt werden die Benutzerinformationen des angemeldeten Users mittels des ersten API-Requests geladen und im Kopf des Widgets angezeigt
(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).
20
Abbildung 15: Funktion init() in Controller.js
Abbildung 16: Funktion: init() in View.js
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).
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).
21
Abbildung 17: Funktionen der Buttons im Kopfbereich
Abbildung 18: ein Tweet
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:
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.
22
Abbildung 19: Funktion: click des "tweet" Buttons
Abbildung 20: Funktionen: DM und Replys
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:
Alle aktuellen Inhalte (andere Divs) werden ausgeblendet (clearContent()). Der zu
23
Abbildung 21: Funktion: printFollower(), Darstellung der Follower und beschreiben des Divs
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:
Die Funktion interFace.userInformatione() (Abbildung 22) ist die erste Methode, die beim
24
Abbildung 22: Funktion: UserInformation() im Controller
Ö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.
25
Abbildung 23: Funktion: _sendRequest(), im Helper des Controllers
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.
Server
26
Abbildung 24: Ausschnitt aus Model
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.
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
Abbildung 25: Ausschnitt aus Main.php
Abbildung 26: Konfiguration zur Identifizierung des Clients
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.
4. Anwendungsbeispiel/Diskussion
4.1. AnwendungsbeispielIm folgenden Kapitel möchte ich kurz an Hand der folgenden Beispiele die Funktionen des Widgets näher erklären:
28
Abbildung 27: Funktionen: UserInformation(), getFriendsTimeLine() der Klasse twitterAPI
Die Startseite:1) Menüleiste:Follower: Personen die mir folgenFollowing: Personen denen ich folgeSearch: Suche nach fremden UsersnLists: Zum Verwalten und Erstellen von Listen2) Kopfbereich:Benutzername des eingeloggten Users und seine letzte Statusmeldung3) Dms Rts:Dms: Direktnachrichten an michRts: Retweets von mir, können gelöscht werden4)Textfeld zum Versenden von Tweets, Dms und Replys5)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 UsersProfile: Zeigt Profil mit allen Details eines UsersAdd to List: Zum Hinzufügen des Users zu einer Liste, vorhandene Listen werden dann zum Auswählen angezeigtDM: Direktnachricht an einen User
Lists:1) create List: zum Erstellen einer neuen Liste, welche danach sofort dargestellt wird2) Vorhandene Listen:Bereits erstellte Listen werden angezeigt.Members: User die sich in der Liste befindenSubscribers: User die der Liste folgenNach 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öschtRemove from List: User wird aus der Liste entfernt.
4.2. DiskussionGrundsä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. ZusammenfassungZiel 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. AusblickDie 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 Verzeichnis1. 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
AbbildungsverzeichnisAbbildung 1: Ausschnitt PLE Tu-Graz....................................................................................4Abbildung 2: Konfiguration und Source Code von Widgets..................................................5Abbildung 3: Twitter Gadget für iGoogle................................................................................6
33
Abbildung 4: Twitter für iGoogle.............................................................................................7Abbildung 5: Twitter Reader für iGoogle................................................................................7Abbildung 6: TweetDeck........................................................................................................8Abbildung 7: Antwort der API im Json Format.....................................................................12Abbildung 8: dev.twitter.com, Dokumentation zur API.........................................................13Abbildung 9: MVC-Pattern...................................................................................................14Abbildung 10: Das Twitter Widget........................................................................................16Abbildung 11: Ordnerstruktur der gesamten Applikation.....................................................16Abbildung 12: oAuth Logo....................................................................................................17Abbildung 13: oAuth: Anmedlung auf Twitter Seite.............................................................18Abbildung 14: Funktion onLoad() in index.html...................................................................18Abbildung 15: Funktion init() in Controller.js........................................................................19Abbildung 16: Funktion: init() in View.js...............................................................................19Abbildung 17: Funktionen der Buttons im Kopfbereich.......................................................20Abbildung 18: ein Tweet.......................................................................................................20Abbildung 19: Funktion: click des "tweet" Buttons ..............................................................21Abbildung 20: Funktionen: DM und Replys.........................................................................21Abbildung 21: Funktion: printFollower(), Darstellung der Follower und beschreiben des Divs......................................................................................................................................22Abbildung 22: Funktion: UserInformation() im Controller....................................................23Abbildung 23: Funktion: _sendRequest(), im Helper des Controllers.................................24Abbildung 24: Ausschnitt aus Model....................................................................................25Abbildung 25: Ausschnitt aus Main.php...............................................................................25Abbildung 26: Konfiguration zur Identifizierung des Clients................................................26Abbildung 27: Funktionen: UserInformation(), getFriendsTimeLine() der Klasse twitterAPI.............................................................................................................................................27
34
Recommended
