Java Reference
In-Depth Information
Die letzten zwei Beispiele für einen ungebundenen und einen gebundenen Service stellen
jeweils nur eine Anwendung dar. Ein wichtiges Thema dieses Buches ist aber die Zusam-
menarbeit unterschiedlicher Anwendungen. Ich hoff e, dass aufgrund der vorhergehenden
Äußerungen klar wurde, dass jede Anwendung ohne Änderung des Programmcodes auf
jeweils zwei Anwendungen aufgeteilt werden kann: Die Activity wird jeweils Bestandteil der
einen und der Service Bestandteil der anderen Anwendung. Für den Fall des gebundenen
Service müssen die AIDL-Dateien sowie die Data-Klasse in beiden Anwendungen vorhan-
den sein.
Es gäbe bei Android noch viele weitere interessante Dinge zu besprechen. Für einen Ein-
blick in die Prinzipien des Komponentenmodells von Android sollten die besprochenen
Sachverhalte allerdings ausreichen.
■
1610 Bewertung
Zur Bewertung von Android müssen wir den Begriff Komponente, den wir in diesem Kapitel
so weit wie möglich vermieden haben, wieder verwenden. Eine Komponente ist im Kontext
dieses Buches eine komplette Android-Anwendung (eine App), die aus mehreren Teilkom-
ponenten oder Bausteinen besteht. Wie durch die Besprechung hoff entlich klar geworden
ist, ist ein wesentliches Ziel des Android-Frameworks die einfache Kombinierbarkeit der
Bestandteile unterschiedlicher Komponenten. Insofern entspricht das Entwurfsziel voll und
ganz der Komponentenidee. Im Folgenden prüfen wir nun, ob auch die Umsetzung von
Android zu den Vorgaben für ein Komponentensystem aus Kapitel 7 passt:
!
Zu E1: Gemäß E1 soll eine Komponente eine klar identifi zierbare Einheit sein, die kon-
form zu einem Komponentenmodell ist. Dies ist für Android eindeutig gegeben, wobei —
um es nochmals zu sagen — als Komponente eine Android-Anwendung verstanden wird.
Eine solche Anwendung ist in einer APK-Datei verpackt, die eine klar vorgegebene Struk-
tur hat. In der Konfi gurationsdatei werden die einzelnen Bestandteile der Komponente
wie Activities und Services defi niert, die ebenfalls wieder klaren Vorgaben folgen.
!
Zu E2: Gerade der Kopplungsmechanismus von Bauteilen unterschiedlicher Komponen-
ten ist eines der herausragenden Merkmale von Android. Da dieser Mechanismus auch
zur Kopplung der Bauteile innerhalb einer Anwendung genutzt wird, ist es nahezu gleich-
gültig, zu welcher Komponente ein benutzter Baustein gehört. Der Intent-Kopplungsme-
chanismus gehört damit zu den dominierenden Merkmalen von Android. Man kann bei
Android ohne Übertreibung von einem modularen System sprechen. Der Kopplungsme-
chanismus über Intents erinnert an ein Ereignisbussystem, bei dem Nachrichten über
einen Bus versendet werden, wobei diese Nachrichten an den zugestellt werden, der den
passenden Intent-Filter defi niert hat. Die Komponenten sind dadurch nur sehr lose gekop-
pelt und können zur Laufzeit einfach hinzugefügt, ausgetauscht und entfernt werden.
!
Zu E3: Das Android-Framework realisiert zwar keinen Lebenszyklus für eine Komponente
im Sinne einer App, aber es gibt ausgeprägte Lebenszyklen für die Teilkomponenten wie
Activities und Services. Auch liegt die Erzeugung und das Löschen solcher Objekte voll
und ganz in der Verantwortung des Komponenten-Frameworks. Im Gegensatz zu anderen
