Mich persönlich stört diese Neuerung etwas, denn die vorgeschlagene Personenliste erscheint mit einiger Verzögerung (zwischen 1-5 Sekunden) und drückt die eigentlichen Share-Apps nach unten weg, sodass ich immer versehentlich auf einen falschen Kontakt gedrückt habe. Außerdem kann jede App die Anordnung und Auswahl der angezeigten Kontakte selbst bestimmen, was mitunter zu Verwirrung geführt hatte.

Ein wenig Googeln brachte mich zu einem Stackoverflow-Thread mit der passenden Antwort. Diese funktioniert allerdings nur unter gerooteten Telefonen.

Man öffnet einen Dateimanager und legt in dem Ordner „/data/system/ifw/“ eine Datei mit dem Namen „disable_directshare.xml“ an. Der Inhalt der Datei muss folgendermaßen aussehen:

<rules>
  <service block="true" log="true">
    <intent-filter>
      <action name="android.service.chooser.ChooserTargetService" />
    </intent-filter>
  </service>
</rules>

Laut der Erklärung des Stackoverflow-Posters stellt dies einen neuen Eintrag in der Intents-Firewall dar, welche das Popup mit den Kontaktvorschlägen unterbindet.

~ Sebastian

ich hatte letztens eine kleine Idee, für die ich eine VM mit Android benötige. So kann man einfach Apps installieren und ausprobieren, ohne Gefahr zu laufen, dass etwas auf dem eigenen Telefon mitgesammelt wird.

In diesem Blogpost geht es also um die Einrichtung der Android-VM auf einem PC und einigen Tipps/Tricks zur einfacheren Verwendung.

VM aufsetzen

Zu unserem Vorteil haben einige Entwickler einen Port von Android für die x86-Architektur geschrieben, welche wir im Folgenden nutzen werden. Daher lädt man sich zunächst die letzte Version herunter:

https://code.google.com/p/android-x86/downloads/

Ich empfehle das Iso der 4.3er Version. (Aktuellste Version zum Zeitpunkt des Schreibens)

Während das Iso heruntergeladen wird, kann man bereits VirtualBox starten und dort eine neue virtuelle Maschine anlegen.

Bei der Frage nach dem Betriebssystem wählt man „Linux“ bzw. „Linux 2/3 (32 bit)“ aus. Als Namen kann man zum Beispiel „Android“ wählen. Auf jeden Fall wird der Name später noch benötigt, sodass man sich diesen merken sollte.

An Arbeitsspeicher und Festplattenspeicher sollte nicht gespart werden:

• RAM: 1 GB
• Festplattenspeicher: Mindestens 6 GB
• Netzwerk: NAT

Ist die VM erstellt und der Download fertig, so kann man mit der Installation fortfahren.

Dazu startet man die VM und legt das ISO in das virtuelle CD-Laufwerk ein. Auf dem Startbildschirm wählt man den untersten Eintrag „Install to disk“ aus.

Danach sollte eine UI zum Verwalten der Datenträger erscheinen. Normalerweise existiert hier nur ein Eintrag, welchen man mit „New“ und „ext3“ formatiert. Des Weiteren muss noch die Schaltfläche „Bootable“ angewählt werden, damit Android später auch starten kann.

Die Änderungen bestätigt man mit der Auswahl von „Write“ und einem Druck auf die Entertaste.

Als nächstes kommt die Nachfrage, ob das Dateisystem als „read/write“ geschrieben werden soll. Ich habe diese Frage mit „Ja“ beantwort – die Entscheidung ist aber jedem selbst überlassen.

Die Installation des Betriebssystems dauert ungefähr eine Minute und danach kann das System neugestartet werden.

Nun sollte man auch den vertrauten Einrichtungsassistenten sehen und das Androidsystem ganz gewohnt nutzen können.

VM aufwecken

Das Androidsystem geht nach einer Weile der Nichtnutzung in den Standby, wie man es vom Handy kennt. Um das System wieder aufzuwecken, muss man laut der Dokumentation einer der folgenden Tasten mindestens 1 Sekunde lang drücken:

