Java Reference
In-Depth Information
mal davon ausgehen, dass es zu jedem Prozess genau einen Thread gibt, der den Bild-
schirminhalt anzeigt und auf die Eingaben der Benutzerin reagiert (vergleichbar mit dem
Event Dispatching Thread in Swing). Zum Thema Threads, die in einer Anwendung laufen,
gibt es im Zusammenhang mit den Beispiel-Apps weitere Informationen.
■
163 Komponentenmodell
Wie zuvor beschrieben wurde, besteht eine Anwendung aus einer Menge von Activities.
Activities sind aber nicht die einzige Art von Bausteinen einer Android-Anwendung. Außer
Activities kann eine App auch einen oder mehrere Services, Content Providers und Broad-
cast Receivers enthalten. Ein Service ist ein „gesichtsloser“ Dienst, also ein Baustein ohne
eine grafi sche Benutzeroberfl äche. Ein Service kann wie eine Activity von anderen Bestand-
teilen derselben oder aber auch einer anderen Anwendung benutzt werden. Ein typisches
Beispiel für einen Service ist das Abspielen einer Audio-Datei. Ein Content Provider ermög-
licht einen Zugriff auf einen Datenbestand über eine fest vorgegebene Schnittstelle, die aus
der Gedankenwelt relationaler Datenbanken stammt. Ein Content Provider muss auf Such-
anfragen reagieren, die nicht syntaktisch, aber vom Prinzip her die Form „SELECT . . . FROM
. . . WHERE . . .“ haben. Weitere von einem Content Provider bereitgestellte Operationen sind
wie bei Datenbanken das Einfügen, Ändern und Löschen von Datensätzen. Ein Beispiel für
einen Content Provider ist natürlich eine relationale Datenbank, aber auch eine Anwen-
dung, mit der die Kontaktdaten angezeigt und verä ndert werden können. Wie bei Activities
und Services kann ein Content Provider nicht nur von der eigenen Anwendung, sondern
auch von einer anderen Anwendung benutzt werden. Die vierte und letzte Art von App-
Bausteinen sind Broadcast Receiver, die auf das Senden von Nachrichten reagieren. In die-
sem Buch beschränken wir unsere Betrachtung auf Activities und Services, während Con-
tent Providers und Broadcast Receivers nicht behandelt werden.
Bevor wir unsere Betrachtung des Android-Komponentenmodells fortsetzen, sollte ein ter-
minologisches Problem geklärt werden. Die einzelnen Bestandteile einer App wie Activities
und Services werden in der Android-Terminologie als Komponenten bezeichnet. Diese Ver-
wendung des Begriff s Komponente passt aber nur teilweise zu dem Begriff , wie er bisher in
diesem Buch gebraucht wurde. Eine Android-Komponente im Sinne dieses Buches ist viel-
mehr eine komplette Android-Anwendung, denn das ist die Einheit, die verpackt und auf
dem Application Framework installiert wird (vgl. Bild 16.1). Der Begriff Komponente ist also
problematisch: Wird er im Sinne des Buches für eine Android-App verwendet, so kann das
für Android-Leute verwirrend sein; benutzen wir den Begriff aber im Android-Sinne für
Activities, Services usw., dann kommt es zu Unstimmigkeiten zwischen der bisherigen Ver-
wendung des Begriff s und der jetzigen. Als Ausweg aus diesem Dilemma werde ich den
Begriff Komponente in diesem Kapitel deshalb nur sehr spärlich verwenden. Stattdessen
spreche ich von einer Android-Anwendung oder App einerseits und von Bestandteilen oder
Bausteinen andererseits.
Für Android-Bausteine wie Activities und Services müssen gewisse Vorgaben eingehalten
werden. Insbesondere muss die „Einstiegsklasse“ einer Activity bzw. eines Services von der
