Daten zu Daten, Code zu Code

Es war einmal ein Programmierer wie jeder andere. Sprich: Kurz vor Feierabend bekam er die Aufgabe, mal eben schnellTM einem neuen Kunden Zugriff auf eine bestimmte Ressource zu gewähren.

Was glauben Sie, warum er sein für den Abend geplantes Date mit Pizza&Kuscheln absagen musste?

Klarer Fall: Weil er oder einer seiner Kollegen bzw. Vorgänger das Bibel-Zitat aus der Überschrift nicht kannte.

Daten als Code

Wie immer sagt ein Beispiel mehr als 1000 Worte, und ich will ja nicht Ihre Zeit verschwenden. Schauen Sie sich daher das folgende Codebildchen an.

switch(userrole) {
case "DRG_BES":
case "DRG_ARG":
case "DRG_EFT":
    mgrNr = 332;
    break;
case "DRG_ALB":
    mgrNr = 451;
    break;
case "DRG_EDV":
    mgrNr = 322;
    break;
case "DRG_BFF":
    mgrNr = 537;
    break;
case "DRG_DDA":
    mgrNr = 336;
    break;
...

Wohlgemerkt handelt es sich hier um einen (leicht verfremdeten) originalen Ausschnitt aus einer umfangreichen Software-Lösung in Java. Die case-Konstruktion im analysierten Gesamtcode war noch länger, und ganz ähnliche Monster gab es an weiteren Stellen.

In einem anderen Projekt gab es auch mal eine ganz ähnliche Konstruktion zur Behandlung von speziellen Userrechten, daher der eingangs erwähnte Anwendungsfall unseres armen Programmierers. Denn der muss, um seine Aufgabe zu lösen, nun den Code erweitern, und zwar möglicherweise an mehreren Stellen. Dann muss er die Software testen, bauen und deployen oder, sollte es sich nicht um eine Serveranwendung handeln, ein Setup-Paket an einen Kunden schicken.

Wie gesagt: das war’s mit dem Date. Denn getreu Murphy’s Law geht dabei irgendwas schief … na ja, ich denke, Sie kennen das, haben es selbst erlebt oder erleiden müssen und fühlen mit unserem armen Programmierer, der sich an der Schwelle zur grausigsten aller Schrottsoftwareapokalypsen wähnt.

Daten sind Daten

Der Knackpunkt ist natürlich: Wenn Sie Daten als Code schreiben, müssen Sie die Anwendung kompilieren, bauen und ausrollen, um etwas zu ändern. Befinden sich Daten da, wo Daten hingehören (in Datenbanken oder Ressourcen- bzw. Konfigurationsdateien), und ist der Code generisch, genügt es, die Daten an der richtigen Stelle zu ändern, was in 99,99% der Fälle deutlich weniger Aufwand ist.

Der zugehörige Ersatz-Code für obiges Konstrukt könnte beispielsweise so aussehen:

mgrNr = userSettings.getMgrNrForUserrole(userrole);

Dabei ist es dem Code an dieser Stelle egal, ob userSettings ein simples POJO ist, in das die richtigen Daten irgendwann vorher geladen wurden, oder ob die Klasse den gewünschten Wert in diesem Moment aus einer Datei oder Datenbank liest. Im ersteren Fall muss die Anwendung möglicherweise neu gestartet werden, oder anderweitig signalisiert bekommen, dass sich Settings geändert haben und neu geladen werden müssen. Hat der Software-Architekt damit gerechnet, dass sich solche Daten außerhalb ändern können, hat er möglicherweise auch einen automatischen Refresh eingebaut. Zu beachten ist nämlich, dass sehr häufige Zugriffe auf meist statische Settings-Daten durchaus die Performance beeinträchtigen können, wenn jedesmal ein Datenbankzugriff oder z.B. eine XML-Deserialisierung notwendig ist. Ein Caching von Settings für ein paar Minuten ist also oft eine gute Idee.

Sie sehen natürlich auf den ersten Blick, dass der neue Code nicht nur ein Vielfaches kürzer ist als das alte Switch-Konstrukt. Er ist außerdem sofort zu verstehen und damit sehr gut wartbar. Auch die Fehleranfälligkeit ist geringer, weil eine versehentliche Veränderung in einem String-Literal oder einer der “magic numbers” im Eingangsbeispiel hier nicht passieren kann (der Compiler würde es wohlgemerkt nicht merken).

Daten sind Daten, aber wie?

Wenn Sie vor der Entscheidung stehen, wie und wo Sie Konfigurationsdaten ablegen, gibt es weder eine Patentlösung noch allgemeingültige Empfehlungen.

So möchten Sie User/Rollen-Konfigurationen einer auf Kunden-PCs laufenden Anwendung sicher verschlüsseln oder zumindest digital signieren, damit sich niemand auf einfache Weise zusätzliche Rechte verschaffen kann. Das ist natürlich mit Standard-Bibliotheken ohne weiteres möglich und ändert nichts am Grundprinzip der sauberen Trennung von Daten und Code.

Auf Dateiebene kommen ini- oder properties-Dateien in Frage, für komplexere Daten (wie Maps/Dictionaries wie im obigen Beispiel) XML- oder Json-Format. Beachten Sie, dass es für so ziemlich jede Programmiersprache, die etwas auf sich hält, Bibliotheken gibt, die Ihnen solche Dateien in Objekte deserialisieren (z.B. GSON oder Jackson für Java). So können Sie eine bestimmte Datenstruktur erzwingen, brauchen keine tippfehleranfälligen Stringliterale für den Zugriff, und strukturell falsche Daten führen zu Ausnahmefehlern, die (ordentliche Fehlerbehandlung vorausgesetzt) sofort sichtbar werden.

Auf Nummer sicher gehen Sie mit einer Datenbank, in der das relationale Schema die Datenstruktur fest vorgibt. Das muss natürlich kein ausgewachsener SQL-Server sein – auch dateibasierte Datenbanken wie Apache Derby oder SQLite erfüllen ihren Zweck. Das obige Beispiel würde eine Tabelle mit zwei Spalten (userrole und mgrNr) erfordern, wobei die userrole gleichzeitig der unique primary key wäre und die get-Funktion letztlich eine SQL-Query ausführt:

 SELECT mgrNr FROM settings WHERE userrole=:?

Diese oder jene Daten

Daten in Ressource-Dateien abzulegen (auch dateibasierte Datenbanken sind letztlich welche), eröffnet Ihnen mit modernen Build-Systemen wie Maven weitere Möglichkeiten. So können Sie mit Maven-Profiles das Buildsystem anweisen, unterschiedliche Ressourcen-Verzeichnisse zu verwenden. Auf diese Weise können Sie Testversionen getrennt von Produktivversionen verwalten oder auch unterschiedliche Ausprägungen eines Produkts bauen. In Mavens pom.xml schreiben Sie einfach:

<profiles>
    <profile><id>dev</id></profile>
    <profile><id>live</id></profile>
    ...
</profiles>

Sie übergeben dem mvn-Kommando mit dem Parameter -P den Namen des gewünschten Profils. Dann verwendet Maven zusätzlich zum Standard-Verzeichnis für Ressourcen (resources) ein Verzeichnis namens resources-[profile]. Legen Sie also einfach die jeweiligen Dateiversionen in unterschiedliche resources-xxx-Verzeichnisse und bauen Sie die Anwendung mit dem passenden -P-Parameter.

Wenn Sie das Springframework verwenden, können Sie mit passenden Annotations dafür sorgen, dass Konfigurationsparameter direkt zu Java-Beans verarbeitet werden, die per Autowire im Inversion-of-Control-Container zur Verfügung stehen. Aber das ist ein Thema für einen anderen Artikel.

Mögen Ihre Daten immer Daten sein, auf dass keines Ihrer Dates ausfallen muss!

Coden, aber effizient!

Wir leben im digitalen Zeitalter (na gut, die meisten von uns), und langsam aber sicher wird vielen Entscheidern klar, dass die AWS-Cloud (oder ihre Verwandten) nicht nur total praktisch ist, sondern auch eine ganze Menge Energie verbraucht. Schätzungen sprechen von bis zu 20% des Energieverbrauchs der ganzen Welt. Wohlgemerkt sind Anwendungen in der Cloud immer noch sparsamer als eigene Rechenzentren mit Servern aus Blech, die 24 Stunden an der Steckdose nuckeln, aber beispielsweise nur tagsüber benötigt werden. Cloud-Instanzen sind üblicherweise “shared” und verbrauchen nur dann Energie, wenn benötigt. Trotzdem bedeuten mehr Cloud-Instanzen natürlich auch mehr Energieverbrauch (und CO2-Ausstoß, sofern das Rechenzentrum keinen grünen Stromanschluss besitzt).

Tatsächlich können wir die Frage nach dem Energieverbrauch auch Codern und Software-Architekten stellen: Benötigt euer Software-System wirklich 10 Instanzen und 3 Datenbanken? Muss für eine eher simple Anwendung 1 GB RAM reserviert werden und die Kiste mit dem fettesten Prozessor oder darf es ein bisschen weniger sein? Sollte der Energieverbrauch einer Plattform vielleicht sogar zu den Entscheidungskriterien gehören?

Der Vergleich

Für die 2. Auflage meines Buchs “Besser coden” habe ich ein Kapitel über effizienten Code geschrieben – und ein paar Messungen durchgeführt. Dazu habe ich eine relativ einfache Webanwendung in mehreren Sprachen geschrieben und Aspekte wie Performance, Ressourcenverbrauch und Anspruch an Entwickler verglichen. Letzteres ist nicht zu unterschätzen: Spart eine Technologie Speicher, aber Sie finden keinen Entwickler, der sie beherrscht, bleibt ihr tolles Softwaresystem graue Theorie.

Es traten an:

  • Java 13 und Spring Boot, das beliebte Framework für Webservices
  • PHP 7.4, eine bewährte, einfache Skriptsprache mit Cache APCu
  • Rust 1.52 und Actix Web, eine ziemlich neue Sprache samt passendem Webservice-Framework
  • sowie quasi als Online-Bonus (nicht im Buch) Go.

Der Webservice besitzt nur einen einzigen Endpoint, der dafür gedacht ist, ein Wort gegen eine hinterlegte Liste zu prüfen. Eine solche Funktion ist beispielsweise in einem Scrabble-Spiel nötig: Ist das gelegte Wort erlaubt oder nicht? Das Ergebnis wird dabei als JSON-Antwort formuliert.

Die Liste ist absichtlich nicht in einem ausgewachsenen Datenbanksystem hinterlegt, denn ich möchte nicht die Effizienz unterschiedlicher RDBMS bewerten, sondern die von Software-Plattformen. Daher lädt die zu schreibende Anwendung die Wortliste beim Start aus Textdateien und hält sie dann im RAM. Im Test enthielt diese Liste knapp 180.000 Einträge. Im Fall von PHP erfordert eine solche Vorgehensweise zwingend den Einsatz eines Caches (hier verwendet: APCu), um die Dateien nicht bei jedem Aufruf des Skripts erneut laden zu müssen.

Die Rechenzeit habe ich mit dem Apache Benchmark ab gemessen, einmal einen Einzelrequest und einmal 10.000 auf einmal in sechs parallelen Threads, um die Leistung im Parallel Processing zu bestimmen.

Den Code finden Sie in Grundzügen in meinem Buch (bis auf die Go-Version). Hier fasse ich Ihnen nur die Ergebnisse zusammen:

Java/Spring BootPHP/APCuRust/ActixGo
RAM-Verbrauch50 MB200 MB0,9 MB24 MB
Anwendungsgröße19 MB (JAR)372 Bytes (Skript)8,4 MB (binär)7,1 MB (binär)
Zeit 1 Aufruf1,8 ms0,9 ms0,4 ms0,5 ms
Zeit 10.000 Aufrufe1,1 s0,6 s0,5 s0,5 s
Startup-Dauer2,5 snicht messbar53 ms75 ms
Buildtime7,4 sentfällt69 s1 s
Coding-Anspruchleichtsehr leichtschwierigmittel

Sie sehen, dass das rein binäre Rust-Programm zur Laufzeit am schnellsten und genügsamsten ist – aber finden Sie mal einen Rust-Entwickler auf dem Jobmarkt oder lernen Sie die Sprache “mal eben”! Ich hab letzteres versucht und brauchte mehrere Packungen Schokokekse, um die spezielle Speicherverwaltung zu kapieren. Die lange Buildtime ist dabei dem anspruchsvollen Compiler- und Linker-Vorgang geschuldet.

Abgesehen vom RAM-Verbrauch ist PHP unter dem Strich wohl die effizienteste Lösung. Aber viele Entwickler scheuen sich davor, größere Projekte in PHP anzulegen – die fehlende starke Typisierung und die immer über uns Entwicklern schwebende Versuchung, spaghettimäßig PHP- und HTML-Code zu mixen, sowie ein paar Fallen wie vergessenes $this->, sind klare Minuspunkte. Dafür ist die Turnaround-Zeit Null: Skript nur speichern, schon ist es bereit zum Aufruf per HTTP.

Java ist nicht ohne Grund sehr beliebt. Aber die Java-Runtime, so optimiert sie mittlerweile auch ist, geht alles andere als sparsam mit Ressourcen um und ist merklich langsamer als die Binärcode-Konkurrenz (auch PHP verwendet dank Zend-Engine letztlich Binärcode). Ein Maven-Buildprozess lädt gefühlt mehrmals täglich das halbe Internet runter. Dafür ist der Code (speziell mit Spring Boot) aufgeräumt und vergleichsweise leicht zu debuggen. Große Projekte mit komplexer Geschäftslogik sind in Java wohl vergleichsweise am lesbarsten abzubilden.

Fazit

Sie sehen: Es gibt keine Lösung, die gleichzeitig einfach und technisch effizient ist. Sie müssen immer abwägen: Lohnt es sich, in eine hocheffiziente, moderne Technik wie Rust oder Go zu investieren? Oder setzen Sie auf eine bewährte und
einfache Technik wie Java und nehmen in Kauf, dass Sie mehr
Server benötigen (und Energie verbrauchen), wenn mehr Rechenpower erforderlich ist? Gerade bei neuen Projekten ist es sicher eine gute Idee, über diese Fragen zu diskutieren. Denn später können Sie die Plattform nicht mehr einfach ändern.

So bleiben vermutlich noch auf Jahre oder Jahrzehnte Java-Webservices
und PHP-Skripte state of the art – obwohl mit Rust oder Go, C++20, D …
technisch hochmoderne und extrem effiziente Konkurrenzprodukte be-
reitstehen.

Mein Dank für die Mitarbeit geht an Marcus Schlechter.

Müssen Betriebssysteme schlauer werden, um uns vor bösen Menschen zu schützen?

Angenommen, Sie wären ein Betriebssystem (oder ein Teil davon, vielleicht das Dateisystem). Sie wären dafür zuständig, auf Befehle wie fopen (Datei öffnen), fwrite (in eine Datei schreiben) oder fdelete (eine Datei löschen) zu reagieren.

Nun haben Sie gerade die halbe Nacht bloß immer Anweisungen bekommen, immer dieselben Infos (“checking for mail … no new mail.”) in in irgendeine Log-Datei zu schreiben. Sie schlafen schon fast ein vor Langeweile, da kommen mit einem Mal zig Anweisungen in kurzer Folge hintereinander: Jemand lässt sich erst den ganzen Verzeichnisbaum ermitteln, um dann jede Datei darin einmal komplett zu lesen und durch scheinbar zufällige Bytes zu ersetzen.

Wenn Sie ein halbwegs wacher und informierter Mensch wären, würden sie diesem Treiben Einhalt gebieten und sagen: “Mooooment! Das sieht mir nicht aus wie eine übliche, absichtliche Aktion meines Nutzers vor dem Bildschirm (der schläft normalerweise um diese Zeit), sondern eher … wie eine Ransomware-Attacke!”

So geschehen kürzlich bei einem Dienstleister einer schwedischen Supermarkt-Kette, die daraufhin ihre Filialen schließen musste. Was das kostet!

Natürlich sagen Sie sich jetzt: Wer hat denn da wieder eine Sicherheitslücke verbrochen? Aber, wie gesagt, wenn Sie schlau genug sind: Sie verweigern den Dienst. Sicherheitshalber. Sie verlangen die erneute Eingabe des User-Passworts (oder eine Zwei-Faktor-Authentifizierung).

Was ich hier vor mich hin fantasiere, ist kein neues Konzept: Ein Forschungsprojekt namens ShieldFS gibt es schon seit Jahren, scheint aber eingeschlafen zu sein. Dabei wäre es wichtiger denn je, dergleichen auf die Tagesordnung zu setzen, denn die Ransomware-Attacken werden immer schlimmer und ganz sicher nicht aufhören, wenn die Täter erstmal genug Lösegeld kassiert haben, um sich eine eigene Insel zu kaufen. Wenn man kein Gegentor kriegen will, muss die Verteidigung eben besonders tief stehen – eine Fünferkette und ein guter Torwart, direkt im Dateisystem.

Natürlich kann man einwenden: Wer von Ransomware betroffen ist, ist eh selbst schuld, weil er anfällige Systeme mit ungepatchten Sicherheitslücken verwendet. Derjenige wird auch nicht so schlau sein, ein besseres Dateisystem zu verwenden. Ja, mag sein: Aber wäre ein solches Dateisystem Standard, wäre also Sicherheit wichtiger als … sagen wir Bequemlichkeit, wäre das ein Schritt in die richtige Richtung.

Wie Spaghetti ist PHP?

Wer kennt sie nicht, die Sprache von WordPress? Laut Statistiken laufen um die 30% aller Webseiten (auch diese) auf WordPress – und damit mit der 25 Jahre alten Skriptsprache PHP (freilich vermixt mit einer gehörigen Portion HTML, Javascript und CSS). Also nicht Java, nicht C# … sondern PHP. Insgesamt kommt PHP sogar auf einen Anteil von 79% aller Webseiten, deren verwendete Plattform bekannt ist, behauptet W3Techs.

PHP – eine Sprache, die Spaghetticode geradezu herbeisehnt, denn damit können sogar Anfänger innerhalb von Sekunden dynamische Webseiten schreiben, mit Datenbank-Anbindung, Formular-Sanitychecks und haufenweise Sicherheitslücken.

Nun ja, die Situation hat sich gebessert, seit URL-Parameter nicht mehr automatisch als Variablen wie $param zur Verfügung stehen – trotzdem verleitet die Natur der Sprache zur Beimischung von HTML wie hier:

foreach($angebote as $angebot) { print "<div>$angebot</div>";}

Ups, heute leider keine Angebote:

Na ja. Kann ja mal passieren.

Hinweisen wollte ich hier eigentlich nicht auf schlechte Fehlerbehandlung, sondern auf etwas anderes: HTML-Code in String-Literalen ist aus Sicht der Entwicklungsumgebung meist irgendein Text. Folglich findet darin keine Validierung statt. Ein versehentlicher, unbemerkter Tastendruck innerhalb des Strings kann die Darstellung der Webseite komplett zerschießen, ohne dass Sie, Ihre Entwicklungsumgebung oder PHP es bemerken (klar gibt es Unit-Tests für PHP, aber ich fürchte, allzu verbreitet sind die nicht). Dass man dergleichen mit einer Template-Engine umgehen kann, die HTML- und PHP-Code in getrennten Dateien verwaltet, dürfte den meisten Lesern klar sein – aber das ist natürlich viel umständlicher und nicht so schnell fertig.

Mit strukturierter (also aufwändigerer, zukunftssicherer) Programmierung ernten Sie als Früchte eine ganze Reihe Vorteile von PHP:

  • Minimaler Footprint auf dem Server (ein paar Textdateien, nicht megabyteweise Java-Libs)
  • Hohe Performance (dank Codecache und bei schlauer Programmierung, siehe dazu weiter unten)
  • Turnaround-Zeit ist 0 (Zeit zwischen Speichern einer PHP-Datei und HTTP-Aufruf gegen localhost zum Testen)
  • Und nicht zu vergessen: Hohe Verbreitung in der Community, also ist es leicht, Unterstützung zu finden.

Fairerweise seien ein paar Nachteile genannt:

  • Vergleichsweise hoher RAM-Bedarf
  • Keine strenge Typisierung
  • Objektorientierte Programmierung leicht nervig (ich vergesse dauernd das $this->, Sie auch?)
  • Verleitet zu unsauberer Programmierung durch globale Variablen, prozedurales Coden und verschachtelte includes
  • Größere Updates erforderten in der Vergangenheit größere Umbauten (z.B. MySQL-Funktionen), so dass viele Webseiten nie upgedated wurden, weil der Aufwand nicht lohnt → eine solche radikale Update-Policy führt dazu, dass viele Nutzer ihre Systeme nicht updaten und damit Sicherheitslücken bestehen bleiben

Zur oben erwähnten “schlauen Programmierung” ein kleiner Info-Drops: Im Gegensatz zu einer Java-Anwendung, die einmal hochfahren muss, ist ein PHP-Skript zunächst einmal “stateless”, es kennt also keine globalen Daten bzw. muss sich alles selbst zusammensuchen, was es braucht. “Weniger schlaue” Programmierung würde hier bedeuten, etwaige benötigte Daten beim Start des Skripts aus Dateien oder Datenbank nachzuladen. Bei jedem Start des Skripts. Das ist natürlich ineffizient. Stattdessen können Sie den In-Memory-Cache APCU verwenden, der wie ein Key-Value-Store im RAM funktioniert und daher extrem performant ist und im Gegensatz zum ebenfalls bewährten Memcached keine externe Komponente benötigt. Wir versuchen also mal im folgenden Beispiel beim Start des Skripts, einen benötigten Wert ($words) aus dem Cache zu holen. Sollte er fehlen (also beim allerersten Start), laden wir ihn aus irgendwelchen Dateien und speichern ihn im Cache:

if(apcu_exists("words")) { 
  $words=apcu_fetch("words");
} else { 
  $words = load_words_from_file("irgendwelche_woerter.txt");
  apcu_add("words",$words);
}
// es folgt der Code, der $words benötigt

Der Performancegewinn ist erheblich, wovon Sie sich leicht selbst überzeugen können, wenn Sie Test-Requests auf ein solches Beispiel loslassen. Um auch mal mehrere Requests auf einmal abzufeuern, können Sie übrigens den Apache Benchmark ab verwenden, etwa so:

ab -c 6 -n 10000 http://localhost/test.php?input=Hurra

Mit den gezeigten Parametern führt ab 10.000 Requests gegen die übergebene Adresse aus, und zwar in 6 parallelen Threads (seien Sie fair und überlassen Sie PHP/Apache auch ein paar, meine Maschine hat 12 Kerne, daher Fifty-Fifty). Das Tool gibt dann eine ausführliche Statistik über die Performancemessung aus:

Concurrency Level: 6
Time taken for tests: 0.629 seconds
Complete requests: 10000
Failed requests: 0
Non-2xx responses: 10000
Total transferred: 1850000 bytes
HTML transferred: 0 bytes
Requests per second: 15901.99 #/sec
Time per request: 0.377 ms
Time per request: 0.063 [ms] (mean, across all concurrent requests)
Transfer rate: 2872.92 [Kbytes/sec] received

Sie sehen: Ja, auch in PHP kann man strukturiert, effizient und sauber programmieren – aber PHP zwingt Sie nicht zu Disziplin, das müssen Sie schon selber tun. Empfehlenswert sind daher z.B. im Team knackige Code-Reviews und zielführende Mikroarchitektur-Debatten, um für porentief reinen Programmierstil zu sorgen.

tl;dr: PHP ist schnell und effizient, aber passen Sie auf, dass Sie keinen Spaghettisalat produzieren.

Meetup: Code-Qualität

Am 9.6. gibt’s von mir einen tollen Online-Vortrag in Zusammenarbeit mit IT Dev Café Düsseldorf. Ich zeige tolle Beispiele aus meiner Arbeit bei Codequalitätsanalysen – und diskutiere, wie es zu bestimmten Problemen typischerweise kommt. Sagte ich schon, dass es ganz toll wird?

Nehmt teil, bringt Freunde mit, kostet nix!

Hier ist der Meetup-Link!

In eigener Sache: Android-Sample-Code-Neuzugänge

Liebe Freunde von “Android-Apps entwickeln mit Java”!

Fans spaßiger App-Bastelei!

Hurra!

Ich habe mein github-Repository um einen Haufen Beispielcode erweitert. Es handelt sich dabei durchweg um Android-Apps, die ein oder mehrere Best Practices in der Android-Entwicklung mit Java zeigen. “Best Practice” heißt natürlich: Was ich für empfehlenswert halte, die Geschmäcker sind halt verschieden. Teilnehmer meiner Trainings kennen diesen Code schon, weil ich ihnen den ausführlich erklärt habe. Jetzt können Sie nochmal draufschauen – oder sich was kopieren, ist ja alles Open Source!

Mit dabei sind Samples zu Themen wie Fragments und Master-Detail-Flow, aber auch die guten alten DialogDemos, die auch das Buch erklärt. Brandneu ist eine Demo der neuen (aktuell noch in Alpha-Version erhältlichen) CameraX-API von Jetpack. Diese wird wahrscheinlich durch irgendwelche API-Änderungen ziemlich schnell obsolet; ich kann noch nicht versprechen, ob oder wann ich sie aktualisiere.

Ebenfalls bekannt aus meinem Buch ist der Kompass, der die Nutzung des Magnetometers und einen selbst gezeichneten View demonstriert. Ferner gibt es einen MiniMiniEditor, der das Speichern von Dokumenten mit dem StorageAccessFramework zeigt. Und last but not least die 9352. Wetterfrosch-App, die die schlechteste UI aller Zeiten aber dafür auch die lehrreichste Retrofit-Implementierung der letzten 23 Minuten mitbringt. Übrigens: Für nächste Woche sind 16 Grad angesagt! Hier, schauen Sie:

Diese App ist tatsächlich sinnvoll nutzbar – also, falls Sie noch keine Lieblings-Wetterfrosch-App installiert haben, nehmen Sie doch diese!

Viel Spaß mit dem Code. Beachten Sie bitte, dass bei Erscheinen einer neuen Gradle- oder Android-SDK-Tools-Version ggf. Aktualisierungen in der build.gradle vorzunehmen werden, da ich es absehbar nicht schaffe, alle Repositories aktuell zu halten.

Von Kleinkindern lernen

Wie Medien berichteten, hat am Sonntag ein Kleinkind einen Twitter-Beitrag im Account der US-Atomwaffenbehörde verfasst:

»;l;;gmlxzssaw« – Rätselhafter Code? Verborgene Botschaft? Die Auflösung kam schnell

Bemerkenswert daran ist natürlich nicht, dass man genau erkennt, welche Buchstaben mit der rechten (die bis gml) und welche mit der linken sehr kleinen (das z liegt auf amerikanischen Tastaturen links neben dem x) Hand (der Rest) verfasst wurden.

Bemerkenswert daran finde ich auch nicht, dass der für den Account zuständige Social-Media-Manager es nicht für nötig hielt, während seiner kurzen Abwesenheit (vermutlich musste er aufs Klo) seinen PC zu sperren, auf dem die Twitter-Webseite zum Verfassen eines Tweets gerade geöffnet war.

Denn dass der Mensch der Schwachpunkt jeder IT-Sicherheits-Infrastruktur ist, wissen wir ja schon, nicht wahr? Man muss ja nur “versehentlich” einen präparierten USB-Stick mit der Aufschrift “Pornos” vor einer Firma verlieren, schon erhält man (nach kurzer Wartezeit freilich) bequem Zugriff auf alle Systeme (auf die der glückliche Finder Zugriff hat). Tipp, falls Sie es ausprobieren wollen: Tun Sie wirklich ein paar Pornos auf den Stick, dann schöpft das Opfer nicht so schnell Verdacht.

Bemerkenswert finde ich aber, dass der Tweet zwar nach ein paar Minuten gelöscht wurde – in der Zeit aber, wie man auf dem Bild sieht, fast 5000 mal geliked und halb so oft retweetet wurde. Wohlgemerkt: “Normale” Tweets des gleichen Accounts, meist mit fast sinnlich fotografierten Kampfflugzeigen drauf, bringen es gerade mal auf etwas über 100 Likes und 30 oder 50 Retweets – aber nicht innerhalb weniger Minuten, sondern Tagen.

Das ist ein Symptom, welches auf ein grundlegendes Problem der (a)sozialen Medien hinweist: Quatsch verbreitet sich bisweilen millionenfach schneller und weiter als alles andere. Das ist aber das genaue Gegenteil des Bedarfs: Wichtige (und möglichst akkurate) Informationen sollten sich schneller und besser verbreiten als anderen. Dieses wünschenswerte Verhalten bilden die Mechanismen der sozialen Netzwerke schlicht nicht ab. Deshalb sind sie ein Problem.

tl;dr: Das Beispiel der tausendfach retweeteten IT-Attacke eines Kleinkinds zeigt: Der “soziale” Kaskadier-Mechanismus von Twitter&Co begünstigt die Ausbreitung von Unsinn.

Entkopplung mit Events

Ein Ausweg aus der Multithread-Hölle (Sie wissen schon, die mit dem fröhlichen Bad in siedenden Race conditions) ist die Entkopplung mit Events. Statt einen linearen Programmablauf zu denken, der streckenweise aus wichtigen Gründen in verschiedenen Threads abläuft, denken Sie lieber an herumgereichte Events oder, allgemeiner: Nachrichten. Ein Message-Broker läuft dazu im Hintergrund und reicht Nachrichten herum. Das entspricht einem Publish-Subscribe-Entwurfsmuster. Der entscheidende Vorteil: Die Nachricht “gehört” immer nur jenem Programmteil (oder Thread), der gerade aktiv ist. Es gibt keinen gleichzeitigen Zugriff mehrerer Threads auf das gleiche Nachrichtenobjekt. Auch der Message-Broker interessiert sich nicht mehr für eine Nachricht, sobald er sie zugestellt hat. Am Ende der Verarbeitung wird einfach eine neue Nachricht mit dem Ergebnis der Berechnung auf gleiche Weise zurück geschickt.

Publish und Subscribe

Sie wissen sicher: Viele größere Software-Systeme arbeiten längst mit Microservices und Message-Brokern wie Apache Kafka, die Nachrichten herumreichen. Aber das geht auch in Android, und Sie können damit leicht und elegant Arbeit in den Hintergrund verlagern. Statt mit AsyncTask, Thread, Handler und runOnUiThread können Sie einfach EventBus verwenden – tun Sie vielleicht eh, denn die Library hat sich in unzähligen Apps bewährt:

dependencies {
implementation 'org.greenrobot:eventbus:3.2.0'
}

Meist verwenden Sie EventBus, um Nachrichten zwischen UI-Komponenten, Fragmenten und Activities oder Services auszutauschen. Aber da Sie per Annotation festlegen können, ob ein EventHandler im Vorder- oder Hintergrund aufgerufen wird, können Sie auch sehr einfach eine saubere Background-Task-Verarbeitung umsetzen:

EB ist eine Abkürzung für EventBus.getDefault()

Links, im Main Thread, schicken Sie (z.B. nach einem Knopfdruck des Nutzers) eine CalculationStartMsg los, nix weiter. Die Message ist ein POJO, das alle nötigen Daten enthält, um die gewünschte Berechnung zu starten. Diese Nachricht (oberer Kaffeefleck) stellt EventBus im Hintergrund zu (siehe @Subscribe-Annotation). Wohlgemerkt ist der UI-Thread völlig unbeteiligt, er macht nach dem EB.post() gar nichts mehr bzw. wartet auf weitere Eingaben.

Die Berechnung im Hintergrund erzeugt eine neue Nachricht mit dem Ergebnis der Berechnung, ResultMsg (unterer Kaffeefleck), und überstellt es dem EventBus. Dieser stellt es der passenden onMessageEvent-Funktion im Main-Thread zur Verfügung, die wiederum das Ergebnis in der UI darstellt.

Async im Pool

Falls Sie oft längere Berechnungen im Hintergrund durchführen, verwenden Sie statt ThreadMode.BACKGROUND lieber ThreadMode.ASYNC. Denn während erstere Variante nur einen Thread verwendet, und mehrere Operationen daher nacheinander verarbeiten muss, benutzt ASYNC einen ThreadPool und kann daher problemlos mehrfach und für länger dauernde Berechnungen (wie Netzwerkzugriff) eingesetzt werden.

Beachten Sie immer den Android-Lifecycle: Beide Klassen (die blaue und die orange) müssen bereits instanziiert sein, sonst können sie keine Events empfangen (). Entweder die Worker-Klasse wird in onCreate der Activity (blau) erzeugt, oder alle Funktionen liegen sogar in der gleichen Activity-Klasse. EventBus kann im Gegensatz zu (expliziten) Broadcasts keine neuen Objekte erzeugen. Natürlich müssen alle beteiligten Klassen sich bei EventBus registrieren (mit EventBus.getDefault().register(this)).

In den Messages können Sie beliebige serialisierbare Daten übertragen, auch größere Mengen. Die Latenz beträgt wenige Millisekunden.

tl;dr: EventBus-ähnliche Architektur löst auf elegante Weise viele Multithreading-Probleme, da sie auf gleichzeitige Zugriffe auf ein und dieselben Ressourcen prinzipiell verzichtet. Das bedeutet maximale Entkopplung, weniger Abhängigkeiten und weniger Probleme. Mit ganz einfachen Mitteln. Investieren Sie Ihre wertvolle Zeit lieber in wichtigere Dinge, zum Beispiel Vermeiden von Sicherheitslücken…