Twitter-Integration auf dem Windows Phone 7.5

Zwitschern auf Mango
Kommentare

Immer mehr Menschen sind in sozialen Netzen wie Facebook oder Twitter miteinander verbunden. Sie möchten Neuigkeiten und Ereignisse live mit ihren Freunden teilen. Der folgende Artikel soll am Beispiel von Twitter zeigen, wie diese Netzwerke in einer App auf dem Windows Phone auch ohne Bibliotheken integriert werden können.

Windows Developer

Der Artikel „Zwitschern auf Mango“ von Matthias Fischer ist erstmalig erschienen im Windows Developer 9.2012

Das Windows Phone 7.5 Mango verfügt bereits über integrierte Funktionen zur Verknüpfung von Facebook, Twitter und LinkedIn. Nach dem Eingeben der Zugangsdaten zu den jeweiligen Netzwerken kann der Benutzer Nachrichten von seinen Freunden lesen, eigene Statusmeldungen abgeben und die Kontaktinformationen in seinem People Hub nutzen. Leider gibt es jedoch (noch) kein in das Windows Phone SDK (7.1.1) integriertes API für Facebook, Twitter und Co. Wer Nachrichten auf Facebook oder Tweets auf Twitter aus seiner App heraus veröffentlichen möchte, muss die Dienste entweder selbst anprogrammieren oder alternativ auf entsprechende Third-Party-Bibliotheken zurückgreifen. Twitter stellt Entwicklern eine Schnittstelle in Form eines REST-API bereit, mit dessen Hilfe der Dienst in eigenen Apps integriert werden kann. Die Autorisierung erfolgt über OAuth [1]. Das vollständige Beispiel finden Sie auf meiner Webseite zum Download unter [2].

Vorbereitung

Um Twitter in einer eigenen Anwendung verwenden zu können, ist es erforderlich, die App zunächst zu registrieren. Jede App bekommt eine eindeutige ID, mit deren Hilfe diese später die Authentifizierung und Autorisierung von Benutzern nach dem OAuth-Verfahren durchführen kann (siehe dazu auch Kasten „Funktionsweise OAuth“).

Die Registration erfolgt auf der Internetseite https://dev.twitter.com. Neben dem Namen der Anwendung sind die Organisation, deren Webseite sowie eine weitere Webseite für die erfolgreiche Autorisierung anzugeben (Abb. 1). Nach einer erfolgreichen Anmeldung des Benutzers im Browser wird auf diese Seite weiter geleitet (Abb. 2 und Abb. 3). Nach dem Speichern werden ein CustomerKey und ein CustomerSecret angezeigt. Diese beiden Werte identifizieren Ihre App, bewahren Sie diese Informationen gut auf und machen Sie diese keinem dritten zugänglich.

Abb. 1: Anmeldung einer App bei Twitter
Abb. 1: Anmeldung einer App bei Twitter
Abb. 2: Autorisierung der App
Abb. 2: Autorisierung der App
Abb. 3: Redirection zur App
Abb. 3: Redirection zur App
Funktionsweise OAuth

  • Bevor ein Dienst verwendet werden kann, muss sich der Benutzer zunächst bei dem Dienst anmelden. Auf einer Internetseite wird das mithilfe des Login-Formulars gelöst. Bei einer Anwendung ist es nicht ganz so einfach. Anwendungen ohne OAuth fragen den Benutzer nach den jeweiligen Zugangsdaten, speichern sie und melden sich mithilfe dieser Daten direkt an dem Server an.
  • Dieses Verfahren birgt die Gefahr, dass die App die Zugangsdaten möglicherweise unsicher speichert oder gar selbst ausspionieren könnte. Um dem vorzubeugen, wird bei dem OAuth-Verfahren sichergestellt, dass die App erst gar nicht mit den Benutzerzugangsdaten in Berührung kommt. Dazu wird die Anmeldung über eine Webseite des Servers umgeleitet, sodass die empfindlichen Daten nur in dem Webformular innerhalb des Browser direkt an den Server übertragen werden. Die App kann die eingebenden Daten nicht auslesen. Aus diesem Grund ist eine Voraussetzung für OAuth, dass die App einen Browser öffnen kann.
  • Vereinfacht besteht ein Anmeldevorgang nach dem OAuth-Verfahren [1] aus fünf Schritten:
  1. Anfordern der RequestToken unter Verwendung der CustomerToken. Auf diese Weise wird eine eindeutige und einmalige Anmeldeseite für die angegebene Anwendung erzeugt. (Die Namen der ID können ggf. von Dienst zu Dienst etwas variieren.)
  2. Öffnen der Webseite für die Anmeldung des Benutzers unter Verwendung des RequestToken.
  3. Anmelden des Benutzers im Browser. Nach erfolgreicher Anmeldung übermittelt der Server einen AccessToken und einen AccessVerifier.
  4. AccessToken und einen AccessVerifier extrahieren. Diese werden als Parameter im URL des Browsers übermittelt, zu der die Weiterleitung erfolgte.
  5. Anfordern des AccessToken und des AccessSecret. Dabei muss der AccessToken und der AccessVerifier an den Server übertragen werden. Mit dem Erhaltenen AccessToken Identifiziert sich die App dann als angemeldet, mit dem AccessSecret werden alle weiteren Anfragen signiert.

