2 Komponenten einer App – und gleich ein paar Basics
Bevor wir uns dem (eigentlich gar nicht so) heimlichen Hauptthema dieses Buches – den Android Activities – intensiver widmen, wollen wir uns einen Überblick über die unterschiedlichen Komponenten einer Android-Applikation verschaffen. Und wenn wir schon dabei sind, sollen auch gleich noch ein paar weitere wichtige Basics erklärt werden.
Im Vergleich zu Java ME- oder iOS-Applikationen bestehen Android-Applikationen zumeist aus vielen, relativ lose gekoppelten Teilen. Das werden für Sie in erster Linie die eben genannten Activities sein, die unter anderem das UI, das User Interface, bereitstellen. Aber Activities müssen eben nicht die einzigen Komponenten einer App sein, genauso können es Android Services, Content Provider, Intents oder Broadcast Receiver sein.
Schöne Bezeichnungen – aber wozu das Ganze?
Natürlich ist das Ganze kein Selbstzweck, es geht auch nicht um abstrakte Designziele eines beliebigen Betriebssystems. Android ist ein hochleistungsfähiges Betriebssystem für mobile Geräte. Aber so leistungsfähig die Prozessoren und so groß der Speicher der verwendeten Geräte auch sein mögen – mobil zu sein, bringt auch immer Einschränkungen mit sich. Denn irgendwo in den mobilen Geräten gibt es eine Energiequelle, die eben nicht unendlich ist, und manchmal sind die nächste Steckdose und ein passendes Ladegerät schmerzhaft weit entfernt. Ein solches System sollte deshalb nicht unnötig belastet oder sogar ständig ausgelastet werden.
Android ist deshalb so konzipiert, dass eine Applikation aus kleinen, flexiblen Komponenten bestehen kann, die jeweils sehr spezifische (Teil-)Aufgaben erledigen und sich gegenseitig aufrufen und abwechseln können.
Ein besonders wichtiger Punkt ist dabei, dass diese Komponenten bei Ressourcenknappheit sehr schnell „zum Abschuss freigegeben“ werden, wenn sie aktuell nicht mehr aktiv sind. Die Zustände (oder aktuellen Inhalte) dieser Komponenten müssen dabei aber nicht vollständig verloren gehen, sondern können recht leicht für ein schnelles „Wiederauferstehen“ vorgehalten werden. So können diese Komponenten im Bedarfsfall recht schnell wieder neu erzeugt werden, belasten das System zwischenzeitlich aber nicht mehr. Das System wird also nur mit solchen Aufgaben (und ausgeführten Programmen) belastet, die tatsächlich benötigt werden.
Auch wird nicht für jede Aufgabe, die von einer App ausgeführt werden muss, eine ressourcenhungrige grafische Oberfläche benötigt. Und es gibt Aufgaben, die problemlos unterbrochen oder ganz beendet werden können, während andere (unauffällig) im Hintergrund weiterlaufen müssen. Android stellt Ihnen deshalb maßgeschneiderte Bausteine zur Verfügung, aus denen eine App gebaut werden kann.
Eben dafür gibt es einige neue Konzepte zu verstehen, und auch wenn wir gerade am Anfang nicht die Zeit haben, jedes einzelne Element umfassend zu behandeln, wollen wir die wichtigsten kurz in einer Übersicht vorstellen:
- Activities beherbergen die Präsentationsschicht einer jeden Android-Applikation. Darüber hinaus kann jede Activity aber auch einiges an Programmlogik beinhalten. Im Normalfall gehört zu einer Activity eine XML-Datei, die eine Oberfläche darstellt, genauso wie eine Java-Datei, die (im Extremfall) sogar die gesamte Programmlogik der App beinhalten könnte. Außer bei sehr kleinen Apps würde das aber natürlich niemand machen – hoffentlich zumindest. Das UI kann dabei über XML oder aber auch direkt im Programmcode erstellt werden. Realisiert wird das durch Android-UI-Komponenten, die von der Klasse android.view.View erben. Die so genannten ViewGroups sind dafür verantwortlich, die Views (auch Widgets oder Controls genannt) entsprechend zu positionieren. Einfacher ausgedrückt, besteht eine Oberfläche aus unterschiedlichsten Elementen, die Views genannt werden. Um diese Elemente besser anordnen zu können, gibt es wiederum verschiedene containerähnliche Elemente, das sind die genannten ViewGroups. Eigentlich ganz einfach. Eine App kann übrigens eine oder beliebig viele Aktivitäten haben und zwischen diesen hin- und herwechseln.
- Services sind die unsichtbaren Helfer Ihrer Applikation, die je nach Applikationslogik regelmäßig erwachen und beispielsweise nach neuen E-Mails schauen. Services selbst haben kein UI, können jedoch durch das Android Notification Framework den Nutzer informieren.
- Intents (Vorhaben, Absichten) sind ein enorm wichtiges Konzept. Sie sind nichts anderes als eine Art „Nachricht“ (oder Aufruf), die entweder direkt an einen Service oder eine Activity adressiert ist (Explicit Intents) oder systemweit wie eine Art Rundfunk (Broadcast) ausgerufen werden kann (Implicit Intents). Das Android-Betriebssystem ist in letzterem Fall dafür verantwortlich, potenzielle Empfänger dieser Nachrichten zu finden und dem Anwender eine Auswahl der Applikationen zu präsentieren, die die Nachricht verarbeiten können. Im einfachsten Fall (dem Explicit Intent) rufen Sie mit einem Intent eine genau festgelegte, andere Activity der gleichen App auf und wechseln somit innerhalb Ihrer App zu dieser Activity.
- Broadcast Receiver konsumieren bzw. empfangen die impliziten Nachrichten (Implicit Intents). Hat Ihre Applikation entsprechende Broadcast Receiver registriert (so eine Art „Hey! Ich kann das!“), kann ein entsprechender Intent Ihre Applikation starten, um dann die Nachricht bzw. zugrunde liegende Daten zu verarbeiten. Unter Windows kennt man das beispielsweise in einfacher Form, wenn sich Programme bei der Installation für bestimmte Dateiendungen registrieren und damit im System bekannt geben, dass sie bestimmte Dateien bearbeiten können. Im einfachsten Fall ein Editor, der Textdateien mit der Dateiendung .txt bearbeiten kann. Natürlich hinkt der Vergleich ein wenig, hilft aber doch beim grundsätzlichen Verständnis.
- Content Provider: Die Vorratsspeicher zur Datenhaltung. Mittels eines oder mehrerer Content Provider kann Ihre Applikation Daten anderen Applikationen zugänglich machen. Auch intern benutzt Android Content Provider, beispielsweise, um die Kontakte des Telefonbuchs anderen Applikationen zur Verfügung zu stellen. Content Provider benutzen intern zumeist SQLite-Datenbanken, können jedoch auch andere Mechanismen der Datenhaltung (Dateisystem, Netzwerk) benutzen.
Neben diesen Bestandteilen einer Android-Applikation gibt es natürlich auch noch andere: Widgets beispielsweise, das sind kleine Applikationen, die direkt auf dem Home Screen der Geräte ausgeführt werden. Widgets sind nicht zu verwechseln mit den Android-UI-Komponenten, die oft auch genauso bezeichnet werden. Live Folders geben vom Home Screen aus Zugriff auf Elemente eines Content Providers und können so beispielsweise Ihre gespeicherten Kontakte zugänglich machen.
2.1 Anatomie einer App – ein Blick unter die Motorhaube
Wie ist eine typische Android-Applikation nun strukturiert? Und wie finde ich mich in dieser Struktur zurecht? Werfen wir doch gleich am Anfang einen Blick auf eine schematische Darstellung einer typischen App.
Abbildung 2.1: Viel Inhalt, vor allem eine ganze Menge XML; die angegebene „strings.xml“ dient als leicht zu merkendes Beispiel
Wie man in der Abbildung sehen kann, gibt es im Inneren einer App mehr als man vielleicht vermuten würde. Eine App besteht aus unterschiedlichen Ressourcen, beispielsweise Grafiken oder MP3-Dateien, die in der App verwendet werden. Es gibt eine ganze Menge von XML-Dateien, beispielsweise eine strings.xml, in der alle Texte (auch einfache Wörter) hinterlegt sind. Genauso werden in einer App alle Farbwerte und Größenangaben in XML-Dateien hinterlegt. Einen besonderen Status hat die AndroidManifest.xml, quasi der Personalausweis unserer App. Dort werden zentrale Informationen wie der Name, die Versionsnummer und notwendige Berechtigungen (z. B. Zugriff auf das Internet) festgelegt. Das zentrale Element, das alle Elemente miteinander verbindet und den Zugriff darauf ermöglicht, ist „R“. Und nicht vergessen dürfen wir unsere Activity, denn irgendwo muss sich ja auch unser Java verstecken und die Logik untergebracht sein. Und ja, natürlich kann eine App auch mehrere Activities haben. Und alle Activities können auf die Ressourcen Ihrer App zugreifen.
Abbildung 2.2: Eine typische Activity mit einem nicht ganz so typischen Namen – sie bildet das Aussehen („activity_curt.xml“) und das Gehirn („Curt.java“) der App ab
Nun zur Praxis
Sollten Sie bisher noch keine App erstellt haben, sollten Sie das spätestens jetzt nachholen: Datei | Neu | Android Application Project. Im Zweifelsfall werfen Sie dazu noch einen kurzen Blick in unser erstes Kapitel. Dort finden Sie auch einen entsprechenden Screenshot, den wir uns deshalb an dieser Stelle sparen wollen. Sie vergeben im Assistenten einen beliebigen Namen für Ihre App, aus dem sich (allerdings nicht zwingend) auch der Projektname in Eclipse herleitet. Genauso wird der Package Name ergänzt, sollte aber weiter angepasst werden, es sei denn, Sie sind tatsächlich Besitzer der vorgegebenen Domain example.com. Weitere notwendige Angaben beziehen sich auf die Auswahl der zugrunde liegenden APIs. Minimum Required SDK1 verhindert, dass Ihre App auf Geräten installiert werden kann, deren API unter dem angegebenen Wert liegt und bei denen Sie davon ausgehen, dass sie zu alt für Ihre App sind. Unter Target...
