Artikel

 
März 2009 | Artikel

Google Android – So funktioniert’s

(Link zum Artikel: http://www.it-republik.de/jaxenter/artikel/2177)

Text: von Konrad Hübner und Henning Böger
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share
Im November 2007 war es soweit: Google veröffentlichte die erste Version seines Software Development Kits (SDK) für die Mobilplattform Android. Dieser Artikel bietet einen Einstieg in die Android-Plattform. Beschrieben werden die Architektur und grundlegende Konzepte von Android. Anhand eines illustrierten Beispiels wird in die Entwicklung eingeführt.
Teil 1   Teil 2   

Der ein oder andere hatte Ende letzten Jahres sicher erwartet, dass ein vollständiges Telefon vorgestellt wird, aber Google verfolgt augenscheinlich eine andere Idee. Ein vollständig quelloffenes System, programmierbar über Java, ausgestattet mit einem umfangreichen, von Google aufgepeppten API, soll das Interesse der Entwickler wecken. Eine wesentliche Annahme dabei ist, dass eine mobile Internetverbindung bald zur (bezahlbaren) Grundversorgung gehört. Die gebündelte Kreativität der Entwicklergemeinde bringt dann einen Schwung an Applikationen, Modifikationen und Tools auf den Markt, von der andere Mobilplattformen nur träumen. Und das, bevor es überhaupt ein einziges Gerät gibt, das die Android-Plattform einsetzt. Die Einreichungen zur ersten Phase der Google Android Code Challenge geben Google Recht: Die Plattform hat ein beachtliches Interesse geweckt und vielversprechende Ideen hervorgebracht. Die Rechnung scheint aufzugehen.

Warum sollten Sie sich mit Android beschäftigen? Erstens ist sicher, dass der Trend deutlich stärker zu mobilen, vernetzten Applikationen geht. Eine ständige, schnelle Internetverbindung und GPS gehören ebenso wie hochauflösende Displays und intelligente Eingabesysteme zur Grundausstattung moderner Endgeräte. Dieses Potenzial will genutzt werden. Mit der Android-Plattform wird Google den Markt aufräumen – die mächtigen Projektpartner in der Open Handset Alliance [1] lassen dies zumindest vermuten. Im Bereich der mobilen Applikationen wird also jeder über kurz oder lang über Android stolpern – ein früher Einstieg schadet demnach nicht.

Und zweitens wird einem der Einstieg in das Thema selten so leicht gemacht wie bei Android. Keine Registrierung, keine teure IDE, keine Hardware ist nötig, um in Java schnell die erste eigene Anwendung zu erstellen. Besonders hervorzuheben sind die von Google bereitgestellten APIs, welche die Mash-Up-Gedanken des Web 2.0 aufs Handy bringen: Kombiniere einfache Elemente und erhalte eine nützliche Anwendung. Dabei gilt einmal mehr: Keep it simple – es handelt sich schließlich immer noch um ein Mobiltelefon.

Was ist Android?
Android ist eine vollständige Plattform für mobile Geräte. Sie bringt ein Betriebssystem, eine Laufzeitumgebung, ein Anwendungsframework und fertige Kernanwendungen mit. Ist passende Hardware vorhanden, reicht es also, Android zu installieren, um ein Smartphone zu erhalten. Soweit die Theorie. Die passende Hardware gibt es aber noch nicht zu kaufen und die Plattform ist auch noch nicht fertig. Dennoch sollen bis zum Ende des Jahres 2008 Android-Telefone verfügbar sein. In der Zwischenzeit kann man mit dem Android SDK Anwendungen entwickeln und mit dem mitgelieferten Emulator testen.

Android ist im Umfang etwa vergleichbar mit Windows Mobile, Symbian OS oder der iPhone Plattform. Es ist allerdings darauf ausgelegt, den Anwendungsentwicklern maximalen Nutzen zu bieten: Die Plattform ist quelloffen und leicht erweiterbar. Man kann in Java programmieren. Alle Möglichkeiten der Hardware können genutzt, Applikationen nach Belieben ergänzt oder ersetzt werden (auch Telefonieapplikationen).

In der Summe erhält der Entwickler mit Android Freiheiten, die er auf anderen Plattformen nicht hat, und zum anderen erhält er Werkzeuge, mit denen er mobile Anwendungen außergewöhnlich komfortabel entwickeln kann. Beides zusammen soll dazu führen, dass die besten mobilen Anwendungen auf Basis von Android entstehen.

Architektur der Plattform
Um einen Überblick über Android zu bekommen, muss man sich näher mit der Architektur der Plattform beschäftigen. Android besteht aus folgenden Komponenten (Abb. 1):

  • Betriebssystem: Android nutzt den Linux Kernel 2.6. Der Kernel stellt die grundlegenden Systemdienste wie Speicher- und Prozessverwaltung, Netzwerkkommunikation und die Hardwareabstraktionsschicht zur Verfügung. Als Entwickler mobiler Anwendungen kann mir das theoretisch egal sein, da meine Anwendungen nicht direkt mit dem Betriebssystem kommunizieren werden (siehe weiter unten Android Runtime). Entwickler von Treibern und Erweiterungen werden sich aber vermutlich freuen, dass Linux verwendet wird und keine obskure Eigenentwicklung.

  • Systembibliotheken: Android enthält einige C/C++-Bibliotheken, die Funktionalitäten für das Android-Laufzeitsystem bereitstellen. Zum Beispiel 3D-Bibliotheken, Medien-Codecs und anderes mehr. Als Entwickler kommt man mit diesen Bibliotheken nicht in Berührung, da sie durch die Laufzeitumgebung gekapselt sind.

  • Android Runtime: Alle Android-Anwendungen laufen in einem eigenen Prozess in einer Instanz der Android-Laufzeitumgebung. Die Laufzeitumgebung heißt Dalvik Virtual Machine (VM). Das ist eine von Google entwickelte, für mobile Geräte optimierte virtuelle Maschine, die den Android-eigenen Bytecode ausführt, den so genannten Dalvik-Bytecode. Wichtig: Die Dalvik VM bringt nicht alle Java APIs einer Java Runtime mit. Die wichtigsten APIs sind aber dabei, und man kann eigene JAR-Bibliotheken mit seiner Anwendung mitliefern.

  • Anwendungsframework: Das Anwendungsframework enthält die grundlegenden Bausteine und APIs, mit denen Android-Anwendungen entwickelt werden. Es ist damit die wichtigste Schnittstelle für alle Android-Anwendungen.

  • Anwendungen: Die Android-Plattform liefert die wichtigsten Anwendungen für ein Smartphone bereits mit: Telefonie, Kontakte, Kalender, Webbrowser, Google Maps und weitere. Alle Anwendungen werden in Java geschrieben und verwenden die Android Runtime. Es ist bisher nicht vorgesehen, dass man native Anwendungen in C/C++ schreibt, die direkt auf Systembibliotheken oder den Linux Kernel zugreifen. Eine echte Besonderheit von Android ist, dass Anwendungen nicht voneinander isoliert sind, sondern über einfache Mechanismen lose miteinander gekoppelt werden können. Entwickler können, wenn die Anwendungen entsprechend gebaut sind, einzelne Funktionalitäten anderer Anwendungen für ihre Anwendung nutzen. Beispiel: Ich möchte in meiner Anwendung die Möglichkeit bieten, einen Kontakt auszuwählen. Anstatt dafür meinen eigenen Dialog zu bauen, springe ich einfach in die Kontaktverwaltungsanwendung. Der Benutzer wählt dort den Kontakt aus, und die aufgerufene Anwendung liefert mir den ausgewählten Kontakt zurück. Auf diese Weise kann ich andere Anwendungen als Dienste betrachten und bei Bedarf in meine Anwendung integrieren.

Android erscheint vollständig. Es bringt alle Komponenten mit, um vollwertige Anwendungen auf mobilen Geräten laufen zu lassen. Android stellt eine Abstraktionsschicht für die Anwendungen bereit, sodass diese sich nicht übermäßig mit gerätespezifischen Eigenschaften anstrengen müssen. Alle Anwendungen sind gleichberechtigt, auch die mit dem System ausgelieferten machen keine Ausnahme: Das gibt dem Entwickler viel Spielraum. Entwickelt wird in Java – das verspricht eine hohe Produktivität bei der Entwicklung der Anwendungen, da die wichtigsten Java APIs verwendet werden können. Zusätzlich sind Google-Anwendungen und APIs mitgeliefert, die leicht integriert werden können (z.B. Google Maps). Vor allem die lose Kopplung der Anwendungen ist interessant: Sie ermöglicht es, bestehende Anwendungen leicht in seiner eigenen Anwendung zusammen zu integrieren und damit ähnlich Web 2.0 Mash-Ups schnell hochwertige Anwendungen zu konstruieren.

Bausteine einer Android-Anwendung
Android gibt die Struktur einer Anwendung und deren Kernbausteine vor. Jeder Entwickler muss diese Bausteine und deren Zusammenspiel kennen. Dabei gilt, dass Android-Anwendungen nicht isoliert zu betrachten sind, sondern mittels einfacher Mechanismen untereinander kommunizieren können. Abbildung 2 zeigt das Zusammenspiel.

  • Eine Activity ist der sicher am meisten genutzte Baustein. Er entspricht üblicherweise einer Maske auf dem Bildschirm. Die Activity trägt eine View, die das Layout und die Bedienelemente der Maske definiert. Die Activity selbst definiert, wie auf Ereignisse der View (z.B. Klick eines Buttons) reagiert werden soll, und sie kann die Inhalte der View verändern. Sie ist damit ein Kernelement der Dialogsteuerung. Eine Activity hat einen Lebenszyklus (Lifecyle). Dieser ist bei Android sehr wichtig, da die Plattform zur Optimierung des Ressourcenverbrauchs Activities jederzeit beenden kann. In einer Activity können daher Callbacks für die Lifecycle-Methoden der Plattform erstellt werden. Dies geschieht, indem die entsprechenden Methoden überschrieben werden. So ist es zum Beispiel möglich, Daten zu sichern, bevor die Plattform die Anwendung aus dem Speicher wirft.

  • Eine View ist dafür verantwortlich, einen Bereich des Bildschirms zu zeichnen und Benutzereingaben entgegenzunehmen. Ähnlich wie bei Java Swing können Container Views definiert werden, die andere Views enthalten und sie mit einer bestimmten Layout Engine zueinander anordnen. In Android können Views über XML-Dateien definiert und von einer Activity referenziert werden.

  • Intents werden dazu verwendet, um von einer Activity zu einer anderen Activity zu springen. Ein Intent beschreibt eine Operation, die eine Activity ausführen will. Beispiel: In einer Kontaktverwaltung gibt es zwei Activities, eine zum Anzeigen der Kontaktliste und eine zum Editieren eines Kontakts. Wenn der Benutzer in der Kontaktliste auf einen Kontakt klickt, löst die Activity den Intent EDIT aus, worauf die Activity mit der Kontaktpflege aufgerufen wird. Die Activities sind also nicht hart im Code miteinander verdrahtet. Die auslösende Activity weiß nicht, welche Activity letztlich den Intent behandeln wird. Das entscheidet die Plattform zur Laufzeit anhand so genannter IntentFilter. Diese legen für eine Activity fest, auf welche Intents sie reagieren sollen. Die hier vorzufindende lose Kopplung der Activities ist ein wesentliches Konzept von Android.

  • IntentReceiver können ähnlich wie Activities auf Intents reagieren, sie haben jedoch keine View. Das heißt: Sie werden nicht am Bildschirm angezeigt. Sie können aber dazu verwendet werden, um beispielsweise auf externe Ereignisse wie einen Telefonanruf zu reagieren. Sie können daraufhin zum Beispiel einen Service starten oder eine Notification anzeigen. Alternativ wäre auch denkbar, bei Anrufen von einer bestimmten Nummer einfach den Anruf abzulehnen. So hat man seine konfigurierbare Telefonruhe.

  • Ein Service ist ein Dienst, der ohne Anzeigeelemente im Hintergrund einer Anwendung läuft. Zum Beispiel soll ein MP3-Spieler die Musik auch dann abspielen, wenn andere Activities im Vordergrund sichtbar sind. Das Abspielen der Musik würde man als Service realisieren. Activities können wiederum einen Service steuern, um zum Beispiel die Musik zu starten oder anzuhalten. Services haben ähnlich wie Activities einen Lifecycle, werden aber nach Möglichkeit nicht beendet. Sollte das doch einmal passieren, startet Android den Service wieder, sobald genügend Ressourcen zur Verfügung stehen.

  • Notifications sind Benachrichtigungen, die dem Benutzer prominent am oberen Rand des Android-Bildschirms angezeigt werden, um ihn auf ein Ereignis unabhängig von der gerade laufenden Anwendung hinzuweisen. Zum Beispiel kann man den Benutzer damit darauf aufmerksam machen, dass eine SMS für ihn angekommen ist. Wenn eine Notification vom Benutzer geöffnet wird, kann diese wiederum einen Intent absetzen, der eine Activiy startet.

  • ContentProvider bieten eine Datenzugriffsschicht für Activities, IntentReceiver und Services. Android-Anwendungen können ihre Daten in einer SQL-Datenbank speichern, die vom Framework bereitgestellt wird. Activities können direkt auf diese Datenbank zugreifen. Wenn allerdings Daten auch anderen Anwendungen zur Verfügung gestellt werden sollen, ist ein ContentProvider nützlich, den man bei der Laufzeitumgebung registriert: Der ContentProvider kann anwendungsübergreifend genutzt werden, um die von ihm verwalteten Daten zu lesen und zu ändern. Zum Beispiel erlaubt es die Kontaktverwaltung anderen Anwendungen, selbst die Liste der Kontakte auszulesen oder zu ändern. Dafür stellt sie einen ContentProvider bereit.

  • Das Android-Manifest enthält die gesamte Anwendungskonfiguration in einer XML-Datei. Die Anwendungskonfiguration definiert, aus welchen Activities, IntentFiltern, IntentReceivern, Services und anderem die Anwendung aufgebaut ist und wie die Komponenten konfiguriert sind. Zum Beispiel wird hier definiert, auf welche Intents eine Activity reagieren soll. Zusätzlich wird im Manifest definiert, welche Zugriffsrechte eine Anwendung benötigt, wie zum Beispiel auf das GPS-System.

  • Ressourcen: Android liefert ein Ressourcen-Framework mit, um Ressourcen abzulegen und darauf zuzugreifen (Strings, Bilder, aber auch Layouts der Views). Es ist damit relativ einfach möglich, Ressourcen internationalisiert oder auch gerätespezifisch abzulegen.

Teil 1   Teil 2   

Anzeige

Kommentare

Gravatar Stefan 14.11.2010
um 16:09 Uhr
Super Beitrag! #zitieren

Anzeige

zurück zum Seitenanfang