Um möglichen „Manipulationen“ an den OAuth-Parametern oder den Benutzerdaten zu vermeiden, werden alle Nachrichten signiert. Zu diesem Zweck werden alle Parameter und ihre Werte gesammelt, alphabetisch sortiert und zusammen mit der Adresse des Servers und dem Pfad unter Verwendung der/des Secrets, meist nach dem HMAC-SHA1-Verfahren, zu einer Checksumme verrechnet [3]. Mithilfe dieser Checksumme kann der Server schnell prüfen, ob einer der Parameter auf dem Transportweg manipuliert wurde oder nicht.

Veröffentlichen auf Twitter

Die Beispielanwendung soll ein Textfeld und einen Button für das Veröffentlichen auf Twitter enthalten. Twitter verwendet OAuth 1.0. Die folgenden Schritte sollen zeigen, wie ein Tweet veröffentlicht werden kann, ohne eine Twitter-Bibliothek zu verwenden.

Twitter hat vor einigen Monaten die Möglichkeit eingeführt, die Antworten des REST-API auch mit GZIP oder DEFLATE zu komprimieren. Besonders auf mobilen Geräten ist es von Vorteil, wenn die übertragenen Daten komprimiert werden. Das spart UMTS-Bandbreite. Um dieses Feature nutzen zu können, muss die Bibliothek SharpCompress [4] zu dem Projekt hinzugefügt werden. So können später komprimierte Antworten des Servers mithilfe eines GZipStream-Objekts entpackt werden.

Als Erstes wird ein Objekt benötigt, das die Autorisierungsinformationen speichern kann. Die Klasse TwitterSettings verfügt über statische Felder für den ConsumerKey und das ConsumerSecret. Diese Informationen werden nach der Registrierung der Anwendung von Twitter bereitgestellt. Ersetzen Sie die Platzhalter bitte mit Ihrem Schlüsselpaar.

Ferner soll diese Klasse den RequestToken, das RequestSecret, den AuthToken und das AuthSecret aufnehmen. Diese Informationen werden später bei den Zugriffen auf das API benötigt. Zu Informationszwecken werden noch die UserId und der UserName gespeichert. Die Klasse selbst ist als Singleton implementiert, weil es sich um Einstellungen handelt, die für die gesamte App relevant sind. Listing 1 zeigt das Objekt.

Listing 1

public class TwitterSettings {

    public static readonly string ConsumerKey = "Platzhalter";
    public static readonly string ConsumerSecret = "Platzhalter";

    protected TwitterSettings() {}

    public string UserName { get; set; }
    public string UserId { get; set; }

    public string RequestToken { get; set;}
    public string RequestSecret { get; set; }

    public string AuthToken { get; set; }
    public string AuthSecret { get; set; }

    private static TwitterSettings _instance;

    public static TwitterSettings Instance {
      get { return _instance ?? (_instance = new TwitterSettings()); }
    }  

Die Aufrufe der REST-API-Funktionen sind sehr ähnlich. Aus diesem Grund soll nur der erste Aufruf etwas ausführlicher betrachtet werden. Bei allen weiteren Aufrufen des API werden nur noch die Unterschiede beschrieben. Um die Anwendung bei Bedarf bei Twitter anmelden zu können, empfiehlt sich eine separate Anmeldeseite mit einem Browsersteuerelement:


    
    

Beim Navigieren auf diese Seite erfolgt der erste Aufruf der API-Funktion zum Ermitteln der RequestToken.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -