In der Dokumentation von android.app.Application heißt es:

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

Aber stimmt das so? Oder gibt es doch Fälle in denen es sinnvoll wäre android.app.Application zu nutzen?

Der zweite Teil ist schon korrekt. Ich habe nichts gegen Singletons an sich. Und sie zu nutzen um die Modularisierung der Applikation zu erhöhen ist bestimmt eine gute Idee.

Die Probleme

Aber Singletons haben ein Problem: Sie müssen initialisiert werden. Und das kann recht kniffelig werden.

Der übliche Weg der späten Initialisierung hat recht große Nebenläufigkeitsprobleme. Zu diesem Thema gibt es ausreichend Informationen und Vorschläge, wie man sie teilweise mit komplizierten Techniken wie Doppel-Locking bewältigen kann.

Zudem braucht die getInstance ()-Methode mit großer Wahrscheinlichkeit einen android.content.Context als Parameter. Was gleichzeitig den Aufruf kompliziert und Fehleranfällig macht. Es bedarf nur eines Programmierers im Team, der eine android.app.Activity (aka this) für das getInstance () nutzt und schon hat man sowohl ein Speicherloch als auch einen schwer zu findenden sporadischen Absturz.

Zur Erinnerung: Selbst wenn die App nur eine einzige android.app.Activity hat — sie wird zerstört und neu erstellt wenn das Gerät gedreht wird. Man kann zwar das Neu-Erstellen verhindern, aber dies macht den gesamten Rotationsablauf komplizierter und fehleranfälliger. Man sollte dies wirklich nur dann machen wenn es keine anderer Alternative gibt.

Alternativ könnte man die Singletons im onCreate der Hauptaktivität erstellen. Damit löst man die Probleme der Nebenläufigkeit und verbessert die Lesbarkeit des Codes. Auch kann man durch Verwendung separater createInstance ()-Methoden um die Verwendung eines context-Parameters bei getInstance ()-Methoden herumkommen. Allerdings hat auch dieses Vorgehen ein Problem: Es es gibt viele Fälle bei dem gar keine Activity erstellt wird: android.content.BroadcastReceiver, android.app.Service oder Instrumentation-Tests. Besonders Tests sind ein Problem: Instrumentation-Tests können alle Instanzen außer der Reihe erstellen

Initialisieren in allen Activities und Receivern? Klinkt kompliziert und wiederum Fehleranfällig.

Die Lösung

Aber wir müssen es uns gar nicht so schwer machen. Es gibt ja android.app.Application.onCreate (). Diese Methode wird garantiert nur einmal vor allen anderen Funktionen aufgerufen, dadurch können Probleme mit der Nebenläufigkeit nicht mehr auftauchen – ein if (!initialised) ist nicht mehr nötig. Alle Initialisierungen werden in der korrekten Reihenfolge durchgeführt und this ist ein context, der garantiert so lange gültig ist wie der Prozess läuft.

Um Missverständnisse von vorn herein auszuräumen: Ich sage nicht, dass man android.app.Application verwenden soll um die Singletons zu ersetzten. Das würde zum God-Object Anti-Pattern führen. Die zu initialisierenden Daten sollten auch weiterhin separat gehalten werden.

Zum guten Schluss kann man, wenn nötig, für die Instrumentation-Tests eine MockApplication-Klasse erstellen, welche die Singletons mit Mock-Objekten befüllt.

Reactive Programming ist zur Zeit in. Es verspricht ein einfacheres implementieren von asynchronen Abläufen indem Informationen als Events (oder Messages) von einer Komponente auf die andere übertragen werden können. Für einen kleinen Test von Bluetooth Fähigkeiten implementierte ich eine Android App die als Server oder als Client eingesetzt werden kann und die Daten vom Client zum Server sendet. Da die Kommunikation mit dem Bluetooth Adapter asynchron in einem eigenen Thread laufen muss, kann das reaktive Paradigma hier eingesetzt werden, um die UI-Komponente von der Kommunikations-Komponente zu entkoppeln.

Die App hat nur eine einzige Activity die den Server oder den Client startet und die Ausgabe der Kommunikation macht. Um die Lesbarkeit des Codes zu verbessern benutze ich Android Annotations (http://www.androidannotations.org). Das nächste Bild gibt einen Überblick der Programmdateien.

Für den reaktiven Teil der App setze ich den EventBus von Google Guava (http://code.google.com/p/guava-libraries/) ein. Damit der Bus mit Android Annotations injected werden kann kreiere ich eine eigene annotierte Klasse BtEventBus.

Der Bluetooth Server (im nächsten Bild) öffnet beim Initialisieren auf Zeile 39 ein Server Socket. Wird die App als Server benutzt so wird die startListening() Methode aufgerufen, die dank der @Background Annotation (Zeile 45) in einem eigenen Thread läuft. Der Server wartet dann auf eine eingehende Verbindung (Zeile 52) und liest dann anschliessend periodisch die eintreffenden Bytes aus (Zeilen 53 – 68). Diese sollen dann an die UI weiter gegeben werden. Auch wenn etwas mit der Bluetooth Verbindung schief läuft, dann soll der Benutzer darüber informiert werden.

Diese Benachrichtigung sollte auf keinen Fall im BtServer drin geschehen, denn dadurch würde die Kommunikations-Komponente an die UI gekoppelt werden (z.B. durch eine Referenz auf die MainActivity) und die App würde weniger wartbar. Stattdessen können wir der UI eine Meldung schicken, dass sich etwas Interessantes ereignet hat. Dies ist die Grundidee von Reactive Programming.

Klassisch würde man dazu das Observer Pattern umsetzen, d.h. zwei Interfaces (Subject und Observer) deklarieren und dann bei den entsprechenden Klassen implementieren. Viel einfacher geht es aber mit dem EventBus, der auf Zeile 28 und 29 injected wird. Um noch flexibler zu sein, habe ich dessen Aufruf nochmals in einer Methode signal() (Zeilen 75-77) gekapselt. Somit könnten wir, die Implementation des Informationsaustausches später leicht ändern und z.B. Logging einfügen, oder einen anderen EventBus mit anderer Signatur verwenden. Um die Meldung abzusetzen reicht es ein Objekt einer selbst definierten Klasse (optimalerweise mit dem Namenszusatz Event) an die Methode post() zu übergeben. Die Klasse kann Informationen (hier eine Nachricht) in eigenen Feldern speichern.

Um die Meldungen in der MainActivity zu empfangen reicht es eine Methode zu deklarieren, die einen Parameter vom Typ BtEvent hat und sie mit @Subscribe zu annotieren (Zeilen 52 – 56). Die Methode ist hier ausserdem mit @UiThread annotiert, damit die Ausgabe auf dem Ui-Thread geschieht. Ausserdem muss der Empfänger sich noch beim EventBus registrieren (Zeile 43).

Beim Empfang der Events sind wir aber keinesfalls auf die UI beschränkt: Jedes Objekt kann Events vom EventBus empfangen und ein Event kann auch von mehreren Objekten empfangen werden.

Durch den Einsatz des EventBus wird die Behandlung von asynchronen Abläufen erheblich vereinfacht. Zudem unterstützt er die Implemenierung der losen Kopplung zwischen den Komponenten.

Der Vollständigkeit halber ist unten der BtClient auch noch dargestellt.