• ESC
• Linke/Rechte Maustaste
• Hoch/Runter-Taste

Bei mir klappte das allerdings nicht wirklich zuverlässig (vielleicht liegt es auch an mir). Daher hab ich in den Einstellungen von Android den Standby abgeschaltet.

Fehlender Mauszeiger

Falls man in der Android-VM den Mauszeiger nicht sehen kann, so liegt das höchstwahrscheinlich an der „Mauszeigerintegration“ von Virtualbox. Schaltet man diese aus, so wird die Maus in der VM gefangen, und kann normal genutzt werden.

Das klappt bei der laufenden VM über „Maschine->Mauszeigerintegration deaktivieren“.

Ist der Mauszeiger in der VM gefangen, so kann man diesen mittels einem Druck auf die rechte Strg-Taste befreien.

ADB Portforward

Um über ADB mit dem System zu interagieren muss man eine Portforwarding-Regel anlegen. Dazu fährt man die VM zunächst herunter. Dann führt man folgenden Befehl aus:

VBoxManage modifyvm "Android" --natpf1 adb,tcp,*,5555,*,5555

Wobei „Android“ der Name der virtuellen Maschine ist.

Danach kann man auf seinem Hostsystem adb nutzen, um sich zu verbinden:

adb connect localhost

Fazit

Meiner Meinung nach ist das eine coole Sache, um zum Beispiel Apps auf böses Verhalten zu untersuchen.

~ Sebastian

ich habe vor einigen Tagen erfolgreich meine erste Android App in den alternativen Appstore „F-Droid“ hochgeladen. F-Droid ist ein Appstore, in dem freie Software (FOSS) zur Verfügung gestellt wird.

Personen, die ihre selbstentwickelte FOSS App in den F-Droid-Store hochladen möchten, können sich hier eine Schritt-für-Schritt Anleitung anschauen.

Bevor man die folgenden Schritte befolgt, sollte man sich noch die zwei Artikel zum Einstellen von Apps durchlesen:

• Inclusion Policy
• Inclusion How-To

1. Anmeldung auf Gitlab.com

Das F-Droid Repository, welches die Informationen zu allen Apps enthält, wird auf GitLab.com verwaltet. Das bedeutet, dass ihr euch bei diesem kostenlosen Dienst anmelden müsst.

2. Repository forken

Das Repository „F-Droiddata“ muss geforkt werden. Nach dem Login auf GitLab.com und dem öffnen des Links, solltet ihr auf der rechten Seite im Menu einen Button „Fork“ finden.

Es kann einige Sekunden dauern bis das Repository in eurem Account auftaucht.

3. Repository clonen und konfigurieren

Für die nächsten Schritte müsst ihr das Program „git“ installiert haben. Erstellt ein neues Verzeichnis, in dem ihr eure Apps verwalten möchtet. Zum Beispiel:

mkdir ~/Coding/Android/

Dann klont ihr euer geforktes Repository dorthin.

cd ~/Coding/Android
git clone git@gitlab.com:USERNAME/fdroiddata.git

Wenn der Prozess abgeschlossen ist, wechselt ihr in das Verzeichnis hinein und erstellt einen weiteren Remote-Eintrag, welcher auf das originelle Repository zeigt.

cd ~/fdroiddata
git remote add upstream https://gitlab.com/fdroid/fdroiddata.git

Möchte man später Updates vom originellen (Upstream) Repository in euer eigenes übernehmen, also sein Repository auf den neusten Stand bringen, so genügt der folgende Befehl:

git pull --rebase upstream master

Damit ist die grundlegende Konfiguration des Repositories fertig.

4. App-Daten eintragen

Für jede im F-Droid Store erhältliche App gibt es eine Datei package.id.txt im Ordner „metadata„.

Der erste Schritt ist demnach eine Datei mit dem Namen „package.id“ im Ordner „metadata“ anzulegen. Dabei steht „package.id“ für den Namen des Packages, in dem die App lebt. Ein Beispiel wäre: „com.google.android.diskusage.txt“

Nun gilt es die Datei mit Leben zu füllen. Glücklicherweise gibt es dafür eine Templatedatei „template“, welche man für eine grundlegende Einführung übernehmen kann.

Die Beschreibung meiner App sieht ungefähr so aus:

Categories:Office,Internet
License:MIT
Web Site:http://DOMAIN.TLD
Source Code:https://github.com/USER/PROJECT
Issue Tracker:https://github.com/USER/PROJECT/issues
Bitcoin: BTCADRESSE

Auto Name:APPNAME
Summary:ZUSAMMENFASSUNG
Description:
BESCHREIBUNG
.

Repo Type:git
Repo:https://github.com/USER/PROJECT.git

Build:1.0,1
 commit=v1.0
 target=android-21

Auto Update Mode:Version v%v
Update Check Mode:Tags .*[0-9]$
Current Version:1.0
Current Version Code:1

Wichtig ist, dass die Werte der Optionen direkt hinter dem Doppelpunkt, ohne Leerzeichen dazwischen, stehen.

Die initiale Build-Version muss angegeben werden. Dabei kann auf Tags zurückgegriffen werden, was die automatischen Updates auch vereinfacht.

Der Update-Mechanismus ist in diesem Beispiel so gestaltet, dass der Updater von F-Droid alle Tags, welche „vx.y“ matchen, auscheckt und in den Commits die AndroidManifest.xml ausliest. Die neuste Version ist dann die, mit dem höhsten „versionCode“. Ihr dürft also nicht vergessen bei jedem Update die „versionName“ „versionCode“ Parameter in der AndroidManifest.xml anzupassen.

Für mehr Informationen kann man sich im Handbuch unter http://f-droid.org/manual umschauen.

5. Build lokal testen

Bevor wir unsere App in den F-Droid-Store zum Review geben, sollten wir schauen, ob sich diese mit den Fdroid-Tools lokal bauen lässt.

Dazu müsst ihr euch die Fdroidserver-Tools installieren. Die Schritte in der Readme-Datei:

git clone https://gitlab.com/fdroid/fdroidserver.git 
cd fdroidserver 
virtualenv env/ 
. env/bin/activate 
pip install -e . 
python2 setup.py install

Alternativ gibt es im AUR das Paket „fdroidserver-git„.

Um den Build-Prozess auszuführen benötigen wir ein lokales F-Droid Repository. Dazu erstellt man sich einen weiteren Ordner:

mkdir ~/Coding/Android/fdroid-build

Nachdem man in den Ordner gewechselt ist, führt man „fdroid init“ aus.

cd ~/Coding/Android/fdroid-build
fdroid init

Dabei kann es passieren, dass folgende Meldung auftritt:

No Android SDK found!
You can use ANDROID_HOME to set the path to your SDK, i.e.:
 export ANDROID_HOME=/opt/android-sdk
Enter the path to the Android SDK (/opt/android-sdk) here:

Ich hab fdroid beendet und danach die Umgebungsvariable entsprechend gesetzt (Fish-Syntax):

set -x ANDROID_HOME "/home/gehaxelt/Coding/Android/Sdk"

Führt man den Initialisierungsprozess erneut aus, so sollte folgende Erfolgsmeldung ausgegeben werden:

Built repo based in "/tmp/foo"
with this config:
 Android SDK: /home/gehaxelt/Coding/Android/Sdk
 Android SDK Build Tools: /home/gehaxelt/Coding/Android/Sdk/build-tools/21.1.2
 Android NDK r10d (optional): $ANDROID_NDK
 Keystore for signing key: /home/gehaxelt/.local/share/fdroidserver/keystore.jks

Es fehlen jetzt immer noch einige wichtige Ordner, welche wir mit einem Aufruf erstellen lassen können:

fdroid build --all
Creating log directory
Creating temporary directory
Creating output directory
Creating build directory
No apps to process.

Im nächsten Schritt bietet es sich an einen Symlink unserer „package.id.txt“ aus dem „fdroiddata/metadata/“ in den „fdroid-build/metadata/“ zu erstellen:

ln -s ~/Coding/Android/fdroiddata/metadata/package.id.txt ~/Coding/Android/fdroid-build/metadata/package.id.txt

Nun können wir den Build-Prozess starten:

cd ~/Coding/Android/fdroid-build/
fdroid build -v -t -l --no-tarball package.id

Läuft der Build-Prozess erfolgreich durch,so sollte man noch den Update-Prozess überprüfen:

fdroid checkupdates package.id

Wenn alles erfolgreich verläuft, kann man sich freuen und einen Merge Request stellen. Andernfalls sollte man solange die „package.id.txt“ anpassen, bis es passt.

6. App veröffentlichen

Kommen wir nun zum letzten Schritt. Zunächst müssen wir unsere Änderungen in einem Commit festhalten:

git add metadata/package.id.txt
git commit -m 'Adding package.id'
git push

Danach loggt man sich wieder auf der GitLab.com Webseite ein und müsste unter seinen Aktivitäten den Commit wiederfinden.

Normalerweise steht direkt daneben eine Aufforderung zum Eröffnen eines Merge Requests. Ist das nicht der Fall, so muss man den Buttons auf der rechten Seite selbst betätigen und die Branches korrekt setzen.

In den Merge Request sollte man noch einen kleinen Grund angeben, weshalb die App in den Store aufgenommen werden sollte. Es bietet sich ausßerdem an die Lizenz + ggf. benutzte Bibliotheken/Abhängigkeiten angeben.

Zuletzt muss man noch ein wenig Geduld mitbringen, bis eine Person des F-Droid-Teams sich den Merge Reqeuest anschaut und die App „durchwinkt“ bzw. konstruktives Feedback abgibt.

~ Sebastian

Bei den beiden Tasturen handelt es sich, wie man es dem Titel entnehmen kann, um

[appbox googleplay com.nuance.swype.dtc]

[appbox googleplay com.touchtype.swiftkey]

Die Vorgeschichte

Ich hatte damals an der Beta von Swype teilgenommen und fand die Tastatur einfach nur genial. Vor einigen Wochen/Monaten wurde dann die Beta beendet und die App als eigenständige, kostenpflichtige Tastatur veröffentlicht.

Da ich von dieser Tastatur überzeugt war, besorgte ich mir daraufhin – wie eingangs schon beschrieben – ein wenig Guthaben für den Playstore. Eigentlich mit dem Ziel Swype zu kaufen.

Der Swiftkey – Fail

Während bzw. nach der Beta von Swype las man immer wieder auf Twitter von einer ähnlichen Tastatur namens „Swiftkey“. Aus den aufgenommenen Wortfetzen leitete ich mir ab, dass diese Tastatur besser als die Swype sein sollte/muss. Das war der Grund (ohne nachzudenken -.-) die Swiftkey-Tastatur zu kaufen. Nach einigen Tagen musste ich aber feststellen, dass diese gar nicht so toll ist, wie ich es erwartet hätte. Man musste relativ genau wischen, damit ein Wort korrekt erkannt wurde. Mit dieser Tastatur zu schreiben machte mir gar kein Spaß :(

Der Sieger: Swype

Nachdem ich mich ein wenig geärgert habe, dass ich für den Reinfall 3,7€ bezahlt habe, und nun nochmal soviel für Swype bezahlen sollte, landete die zweite Tastatur direkt im Warenkorb. Nach der Installation und Einrichtung von Swype konnte ich beruhigt aufatmen, denn diese App bot mir das, was ich aus der Beta-Phase gewohnt war. Sie funktionierte einwandfrei und es macht einfach Spaß damit zu schreiben. Mittlerweile unterstützt Swype auch mehrere Sprachen gleichzeitig.

Fazit

Dies ist nur meine persönliche Meinung, und beide Hersteller bieten auch jeweils eine Demo-Version zum Ausprobieren an. Falls Euch die Entscheidung aber schwer fällt, dann kann ich euch Swype einfach nur empfehlen :)

~ Sebastian

Voraussetzungen

Es gibt nicht viele Voraussetzungen, die man erfüllen muss. Genauer gesagt, sind es genau zwei:

• Ein gerootetes Handy, auf dem man root-Rechte hat
• Die App „Linux Deploy“
  [appbox googleplay ru.meefik.linuxdeploy ]

Erfüllt man die erste Voraussetzung, und hat die genannte App installiert, kann des Linuxs Einrichtung beginnen.

Die Installation

Nachdem die App gestartet wurde, geht man auf das Download-Symbol unten rechts. Daraufhin öffnet sich der Konfigurationsdialog. Ich habe der Einfachheit halber ein Debian gewählt, und das .img-File auf 2GB begrenzt. Die Dateigröße sollte man überlegt wählen, da der Versuch, diese später zu vergrößern scheiterte. Den Benutzernamen habe ich auf „linux“ gesetzt.

Konfiguration – Teil 1

Ansonsten empfehle ich, nur den SSH-Server als Service installieren zu lassen. VNC bzw. die graphische Oberfläche würden nur viel Speicherplatz und Ressourcen verbrauchen.

Konfiguration – Teil 2

Sind diese Einstellungen nach dem eigenen Belieben getroffen, kann man ganz oben auf „Installieren“ drücken. Man benötigt eine möglichst stabile WLAN-Verbindung, und etwas Zeit, bis das System eingerichtet ist.

Start & Einrichtung

Um das Linux-System zu starten, drückt man einfach einmal auf den „start“-Button. Man sollte eine ähnliche Ausgabe erhalten:

Linux Deploy – Startvorgang

Im nächsten Schritt bietet es sich an, das Handy per USB-Kabel an den PC anzuschließen, und sich per adb shell darauf zu verbinden:

adb shell

Wir sind nun in der ADB Shell und können dann auf den SSH-Server verbinden:

ssh linux@127.0.0.1

Den Umweg über ADB muss man nicht unbedingt machen, da man die Linux-VM auch von „außen“ erreichen kann. Die jeweilige IP steht in der Linux Deploy App im oberen Teil des Bildschirms.

Das Passwort ist standardmäßig auf „changeme“ gesetzt. Dieser Anweisung wollen wir folge leisten, und ändern als erstes das Passwort.

passwd linux

Ihr werdet aufgefordert das aktuelle Passwort, sowie zweimal das neue Passwort einzugeben. Ich empfehle hier ausdrücklich ein starkes Passwort zu wählen, da der SSH-Services von außen erreichbar ist.

Bevor man effektive mit dem System arbeitet, kann es von Vorteil sein, sich die aktuellsten Paketlisten herunterzuladen:

sudo apt-get update

Die neusten Pakete sollten bereits vorhanden sein, sodass ein „upgrade“ keine Auswirkungen zeigen sollte.

SSH Verbindung aufs Handy

Es steht einem nun ein ganz normales Debian-System zur Verfügung.

Fazit

Danach sollte einem nichts mehr im Wege stehen, das Linuxsystem für seine Zwecke zu nutzen. Ich habe zum Beispiel IoQuake3 jetzt auf dem Handy eingerichtet :)

~Sebastian

Voraussetzungen

Während diesem Blogeintrag werden einige weitere Tools benötigt, welche ich zum entsprechenden Zeitpunkt einführe. Trotzdem sollte man die folgenden drei Voraussetzungen erfüllen, damit sich das Weiterlesen lohnt:

• Burp Proxy – http://portswigger.net/burp/proxy.html
• Exportierte CA Certicifate (PortSwigger) – http://portswigger.net/burp/help/proxy_options_installingCAcert.html
• Android SDK – http://developer.android.com/sdk/index.html

Im weiteren Verlauf werde ich davon ausgehen, dass diese Tools heruntergeladen, installiert und eingerichtet wurden. Dies sollte relativ intuitiv sein, und im Zweifel findet sich Hilfe im Internet.

Emulator einrichten

Wir müssen zunächst einen neuen Android-Emulator erstellen. Die entsprechende GUI rufen wir mit diesem Befehl auf:

android avd

Dort erstellen wir einen neuen Emulator. Spendiert diesem eine SD-Karte und aktiviert die „externe“ Tastatur. Der erstelle Simulator wird im Folgenden den Namen „BurpTesting“ tragen.

Sollte die Tastatur später nicht erkannt werden, so müsst ihr in einer Konfigurationsdatei die Option „hw.keyboard“ von „no“ auf „yes setzen.

~/.android/avd/BurpTesting.avd/config.ini
hw.keyboard=yes

Emulator mit Proxy starten

Zunächst starten wir die Burp Suite. Ich habe den Proxy auf 127.0.0.1:8888 konfiguriert.

Wenn Burp läuft, können wir den Emulator starten. Dabei hängen wir dem Programmaufruf noch einige Parameter an:

• HTTP-Proxy ist localhost:8888
• HTTP Debug auf der Konsole
• Interne Speicher ist 500MB groß
• Kein Sound
• GPU Rendering aktiv
• Keine Bootanimation

Der gesamte Befehl sieht dann so aus:

emulator -avd BurpTesting -http-proxy localhost:8888 -debug-proxy -partition-size 1000 -no-audio -no-boot-anim -gpu on

Der Emulator sollte nun langsam hochfahren. Es kann einige Minuten dauern, bis man beim Homescreen ankommt.

Portswigger CA Certificate installieren

Damit wir später ohne Probleme HTTPS Verbindungen untersuchen können, müssen wir das von Burp mitgelieferte CA Certificate im Emulator hinzufügen. Dazu schieben wir das Zertifikat zunächst auf die SD Karte. Im nächsten Schritt teilen wir „adb“ mit, welchen Emulator wir als nächstes ansprechen möchten:

adb devices

Dort sollte nun ein Emulator erscheinen. Als nächstes kopieren wir das angesprochene Zertifikat:

adb push PortSwiggerCA /sdcard/PortSwiggerCA.crt

Wichtig ist, dass auf der SD Karte das Zertifikat auf „.crt“ endet, ansonsten erkennt Android dieses nicht.

Als nächstes müssen wir einen Screen lock im Emulator festlegen, damit wir das Zertifikat installieren können. Geht im Emulator dazu auf „HOME“->“Settings“->“Security“->“Screen lock“. Ich habe die PIN-Methode gewählt, da sich dieser relativ einfach über die Tastatur eingeben lässt.

Ist der Screen lock gesetzt, könnt ihr auf der gleichen Einstellungsseite unter „Credential Storage“->“Install from SD card“ auswählen. Der Emulator sollte nun das PortSwigger Zertifikat erkennen und auf Euer abnicken installieren.

Zwischenfazit

Bis hierhin habt ihr den Emulator soweit eingerichtet, dass ihr dessen Traffic (auch HTTPS) im Burp sehen und manipulieren könnt.

Das macht natürlich nur Spaß, wenn man sich Apps zum Testen installieren kann.

Playstore auf dem Emulator einrichten

Wir möchten die zusätzlichen Apps über den Google Play Store beziehen. Dazu müssen wir diesen auf dem Emulator installieren.

Ich habe die für den Google Play Store benötigten APKs in einem Archiv zusammengestellt, und stelle Euch dieses hier zur Verfügung. Mittels der beigefügten „install.sh“ werden die Dateien über adb push auf den Emulator kopiert.

Download: http://uploads.blogpasis.net/Playstore.tgz

Nachdem ihr die Dateien nach den Anweisungen der „install.sh“ oder direkt per Aufruf der Datei auf den Emulator kopiert habt, solltet Ihr den Google Play Store in der Appübersicht sehen. Danach braucht Ihr nur noch darin anzumelden.

Den Google Play Store müsst Ihr bei jedem Start des Emulators erneut installieren, da ich keine Möglichkeit gefunden habe, die Änderungen beizubehalten.

Fazit

Ihr habt nun die Möglichkeit Euch Apps aus dem Google Play Store herunterzuladen, und dessen Traffic zu untersuchen. Dies kann bei sicherheitskritischen Apps, sowie auch bei kleinen Spielen interessant sein. Zudem sollte es möglich werden, genau zu überprüfen, welche Daten eine App an Ihren Server überträgt.

~ Sebastian

Um das System dahinter zu verdeutlichen, müssen wir uns dazu keine extra App vorstellen, denn die App-Entwicklung für Android basiert auf Java. In dem folgenden Beispiel nutzen wir eine Calculator-Klasse, welche ein paar einfache Rechenoperationen durchführen soll. Das Ergebnis wollen wir dann per onFinished-Event ausgeben lassen.

Die main-Klasse

Die von mir genutzte Main-Klasse würde in einer Android-App die entsprechende Activity darstellen, welche von dem onFinished-Event Gebrauch machen möchte.

import tools.Calculator;
import tools.EventListener;

public class main {

    public static void main(String[] args) {

        Calculator calc = new Calculator();

        calc.setOnFinishedEventListener(new EventListener() {

            @Override
            public void onFinished(Object result) {

                System.out.println("Result: "+String.valueOf((int)result));

            }

        });

        calc.calculate(5,5,Calculator.PLUS);

    }

}

In dieser Activity bzw. Klasse erzeugen wir ein Objekt der Calculator Klasse. Diesem Objekt weisen wir über calc.setOnFinishedEventListener(…) unser EventListener-Objekt, in welchem wir die onFinished Methode überschreiben. In dieser Methode geben wir das Ergebnis einfach als String aus.

Wichtig ist, dass wir den EventListener vor der Berechnung selbst setzen. Andernfalls würde es zu keinem Event kommen, da wir in der Calculator-Klasse dieses nach der Berechnung abfeuern.

EventListener.java

Um einen EventListener umzusetzen, müssen wir ein entsprechendes Interface erstellen. Dieses Inferface enthält die Methode onFinished, welche wir weiter oben überschrieben haben.

package tools;

public interface EventListener {

    void onFinished(Object result);

}

Calculator.java

In der Calculator.java, in welcher später das Event abgefeuert werden soll, muss eine Funktion implementiert werden, welche den EventListener setzt. Zunächst weist man der Klasse eine neue private Variable, welche den EventListener enhält, zu. Wir brauchen nun nur noch eine Setter-Methode, um den EventListener zu setzen:

package tools;

public class Calculator {

    public static final int PLUS = 0;
    public static final int MINUS = 1;
    public static final int DIV = 2;
    public static final int MULT = 3;

    private int _result;
    private EventListener _eListener = null;

    public void calculate(int x, int y, int op) {

        switch(op) {
            case PLUS: {
                _result = x + y;               
            }
            case MINUS: {
                _result = x - y;
            }
            case DIV: {
                _result = x / y;
            }
            case MULT: {
                _result = x * y;
            }
            default: {
                _result =  x + y;
            }

        }

        if(_eListener != null)
            _eListener.onFinished(_result);

    }

    public void setOnFinishedEventListener(EventListener listener) {
        _eListener = listener;
    }

}

Wie man erkennen kann, ruft man zum abfeuern des Events einfach an der gewünschten Stelle die onFinished-Funktion auf. Dies macht allerdings nur Sinn, falls diese nicht null ist.

Fazit

Man kann sehr einfach eigene EventListener umsetzen, um bestimmte Funktionalitäten – meistens in parallelem bzw. asynchronen Code – zu programmieren.

~ Sebastian