URIs weisen den Weg

Teil 1 von Listing 3 beschafft sich die ID des ersten Kalenders, den er im System findet. Hier zeigt sich bereits die grundlegende Verwendung des Content-Providers. Statt der bei Datenbanken üblichen Tabellennamen kommen URIs zum Einsatz. Android verwaltet intern ein Mapping, welche URIs zu welchen Content-Providern gehören. Die URIs für System-Content-Provider sind über Konstanten in den APIs fest hinterlegt. Im Falle des Kalenders finden sie sich in der Klasse »android.provider.CalendarContract« [2] sowie in deren inneren Klassen wie »Calendars« , »Events« und »Instances« .

Die Klasse »ContentResolver« ermöglicht den Zugriff auf Content-Provider (Zeile 3). Ein entsprechendes Objekt liefert die Methode »getContentResolver()« , die in jedem Kontext zur Verfügung steht, also beispielsweise über die »Activity« -Klasse. Die »query()« -Methode des »ContentResolver« bekommt den URI übergeben, um den passenden Content-Provider zu adressieren (Zeile 5). Die Variable »projection« gibt zudem an, dass nur bestimmte Werte gefragt sind: Für das Beispiel genügen die Kalender-ID und der Darstellungsname des Kalenders.

Datenbank-Cursor

Das Ergebnis der »query()« -Methode ist ein »Cursor« -Objekt, das viele bereits vom Umgang mit Datenbanken kennen dürften. Mit »moveToNext()« (Zeile 7) springt der Cursor zum jeweils nächsten Datensatz, dessen Werte sich dann nach Spalten erfragen lassen. Im Beispiel ist die ID in Spalte 0 zu finden, da sie im »projection« -Array an erster Stelle steht. Findet das Programm keinen Kalender, wirft dieser Code eine Exception. Produktive Apps sollten hier eine Fehlermeldung anzeigen oder bei fehlender Eindeutigkeit den Nutzer fragen, welchen Kalender er verwenden möchte.

Der zweite Teil von Listing 3 fügt einen neuen Termin hinzu, der in einer Stunde beginnt und 60 Minuten dauert. Dazu sammelt der Code die Werte für den Termin in dem Map-artigen Objekt »ContentValues« (Zeile 21). Die Schlüssel erlaubter Werte sind in der Klasse »Events« als Konstanten zu finden. Die Kalender-ID, der Startzeitpunkt und die Zeitzone sind dabei Pflichtangaben. Bei einmaligen Terminen, wie im vorliegenden Fall, muss der Programmierer auch eine Endzeit angeben. Bei sich wiederholenden Events sind stattdessen Dauer (»DURATION« ) und Wiederholungsrhythmus (»RRULE« oder »RDATE« ) gefordert.

Mit diesen vorbereiteten Daten ruft das Listing die »insert()« -Methode des »ContentResolver« auf (Zeile 28). Diese gibt ein »Uri« -Objekt zurück, mit dem sich der neue Datensatz adressieren lässt. Der letzte Teil des erhaltenen URI entspricht dabei der Event-ID, die das Beispielprogramm in einem Log-Eintrag ausgibt (Zeile 30).

Der dritte Teil des Programmierbeispiels gibt alle Termine der kommenden 200 Tage aus und arbeitet, korrekt ausgedrückt, mit Termin-Instanzen, die Terminwiederholungen berücksichtigen. Jede Wiederholung ist eine weitere Instanz des Termins. Ähnlich wie im ersten Teil findet hier eine Abfrage über den »ContentResolver« statt. Neu ist jedoch, dass der URI an dieser Stelle bereits den Abfragezeitraum beinhalten muss. Die Variable »projection« (Zeile 38) definiert, dass Event-ID, Termin-Titel und -Start gefragt sind. Mit Hilfe der While-Schleife in den Zeilen 40 bis 45 iteriert der Code über den Cursor, solange dieser weitere Datensätze bereitstellt.

Das Codebeispiel schließt im vierten Teil damit ab, dass es den angelegten Termin wieder entfernt. Dazu benötigt es den URI des Termins, den es sich beim Anlegen in Zeile 28 gemerkt hat.