Doxygen ist ein sehr umfangreiches Programm zur automatischen Erzeugung einer Dokumentation aus dokummentiertem Quellcode. Diese kann neben HTML auch als PDF, HtmlHelp (CHM), Man, LaTex und RTF ausgegeben werden. Zum Funktionsumfang gehört unter anderem eine eingebaute Suchfunktion und das Einbetten von UML-Diagrammen mit Hilfe von Graphwiz.

Zu den unterstützten Sprachen gehören unter anderem C, C++, C#, Java, PHP und Fortran. Obwohl Doxygen keine eingebaute Unterstützung von Visual Basic .NET hat, lässt sich diese mit Hilfe eines Filters nachrüsten.

Visual Basic .NET Filter

Inspiriert durch den VB Filter von Mathias Henze, der leider viele Eigenheiten von VB.NET nicht unterstützt, habe ich einen neuen VB.NET Filter geschrieben. Dieser unterstützt neben Klassen-Deklarationen auch Strunkturen, Schnittstellen, Enums und Declares. Als Member werden neben einfachen Feldern, Methoden und Funktionen, auch Eigenschaften erkannt.

Die Funktionsweise entspricht im Ansatz dem alten VB Filter. Die Notation und Syntax wird so verändert, dass sie der üblichen C# Notation ähnelt und von Doxygen als solche erkannt wird. So werden beispielsweise Zugriffsmodifikatoren und einige andere Schlüsslwörter klein geschrieben, sowie Klammern und Semikolons eingefügt.

Im Gegensatz zum alten Filter von Mathias Henze, werden Typen vor die Bezeichner gesetzt (statt mit “As” dahinter), Basisklassen und implementierte Schnittstellen (Inherits, Imports) sowie Arrays werden korrekt ausgegeben und Inline-Kommentare werden teilweise umgeschrieben.

Beide Filter im Vergleich:

Beispiel:

Einige Beispiele zum Vergleichen der beiden Filter gibt es auf der Projektseite des neuen VB.NET Filters. Die Dokumentation der Beispieldateien im Projektrepository wird automatisch jeweils mit dem alten und dem neuen Filter erzeugt. Alle anderen Einstellungen im Doxyfile (auch im Beispielordner zu finden) bleiben identisch.

• Zum Vergleich herangezogene Dateien:
  • http://trac.sevo.org/projects/doxyvb/browser/trunk/samples/
• Dokumentation der Beispieldateien mit dem VB Filter von Mathias Henze:
  • http://trac.sevo.org/doxyvb.old/html/index.html
• Dokumentation der Beispieldateien mit dem neuen VB.NET Filter:
  • http://trac.sevo.org/doxyvb/html/index.html

Fazit:

Mit dem neuen VB.NET Filter lassen sich problemlos Visual Basic .NET Projekte mit Doxygen dokumentieren. Zwar werden keine Verlinkungen zur MSDN hinzugefügt, wie bei Sandcastle, dafür können aber UML-Diagramme hinzugefügt, oder Ordner und Dateien dokummentiert werden.

Alle Klassen, Strukturen und Schnittstellen werden mit allen ihren Membern richtig dargestellt und miteinander in der Dokumentation verlinkt. Nur der Quellcode lässt sich nicht korrekt in der Dokumentation anzeigen, da Doxygen die gefilterte Fassung übernimmt. Dies kann man jedoch auch mit dem geschickten Einsatz von <A HREF=”…”>…</A> Tags in den Kommentaren verbessern, indem man die Originaldateien in der Dokumentation verlinkt. Durch den Einsatz von SvnView oder Trac lassen sich sogar einzelne Zeilen verlinken.

Links:

Doxygen: http://www.stack.nl/~dimitri/doxygen/

VB Filter von Mathias Henze: http://www.stack.nl/~dimitri/doxygen/helpers.html

VB.NET Filter von Vsevolod Kukol: http://trac.sevo.org/projects/doxyvb/

Das Visual Studio .NET bietet die Möglichkeit Kommentare mit XML Tags zu versehen, die vom Objektbrowser automatisch erkannt und angezeigt werden. Diese werden beim Erstellen eines Projektes automatisch in eine XML Datei exportiert und können gemeinsam mit der Assembly ausgeliefert werden. Wird diese XML Datei beim Importieren einer Assembly als Verweis in ein neues Projekt gefunden, erkennt Visual Studio die Zusammenhänge und zeigt automatisch die passende Dokumentation an.

Das folgende Beispiel zeigt eine dokumentierte Schnittstelle und ihr Aussehen im Objektbrowser:

''' <summary>
''' Sample Interface 1
''' </summary>
''' <remarks>A simple interface</remarks>
Public Interface IInterface1
    ''' <summary>
    ''' Simple string property
    ''' </summary>
    ''' <value>some string</value>
    ''' <remarks>stores a string value</remarks>
    Property Property1() As String
    ''' <summary>
    ''' simple integer property
    ''' </summary>
    ''' <value>some numeric value</value>
    ''' <remarks>stores a numeric value</remarks>
    Property Property2() As Integer
End Interface

Diese Funktion ist jedoch sehr rudimentär und an Visual Studio gebunden. Die Dokumentation lässt sich weder mit Klassendiagrammen verknüpfen, noch kann diese in gängige Formate wie PDF oder HTML exportiert werden. Soll eine Dokumentation im HTML Format erzeugt werden und eventuell sogar in ein CMS System wie Trac eingebunden werden, muss Visual Studio passen und eine Zusatzsoftware zum Einsatz kommen.

Bei meiner Suche nach einer handfesten Lösung für Visual Basic Projekte konnte ich lediglich zwei Programme finden, die zuverlässig den Quellcode analysieren und eine gute Dokumentation erzeugen können.

Die Entwicklung von plattformunabhängiger Software ist immer mit einem relativ hohen Mehraufwand verbunden. Mit Hilfe von Cygwin ist es möglich native Linux Anwendungen auch für Windows zu kompilieren, wobei meistens der Quellcode zusätzlich angepasst werden muss. Oft werden auch komplett getrennte Code-Repositories verwendet, da die zusätzliche Pflege des Kompiliervorganges für viele zu kompliziert erscheint.

Als Alternative zur nativen Anwendung kann ein Framework wie Java, oder .NET verwendet werden. Allerdings sehen die so entwickelten Anwendungen nicht auf jedem Betriebssystem gleich aus und die Laufzeitumgebung muss auf dem Zielsystem installiert sein. Da die .NET Laufzeitumgebung bereits in Windows integriert ist, hat diese einen entscheidenden Vorteil gegenüber Java. Der Benutzer muss keine zusätzliche Software installieren und die Anwendungen starten schneller. Unter Linux und Mac OS verschwindet dieser Vorteil allerdings, denn Microsoft bietet keine .NET Implementierung für andere Betriebssysteme. Hier kann auf die freie .NET Implementierung names “Mono” zurückgegriffen werden.

Mono

Mono ist eine freie .NET Implementierung, die sich an die ECMA Standards für C# und CLR hält. Das opensource Projekt unterliegt der GPL und MIT X11 (genauereres weiter unten) und wird von Novell gesponsort. Die Laufzeitumgebung läuft unter Linux, Mac OS X und neuerdings auch auf dem iPhone. Damit kann beinahe jede .NET Anwendung (auch ASP.NET), direkt auf einem dieser Betriebsysteme ausgeführt werden und muss nicht extra übersetzt werden. Dies funktioniert jedoch nur solange die Anwendung nicht die Windows API, oder neuste .NET Technologien verwendet.

So vielversprechend das alles auch klingen mag, kommt es in der Realität oft zu Problemen. So ist Windows Forms nur bis zur Version 2.0 komplett implementiert. Da es zudem unter Unix keine WinForms gibt, versucht Mono die Formulare selber zu rendern, was leider nicht immer gut funktioniert. Zusätzlich fehlen unter Mono die visuellen Stile von Windows.

.NET 3.5 Windows Form unter Windows

Folgende Screenshots zeigen die Problematik:

Hierfür habe ich einfach ein neues Windows Projekt in VS 2008 erstellt und einige einfache Controls auf dem Formular positioniert. Die resultierende Assembly habe ich dann normal unter Windows und anschliessend unter Ubuntu 10.04 mit mono gestartet.

.NET 3.5 Windows Form unter Ubuntu 10.04 mit Mono

Die Unterschiede sind deutlich erkennbar. Weder die Größen noch die Positionierung der Controls stimmen überein. Die Textelemente der einzelnen Controls sind falsch ausgerichtet. Das Fenster weist zudem andere Dimensionen auf und sieht insgesamt schlechter aus, als das Original unter Windows.

Eine mit Visual Studio entwickelte Anwendung läuft also unter Linux, jedoch mit großen Abstrichen bei der Grafik. Für den Benutzer kann das schnell zu einem K.O. Kriterium werden, vor allem wenn grafisch anspruchsvollere Konkurrenzprodukte verfügbar sind.

Welche Möglichkeiten gibt es, um .NET Anwendungen auf allen Systemen gleich aussehen zu lassen?

Ich möchte als Erstes anhand des HelloWorld beispiels den Grundaufbau eines Android Projektes und der GUI einer Aktivität erläutern.

Neues Projekt erstellen

Zum Erstellen eines neuen Android Projektes steht im Menü “File” -> “New” der Eintrag “Android Project” zur Verfügung.

Project Name: der Name des Projektes ohne Leer-/Sonderzeichen

Build Target: die Zieplattform bzw. die zu verwendende API. Mit 1.6 ist man für den Anfang auf der sicheren Seite. Sollte man später doch eine neuere API benötigen, kann man diese nachträglich im Manifest ändern.

Application Name: Der lesbare Name der Anwendung, den auch der Benutzer sieht

Package Name: der Java Paketname sollte mindestens einen Punkt haben. Üblicherweise trägt man hier den Entwicklernamen, Firmennamen, oder die eigene Domain mit ein. Der Name muss eindeutig sein, da Android diesen zur Identifizierung der Anwendung verwendet und darf natürlich weder Sonderzeichen, noch Leerzeichen enthalten.

Create Activity: Erzeugt direkt eine fertige Aktivität, die als Startpunkt für das Programm dient. Diese wird auch im Android Launcher sichtbar.

Mit einem Klick auf “Next” kann man sich noch ein paralleles Testprojekt erstellen lassen. Da dies jedoch für den Anfang nicht notwendig ist, beendet man den Wizard mit “Finish”

Ordnerstruktur

Ein Projekt besteht aus vielen Ordnern und Dateien, die über den Package Explorer durchsucht werden können.

Hier sind die wichtigsten:

src: In diesem Ordner befindet sich der eigentliche Quellcode der Anwendung. Dieser ist nach Paketen und Klassen sortiert. Jede Klassendefinition (Quellcode) muss dabei in einer eigenen *.java Datei gespeichert werden.

res: beinhaltet alle Resourcen, die das Programm benötigt. Dazu gehören Grafiken, und XML Dateien.

AndroidManifest.xml: diese XML Datei beinhaltet alle wichtigen Informationen zu dem Projekt. Neben dem Namen, der API, Kompilieroptionen, usw. werden hier auch alle Aktivitäten und Intents deklariert.

Der Quellcode

In meinem Beispiel habe ich im Wizard “Create Activity” ausgewählt und den Namen “HelloActivity” angegeben. Wie man sieht hat der Wizard die Klasse erzeugt und auch richtig benannt.

Öffnet man die Datei “HelloActivity.java”, so findet man den automatisch vom Wizard erzeugten Quellcode:

package com.sevo.helloandroid;

import android.app.Activity;
import android.os.Bundle;

public class HelloActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}

Dieser Beispielcode ist eigentlich ganz simpel. Hier wird eine Klasse HelloActivity von der Basisklasse Activity abgeleitet und die Methode onCreate überschrieben.

Wie bei einer Ableitung üblich, ruft die Methode onCreate zuerst die gleichnamige Methode der Basisklasse auf, wonach die Anweisung setContentView(R.layout.main) ausgeführt wird.

Damit ist der Quellcode der HelloAndroid App fertig! Die Methode setContentView wird nämlich mit einer Resource parametrisiert. Das R steht dabei für Resources, layout für den Ordner layout und main für die Resource main.xml, die die GUI der Aktivität beschreibt. Sie lädt also die Resource und generiert das Layout des Fensters.

Und damit kommen wir zu den Resourcen.

Resourcen (res Ordner)

Die Resourcen sind in drei Hauptkategorien unterteilt.

drawable

Die drawable-* Ordner beinhalten Grafiken für verschiedene Auflösungen. Möchte man eine Grafik in die Anwendung einbinden, so muss man diese für jede Auflösung optimieren und in dem jeweiligen Ordner speichern. Mehr dazu gibt es später in einem separaten Artikel.

layout

Beinhaltet XML Dateien zur Beschreibung von GUIs.

Die Beispilaktivität HelloActivity enthält eine Referenz zu der main.xml im Ordner res/layout. Wenn man diese öffnet, zeigt Eclipse eine Design-Ansicht. In der Mitte sieht man die Vorschau der GUI und auf der linken Seite eine Auswahl von Elementen. Unter der Ansicht findet man noch den Reiter “Properties”, den man sich idealerweise auf die rechte Seite vom Designer zieht.

Der Wizard hat bereits ein TextView Element eingefügt. Klickt man dieses an, werden dessen Eigenschaften im Properties Tab angezeigt. Unter der Designvorschau kann die “main.xml” direkt betrachtet werden. Es ist also möglich und manchmal sinnvoll das Design auch manuell über den XML Code zu bearbeiten.

Die Beispiel-XML sieht so aus:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:orientation="vertical"
 android:layout_width="fill_parent"
 android:layout_height="fill_parent"
 >
<TextView
 android:layout_width="fill_parent"
 android:layout_height="wrap_content"
 android:text="@string/hello"
 />
</LinearLayout>

Die interessanteste Zeile stellt in diesem Beispiel die TextView Eigenschaft android:text=”@string/hello” dar. Wie man in dem dem Designer erkennen kann, wird in dem TextView Element ein anderer Text angezeigt, als in der XML Datei angegeben. Es handelt sich hierbei wieder um eine Referenz zu einer anderen Resource, nämlich den Strings.

Klickt man auf den “…” Button neben den Eigenschaftswert “Text”, wird ein neues Fenster zur Auswahl von Strings geöffnet. Hier können bereits vorhandene Strings ausgewählt und neue erzeugt werden.

Die bereits besprochene Methode setContentView(R.layout.main) wertet die main.xml aus und folgt auch den darin enthaltenen Referenzen. Dadurch wird als Text der mit hello bezeichnete String “Hello World, HelloActivity!” angezeigt.

values

In dem Ordner values werden XML Dateien mit Strings, oder anderen Resourcen abgelegt.

Strings bestehen aus einem Namen sowie einer dazugehörigen Zeichnkette und werden in der Datei res/values/strings.xml gespeichert. Öffnet man diese Datei, wird der Resource Designer angezeigt. Hier kann man bereits vorhandene Strings bearbeiten, oder neue hinzufügen.

Öffnet man die XML Ansicht, so findet man den folgenden Inhalt:

<?xml version="1.0" encoding="utf-8"?>
<resources>
 <string name="hello">Hello World, HelloActivity!</string>
 <string name="app_name">Hello Android</string>
</resources>

Auf diese Weise lassen sich nicht nur Strings sondern alle erdenklichen Informationen (String Felder/Arrays, Konstanten, Farbcodes, etc) speichern. Möchte man ein Programm in mehrere Sprachen übersetzen, erstellt man für jede Sprache eine eigene XML Datei und muss nichts am Quellcode ändern (hierzu später mehr).

AndroidManifest.xml

Wie bereits erwähnt, beschreibt diese Datei alle Eigenschaften des Projektes. Man kann entweder die Unterstützung von Eclipse in Anspruch nehmen, oder die XML Datei direkt bearbeiten.

Am interessantesten sind die Abschnitte Application und Permissions.

Unter Application werden neben den Grundinformationen wie Name oder Icon auch die Aktivitäten festgelegt. Es reicht also nicht aus nur eine neue Aktivitätsklasse zu erzeugen, damit diese auch ausgeführt wird. In der AndroidManifest.xml muss diese deklariert und mit Regeln versehen werden.

In dem automatisch erzeugten Beispiel finden wir den folgenden Abschnitt:

<application android:icon="@drawable/icon" android:label="@string/app_name">
 <activity android:name=".HelloActivity"
 android:label="@string/app_name">
 <intent-filter>
 <action android:name="android.intent.action.MAIN" />
 <category android:name="android.intent.category.LAUNCHER" />
 </intent-filter>
 </activity>

Die HelloActivity bekommt hier einen Intent Filter zugewiesen. Dieser legt fest unter welchen Bedingungen die Aktivität wie gestartet werden soll. In diesem Beispiel ist die Aktion MAIN und die Kategorie LAUNCHER. Dies erlaubt also einen Start der HelloActivity aus dem Android Programm-Launcher. Es sind natürlich sehr viele verschiedene Bedingungen möglich. Weitere Informationen gibt es unter http://developer.android.com/reference/android/content/Intent.htm.

Fazit

Mit den gemachten Erfahrungen lassen sich problemlos komplette Aktivitäten erstellen, ohne auch nur eine Zeile Code geschrieben zu haben. Natürlich kann man auf die Verwendung von XML Dateien komplett verzichten und alle GUI Elemente direkt im Quellcode erzeugen. Aber dazu später mehr…

Mit dem Debug oder Run Button in der Symbolleiste kann das Programm im Emulator gestartet werden.

Android SDK

Die Android SDK kann von http://developer.android.com/sdk/index.html heruntergeladen werden. In der ZIP (Windows) bzw. TGZ (Linux) Datei befindet sich der SDK Manager und einige Tools zum Debuggen.

Um die SDK zu installieren muss man das Archiv entpacken und den SDK Manager starten (Linux: tools/android, Windows: SDK Setup.exe). Dieser bietet beim ersten Start eine Auswahl an Paketen an, die man einzeln mit “Accept”, oder “Reject” an- und abwählen kann. Vor der Installation sollte man daran denken, dass der SDK Manager alles in sein aktuelles Verzeichnis installiert. Man wird also nicht nach einem Installationsordner gefragt.

Zur Auswahl stehen mehrere SDK Versionen angefangen mit 1.1 (API2) bis 2.1 (API7) und neuer. Natürlich kann man alle API Versionen installieren und sich später darüber Gedanken machen, was man wirklich braucht. Ich mag es persönlich nicht, wenn unnötig viel installiert wird. Deshalb hier ein Paar Empfehlungen:

API 2.X: sollte gewählt werden, wenn man immer auf dem aktuellsten Stand sein will und weiss, dass man Teile der neueren API braucht.

API 1.6: ist nicht soo aktuell, aber sehr viele Geräte (sowohl ältere als auch neuere!) laufen noch mit Android 1.6, will man also eine Anwendung schreiben, die auf möglichst vielen Geräten läuft, ist das die beste Wahl.

Während der Installation kann die Fehlermeldung “Failed to fetch URL” kommen. In diesem Fall sollte man unter “Settings” -> “Misc” die Checkbox “Force https:// …” aktivieren. Danach klapps auch mit dem Download.

HINWEIS: den SDK Ordner kann man hinlegen wohin man möchte. Unter Windows habe ich mir unter C: einen Android Ordner dafür angelegt. Alle Einstellungen werden sowieso im Benutzerordner gespeichert.

Eclipse

Die Eclipse IDE kann von http://www.eclipse.org/downloads/ heruntergeladen werden.

Die beste Wahl ist “Eclipse IDE for Java Developers”. Dieses Paket ist kompakt und beinhaltet alles Notwendige.

Nach der Installation kann man Eclipse das erste Mal starten und ein Workspace anlegen (wird automatisch angeboten).

ADT Plugin für Eclipse

Eclipse kann von sich aus nichts mit der Android SDK anfangen. Hierfür benötigt man die “Android Development Tools”, die direkt in Eclipse installiert werden können.

1. “Install new Software” im “Hilfe” Menü auswählen
2. rechts Oben den Button “Add…” anklicken
3. bei “Location” folgende Adresse eintragen: https://dl-ssl.google.com/android/eclipse/ und mit OK bestätigen
   
4. Die Liste wird nun aktualisiert und man kann “Android Development Tools” auswählen
5. Mit “Next” fortfahren und eventuelle Warnung über unsichere Quellen ignorieren
6. Ist die Installation fertig, fragt Eclipse ob es neu starten, oder die Konfiguration Übernehmen soll. Hier sollte man unbedingt den Neustart wählen
7. Als Letztes muss man dem ADT Plugin noch mitteilen, wo sich der SDK Ordner befindet. Hierzu öffnet man das Menü “Windows” -> “Preferences” und wählt den Punkt “Android” (auf der linken Seite) aus. Rechts oben trägt man nun den SDK Ordner unter “SDK Location” ein und bestätigt mit “Apply”.

Ist alles korrekt verlaufen, so werden die vom SDK Manager installierten API Versionen im Preferences Fenster angezeigt.

Weitere Informationen zum ADT Plugin findet man unter http://developer.android.com/sdk/eclipse-adt.html.

Der erste Start mit ADT

Ist alles korrekt installiert, findet man in Eclipse einige neue Android-spezifische Funktionen. Als erstes fällt einem das kleine Handy, bzw. bei neueren ADT Versionen das Android  Symbol in der Symbolleiste auf, über das man den SDK und AVD Manager direkt starten kann. Hier sollte man als allererstes ein “Virtual Device” anlegen (Den SDK Manager findet man auch im Menü “Window”).

Jetzt ist alle bereits für die ersten Gehversuche. Das virtuelle Device kann man testweise manuell starten. Es sieht nicht nur aus wie eine normales Android System, sondern das ist es auch. Man kann also alles machen, was Android hergibt (außer Telefonieren ).

MOTODEV, die Alternative

Da ich selber ein Milestone von Motorola habe, wurde ich auf das Developer Studio von Motorola aufmerksam. Es heisst “MOTODEV Studio for Android” und man kann es unter http://developer.motorola.com/ nach einer Registrierung herunterladen.

Das Studio baut auf einer durch Motorola angepassten Eclipse Version auf. Also Eclipse mit Zusatzfeatures. Dabei sind alle normalen Funktionen von Eclipse erhalten geblieben. Man hat beispielsweise die Wahl zwischen der optimierten MOTODEV und der normalen Java Ansicht. Die zweite sieht aus und verhält sich genauso wie eine unmodifizierte Eclipse Version.

Folgende Vorteile hat MOTODEV im Vergleich zur manuellen Methode:

• mehr Wizards
• (original) ADT Wizards verbessert
• SDK und ADT müssen nicht separat installiert werden
• Virtual Device direkt in die IDE eingebunden
• optimierte Debug Ansicht
• mehr Code Snippets
• mehr Beispiele

Nachteile:

• Registrierung notwendig. ACHTUNG: es wird eine Bestätigungsmail verschickt, also einen Fake Account nutzen, auf den man auch Zugriff hat!
• ADT und SDK Versionen hinken einige Wochen hinterher und kommen aus einem Repository von Motorola

Bevor man mit der Programmierung loslegt, sollte man wissen, dass Android Programme nicht eigenständig sind. Sie sind lediglig Subklassen von bereits vorhandenen Android Klassen, die diese um gewünschte Funktionen erfweitern. Durch die Ableitung von bereits vorhandene Klassen und Einhaltung, bzw. Implementierung der Android API, können diese Klassen von Android zur Laufzeit geladen und instanziert werden. Nichts anderes geschieht beim Start eines “Apps” aus dem Android Launcher.

Basierend auf diesem Wissen stellt sich natürlich sofort die Frage, welche Basisklassen man ableiten muss um überhaupt ein “Hello World” mit einigen Menüs und Fenstern herbeizuzaubern. Hierzu muss man zuerst den Grundaufbau eines Android Apps versetehen.

Activity

Eine Activity ist der Grundstein einer interaktiven Anwendung. Diese beschreibt meistens ein einzelnes Fenster (eigentlich ein Screen, aber Fenster ist leichter zu verstehen), das bestimmte Steuerelemente anzeigt. Jede Activity muss von der Basisklasse Activity abgeleitet sein und zumindest die Methode onCreate überschreiben. Eine Activity kann man (wenn auch sehr abstrakt) mit einem Windows Formular vergleichen. Sie kann verschiedene Steuerelemente haben, ein Menü, usw.

Begriffserklärung: Activity ist eine Interaktion mit dem Benutzer, also eine Benutzer-”Aktivität”, daher der Name “Activity”. Dies war für mich persönlich etwas verwirrend, da man sofort an Programmaktivität und nicht an den Benutzer denkt, wenn man den Begriff liest.

Intent

Intents beschreiben Vorhaben, oder Absichten und sind Instanzen der Klasse Intent. Eine Aktivität wird immer mit einem Intent gestartet, das beschreibt was die Aktivität machen soll. Ein Intent hat immer eine Aktion und optional auch einen Datenverweis. Beispiel: “Starte”, oder “Offne Kontakt xy aus der Kontaktdatenbank”. Zusätzlich haben Intents eine Kategorie, die beischreibt in welchem Kontext die Aktion gestartet wurde (nicht mit der Context Klasse verwechseln).

Wird ein Programm, also eine Aktivität einfach aus dem Launcher gestartet, so wird der Aktion “MAIN” und der Kategorie “CATEGORY_LAUNCHER” zugewiesen. Die Aktivität kann diese Werte abfragen beispielsweise je nach Kontext Steuerelemente ein- oder ausblenden.

Intent Filter

Ein Intent Filter ist das Gegenstück vom Intent. Dieser beschreibt welche Intents eine Aktivität akzeptiert. Startet Android oder ein anderes Programm eine Aktivität mit einem Intent, so kann die zu startende Aktivität den Startversuch verweigern oder annehmen (in der Realität überprüft Android vor dem Start einer Aktivität. ob der Filter passt und startet diese ggf. erst garnicht).

Auf diese Weise lässt sich zum Beispiel auch kontrollieren, ob ein Programm (bzw. eine Aktivität) im Launcher von Android auftaucht. Wird ein Programm installiert, wertet Android die Filter der Aktivitäten des Programms aus. Ist die Aktion MAIN mit der Kategorie LAUNCHER vorhanden, so wird ein Icon im Launcher angelegt. Fehlt dieser Filter, taucht das Programm im Launcher garnicht erst auf.

Intent Receiver (Service/Dienst)

Möchte man ein Programm schreiben, das keine Interaktion mit dem Benutzer braucht und im Hintergrund läuft, so kann man einen Receiver verwenden. Hierzu leitet man die Basisklasse BroadcastReceiver ab und überschreibt die Methode onReceive. Genau wie eine Aktivität wird ein Receiver mit einem Intent gestartet. Man könnte beispielsweise ein Intent in bestimmten Zeitabständen erzeugen und den Receiver auf diesen reagieren lassen. Besonders sinnvoll ist das Ganze um Daten von bestimmten Ereignissen im Hintegrund zu sammeln oder in regelmässigen Abständen einen Server abzufragen.

Content Provider

Die meisten Programme müssen irgendwo ihre Daten ablegen. Dies kann mit Hilfe von Dateien oder Datenbanken geschehen. Android hat für diesen Zweck SQLite mit an Bord. Man kann Daten entweder direkt in einer SQLite Datenbank speichern, oder den Content Provider verwenden. Der Content Provider ist dabei ein gemeinsamer Speicher (Datenbank), auf den alle Android Programme zugreifen können. So ist auch der Zugriff auf die Kontakte, oder Termine über den Content Provider möglich. Möchte man den Zugriff auf das eigene Programm einschränken, so kann man eine eigene Datenbank anlegen.

Die SQLite Datenbanken vereinfachen die Datenverwaltung enorm. Allerdings kann es auch sinnvoll sein, direkt auf das Dateisystem zugreifen zu können. Es ist natürlich auch möglich strukturierte XML Dateien zu erstellen und diese auf der Speicherkarte zu speichern, oder man generiert Benärdateien. Hier sind keine Grenzen gesetzt.