© Excellent backgrounds/Shutterstock.com
Java Magazin
API zum Laden von Daten: Loader

API zum Laden von Daten: Loader

Daten, die in einer Android-App angezeigt werden, müssen irgendwoher kommen. Dieses „irgendwo“ ist selten initial im Speicher verfügbar und muss daher von einer externen Datenquelle wie Datei, Datenbank oder Netzwerk geladen werden. Damit dies nicht zu einer langsam reagierenden App führt oder noch schlimmer, zu dem Dialog „Application not responding“, sollte das Laden in einem Hintergrundthread passieren.

Arne Limburg, Lars Röwekamp


Jeder, der den Code einer App von Android Version 2.x auf Version 3 oder 4 aktualisiert, wird verschiedene Stellen im Code finden, die auf einmal von der IDE (jedenfalls von Eclipse) durchgestrichen werden. Ein Major-Versionssprung geht in Android eigentlich immer damit einher, dass einige Methoden auf deprecated gesetzt werden, was zu dem beschriebenen Phänomen führt. Ein häufig anzutreffendes Stück Code dieser Art ist die Activity-Methode startManagingCursor. Diese ist seit Android 3 deprecated und das aus gutem Grund.

Probleme von „managed“ Cursors

Dabei könnte es so einfach sein: Man möchte Daten aus der Datenbank anzeigen und diese sollen sich automatisch aktualisieren, wenn sich der Datenbankinhalt ändert. Die Methoden startManagingCursor und managedQuery (welche eine Query absetzt und dann startManagingCursor aufruft) bieten hierfür tatsächlich einen ebenso einfachen, wie funktionierenden Mechanismus an: Der Cursor der Query wird an den Lebenszyklus der Activity gebunden. Das heißt, wenn die Activity gestoppt wird, wird der Cursor deaktiviert und beim Zerstören der Activity wird auch der Cursor automatisch geschlossen. Damit nicht genug, zusätzlich werden jedes Mal, wenn die Activity wieder in den Vordergrund geholt wird, die Daten automatisch aktualisiert. Im Zusammenspiel mit dem SimpleCursorAdapter ist es sogar möglich, dass die Daten direkt bei der Änderung aktualisiert werden. Wo ist also das Problem mit diesem Mechanismus?

Problem 1: Das Laden der Daten geschieht nicht, wie in der Einleitung empfohlen, im Hintergrund sondern direkt im UI-Thread. Bei kleinen Datenmengen ist das zwar in der Regel nicht so dramatisch, führt aber in jedem Fall zu einem langsamer reagierenden UI.Problem 2: Jedes Mal, wenn die Activity in den Vordergrund geholt wird, werden die Daten automatisch neu geladen. Auch das ist bei näherer Betrachtung recht ungeschickt, weil dadurch die betroffene Activity grundsätzlich langsamer angezeigt wird, auch wenn sich die angezeigten Daten gar nicht geändert haben.Problem 3: Auch das Zusammenspiel mit dem SimpleCursorAdapter ist problematisch, weil es dazu führt, dass das UI unvorhersehbar stockt, nämlich jedes Mal, wenn im Hintergrund die Daten geändert werden und der SimpleCursorAdapter daher ein requery() vornimmt.

All diese Probleme haben Google dazu bewogen, seit Android 3 einen anderen Weg zu gehen, wenn es darum geht, Daten für das UI zu laden.

Neues API zum Laden von Daten

Seit Android 3 gibt es mit dem Loader-Interface [1] ...

Java Magazin
API zum Laden von Daten: Loader

API zum Laden von Daten: Loader

Daten, die in einer Android-App angezeigt werden, müssen irgendwoher kommen. Dieses „irgendwo“ ist selten initial im Speicher verfügbar und muss daher von einer externen Datenquelle wie Datei, Datenbank oder Netzwerk geladen werden. Damit dies nicht zu einer langsam reagierenden App führt oder noch schlimmer, zu dem Dialog „Application not responding“, sollte das Laden in einem Hintergrundthread passieren.

Arne Limburg, Lars Röwekamp


Jeder, der den Code einer App von Android Version 2.x auf Version 3 oder 4 aktualisiert, wird verschiedene Stellen im Code finden, die auf einmal von der IDE (jedenfalls von Eclipse) durchgestrichen werden. Ein Major-Versionssprung geht in Android eigentlich immer damit einher, dass einige Methoden auf deprecated gesetzt werden, was zu dem beschriebenen Phänomen führt. Ein häufig anzutreffendes Stück Code dieser Art ist die Activity-Methode startManagingCursor. Diese ist seit Android 3 deprecated und das aus gutem Grund.

Probleme von „managed“ Cursors

Dabei könnte es so einfach sein: Man möchte Daten aus der Datenbank anzeigen und diese sollen sich automatisch aktualisieren, wenn sich der Datenbankinhalt ändert. Die Methoden startManagingCursor und managedQuery (welche eine Query absetzt und dann startManagingCursor aufruft) bieten hierfür tatsächlich einen ebenso einfachen, wie funktionierenden Mechanismus an: Der Cursor der Query wird an den Lebenszyklus der Activity gebunden. Das heißt, wenn die Activity gestoppt wird, wird der Cursor deaktiviert und beim Zerstören der Activity wird auch der Cursor automatisch geschlossen. Damit nicht genug, zusätzlich werden jedes Mal, wenn die Activity wieder in den Vordergrund geholt wird, die Daten automatisch aktualisiert. Im Zusammenspiel mit dem SimpleCursorAdapter ist es sogar möglich, dass die Daten direkt bei der Änderung aktualisiert werden. Wo ist also das Problem mit diesem Mechanismus?

Problem 1: Das Laden der Daten geschieht nicht, wie in der Einleitung empfohlen, im Hintergrund sondern direkt im UI-Thread. Bei kleinen Datenmengen ist das zwar in der Regel nicht so dramatisch, führt aber in jedem Fall zu einem langsamer reagierenden UI.Problem 2: Jedes Mal, wenn die Activity in den Vordergrund geholt wird, werden die Daten automatisch neu geladen. Auch das ist bei näherer Betrachtung recht ungeschickt, weil dadurch die betroffene Activity grundsätzlich langsamer angezeigt wird, auch wenn sich die angezeigten Daten gar nicht geändert haben.Problem 3: Auch das Zusammenspiel mit dem SimpleCursorAdapter ist problematisch, weil es dazu führt, dass das UI unvorhersehbar stockt, nämlich jedes Mal, wenn im Hintergrund die Daten geändert werden und der SimpleCursorAdapter daher ein requery() vornimmt.

All diese Probleme haben Google dazu bewogen, seit Android 3 einen anderen Weg zu gehen, wenn es darum geht, Daten für das UI zu laden.

Neues API zum Laden von Daten

Seit Android 3 gibt es mit dem Loader-Interface [1] ...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang