Voller als voll

Wenn der Speicher voll ist, wirft Java bekanntlich einen OutOfMemoryError:

Oha.

Tatsächlich kann der Speicher sogar so knapp werden, dass er nicht einmal genügt, um ein Objekte der Klasse OutOfMemoryError zu erzeugen …

Wer genau hinschaut, kann sehen, dass der Fehler von com.android.vending geworfen wurde, also dem Play Store auf einem Android-Smartphone. Einem virtuellen allerdings, denn das Ganze ist beim Vorveröffentlichungs-Test einer App passiert.

Exkurs

Kleiner Exkurs über Speicher unter Java?

Nein … nur ein klitzekleiner, das Thema ist so groß, dass es gerade nicht in meinen Arbeitsspeicher passt.

Beim Start müssen wir der virtuellen Maschine von Java einen gewissen Spielraum einräumen – Speicher, der dann dem Programm zur Verfügung steht, sei es für Bytecode oder Objekte (es ist wirklich kompliziert). Der Garbage Collector ist ja einer der Hauptgründe, Java zu verwenden, weil er die Entwicklung so schön einfach macht. Programmierer müssen sich keine Gedanken darüber machen, wann sie ihre erzeugten Objekte wieder wegschmeißen müssen. Der Preis ist natürlich, dass der Garbage Collector Rechenzeit verbraucht – und das kann beim Verzicht auf Optimierungen durchaus merkliche Auswirkungen haben.

Zu viel Dingsbums

Beispiel Spiele: Normalerweise besitzen Spiele einen Renderer, der 30 mal pro Sekunde (oder öfter) den Bildschirm neu zeichnet. Da normalerweise bewegliche Dingsbums mit von der Partie sind, müssen Berechnungen stattfinden. Zum Beispiel sind Vektoren zu addieren, etwa so:

Vector3 newLocation = new Vector3(move(dingsbums,oldLocation,timePassed));
drawAt(dingsbums,newLocation);

Die erste Zeile erzeugt ein neues Objekt (newLocation) auf dem Heap. Am Ende der Zeichenfunktion ist es überflüssig, d.h. der Garbage Collector wird es irgendwann wegräumen. Jetzt stellen Sie sich vor, dass deutlich mehr als ein Dingsbums auf dem Bildschirm ist. Alle müssen sich bewegen, für jedes entsteht ein neues Vector3-Objekt, und das 30 mal pro Sekunde. Sie können sich leicht ausrechnen, wie viele Objekte der Garbage Collector letztlich aufzuräumen hat. Schlimmstenfalls macht sich das als Ruckeln bemerkbar, auf jeden Fall verbraucht es Prozessorzeit und damit Energie (also Akkuladung).

Besser ist es also, Objekte wiederzuverwenden. Dingsbums sollte über einen permanenten Vector3 verfügen, nur dessen Koordinaten (vielleicht native floats) ändern sich noch:

move(dingsbums,timePassed);
drawAt(dingsbums.getLocation());

Profilieren

Sie können mit Android Studio im Profiler genauso wie mit Java-Tools wie jmx die Aktivität des Garbage Collectors verfolgen. Ein guter Hinweis ist ein zackiger Sägezahnverlauf der Speicherbelegung. Wird der GC sehr oft aktiv, deutet das auf Optimierungspotenzial hin. Der Profiler zeigt dann an, in welchem initializer besonders viel Zeit draufgeht – damit wissen Sie, welche Objekte womöglich zu oft erzeugt werden.

Bekanntlich beträgt der Anteil der CO2-Ausstoßes der IT weltweit mit ihren ganzen Rechenzentren geschätzt 10-20%. Je effizienter Ihre Anwendung arbeitet, umso weniger ist sie daran schuld. Klingt vielleicht banal, aber nicht wenn Ihre App auf Milliarden Smartphones installiert ist und milliardenfach verwendet wird (und das wollen Sie doch, oder?).

Mehr zum Thema Speicherverbrauch und Effizienz in naher Zukunft und in der nächsten Auflage meines Buchs “Besser coden”.

Schriftarten in Android

Jeder, der schonmal eine Urkunde für seinen Zimmeraufräum-Weltmeister (6-jähriger Sohn) designt hat, weiß, dass man da mit Times New Roman und Arial keine Begeisterung auslöst. Auf 1001freefonts.com gibt es deutlich mehr als 1001 Schriftarten – aber wie kriegt man die in seine App?

Wer schonmal im Layout-Editor in Android Studio etwas herumprobiert hat, wird zumindest auf das hier gestoßen sein:

So weit, so langweilig – mehr als diese vier einfachen Varianten lassen sich hier nicht auswählen. Sie können nicht einfach einen Truetype-Font in irgendein Verzeichnis legen und dessen Namen hier hinschreiben. Wie geht’s also sonst?

Tatsächlich gibt es eine klassische Methode und eine neuere, die ich Ihnen hier kurz zeige.

Typefaces aus Assets

Die klassische Methode klappt nicht ohne Code. Dazu legen Sie zunächst die gewünschte Schriftart im TTF-Format ins Verzeichnis assets/fonts. Damit sorgen Sie dafür, dass die Schrift in Ihr APK eingebaut wird. (Der Verzeichnisname fonts ist willkürlich, Sie können ihn auch irgendwie nennen.)

An dieser Stelle eine freundlich gemeinte Warnung: Es sieht nicht nur unprofessionell aus, wenn Sie auf einem Bildschirm 10 verschiedene Schnörkelschriften verwenden – es kostet auch Speicher und Rechenzeit. Achten Sie darauf, nicht zu viele und nicht zu komplexe Schriften zu verwenden. Letzteres erkennen Sie an der Größe der TTF-Datei.

Und noch eine Warnung: Viele im Netz auffindbare Schriften verfügen nicht über deutsche Umlaute. Und die wenigsten bieten Unterstützung auch für ausgefallene Zeichen. Wenn Sie ohnehin keine fremden Schriftsysteme oder Sprachen unterstützen wollen, können Sie das getrost ignorieren – bedenken Sie aber, dass ein griechischer Nutzer Ihres Spiels beim Eingeben seines Namens für Ihre Online-Highscore-Liste möglicherweise griechische Zeichen verwenden möchte. Wenn Sie dem zugehörigen EditText eine Schriftart ohne griechische Buchstaben zugewiesen haben, sieht der Nutzer bloß kleine Rechtecke.

Genug Warnungen, kommen wir zum Programmcode.

Die Schriftart eines TextViews (oder einer Ableitung davon, wie Button) setzen Sie wie folgt:

textView.setTypeface(typeface);

Das zugehörige Typeface-Objekt erzeugen Sie mit einer einfachen Create-Funktion:

Typeface typeface=Typeface.createFromAsset(am, path);

Dabei ist am der AssetManager Ihres Contexts, den Sie innerhalb einer Activity mit getAssets() erhalten.

Als Pfad path übergeben Sie den Dateinamen Ihrer Schriftart relativ zum Verzeichnis assets.

Schriften per FontFamily

Die moderne Variante funktioniert ohne Code. Font-Definitionen per XML wurde in Android 8 eingeführt und funktioniert dank Rückwärtskompatibilität per AndroidX bis hinunter zu Android 4.1 (API 16), was für ungefähr 99% der verwendeten Geräte auf der Welt genügt.

Nunmehr gehören Ihre Schriftartdateien ins Verzeichnis res/font.

Diese referenzieren Sie einfach im TextView-Attribut fontFamily:

Es lassen sich außerdem FontFamilies definieren, so dass für fette oder kursive Schrift automatisch die passende Schriftartdatei zum Einsatz kommt. Mehr zu Fonts erfahren Sie in der offiziellen Dokumentation:

https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml

Delphi: Unkaputtbar

Kürzlich wurde ich gefragt, ob ich denn Pascal beherrsche. Nun, diese Sprache hat mir mein Informatik-Lehrer in der 9. und 10. Klasse beigebracht, das war so anno 84/85. Dergleichen vergisst man genausowenig wie die Musik, die man damals gehört hat, und die teilweise so ähnlich klang wie prozeduraler Code. Natürlich hat sich seitdem einiges verändert: Ältere von uns erinnern sich bestimmt an die “Delphi-Epoche”, in der so ziemlich jede Free- oder Shareware für Windows mit Borlands praktischer RAD-IDE gebaut wurde.

Aber nicht nur das: Viele mittelständische Unternehmen verwenden immer noch Delphi-Software, weil es schlicht viel zu aufwändig wäre, sie neu zu schreiben, und – nun ja, sie funktioniert ja. Delphi kommt inzwischen von Embarcardero. Es gibt eine kostenlose Community Edition 10.3 des RAD Studio, das immer noch so funktioniert wie vor Jahrzehnten und das Versprechen des “rapid application development” auch hält: Die UI wird mit der Maus gebastelt, heraus kommt am Ende ein 32- oder 64-bittiges Binary, das (mit verlinkten Laufzeitbilbiotheken) sofort auf jeder Windows-Kiste läuft. Inzwischen wurden zig Features, die man zuvor immer nachrüsten musste, integriert, zum Beispiel Git/Subversion, unzählige Komponenten für HTTP, REST, Xml, Gestensteuerung und auch Must-haves wie Refactoring.

Delphi 10.3 Community Edition: Retro-Programming für die kleine UI-Anwendung zwischendurch

Natürlich würde niemand heutzutage ein neues Projekt mit Delphi beginnen, oder? Es muss ja immer gleich eine Webanwendung sein, deployed auf zig Kubernetes-Clustern, Amazon freut sich dann über die AWS-Kosten. Dafür gibt es natürlich gute Gründe (zum Beispiel kann man jederzeit Updates durchführen, ohne dass der Kunde irgendetwas tun muss), und die meisten Menschen, die Pascal sprechen, sind ihrer Rente näher als dem Abitur. Woher sollte man solche Entwickler also auch nehmen?

Da es mit FreePascal/Lazarus auch eine freie Alternative gibt, ist die Zukunft von Pascal gesichert. Sauber programmieren kann man auch mit dieser alten Sprache. Wenn man nicht alles in seine TForm-Klassen stopft (wozu Delphi ja leider ermuntert) und das Single-Responsibility-Prinzip achtet, wohlgemerkt. Delphi unterstützt auch Linux und inzwischen sogar Android und iOS. Ob es eine gute Idee ist, eine App in Pascal zu schreiben, wage ich nicht zu beurteilen, falls jemand sachdienliche Hinweise dazu hat, immer her damit!

Wer’s mal ausprobieren möchte: Die Community-Edition erfordert nur eine kostenlose Registrierung und ist hier erhältlich.

Ganz ehrlich: Ich finde, dass sich Delphi unter Windows langsam und flackerig anfühlt. Die IDE assistiert mir bei weitem nicht so komfortabel wie die von IntelliJ oder VS Code (oder, okay, Opa Eclipse). Es wird nicht im Hintergrund kompiliert, so dass mein korrekter Code rot unterstrichen bleibt, bis ich explizit ein Build auslöse. Man ist ja verwöhnt …

Visual Forth für Android und Arduino

Ich bin ja Experte darin, Dinge in einen Topf zu werfen, die sonst nix miteinander am Hut haben. Anders ausgedrückt:

Wenn man Müsli, Tomatensoße, Klebstoff und Lötzinn kräftig aufkocht, kommt wohl etwas wie das hier dabei raus:

Das ist … erklärungsbedürftig.

Das Bild zeigt eine App, an der ich gerade arbeite, und die demnächst ins Licht der Öffentlichkeit treten wird (ich teste und optimiere noch wild dran herum). Hinter dem klobigen Namen “Visual Forth for Arduino” verbirgt sich eine Art grafische Variante der Programmiersprache Forth. Ähnlich wie Scratch kann man Befehle als Klötzchen untereinander kleben, um ein Programm zu erzeugen. Der Clou daran: Dieses Programm läuft dann per Knopfdruck auf einem ganz normalen Arduino Nano, der über ein OTG-Kabel via USB am Tablet hängt. Einzige Voraussetzung: Der Arduino wurde zuvor mit Finf bespielt. Finf (“Finf is not Forth”) ist eine kleine Forth-Umgebung für Arduino, Open Source, ursprünglich von Leandro A. F. Pereira, wird aber von mir weiterentwickelt (und korrigiert, räusper). Meine App erzeugt also aus den Klötzchen Forth-Code (oder besser: Finf-Code und lässt ihn auf dem Arduino laufen.

Vorteil im Vergleich zu Scratch für Arduino: Das Programm funktioniert auch dann noch, wenn man den Arduino aus dem Tablet stöpselt und einfach an eine Stromversorgung anschließt! (In der Premium-Version meiner App, har har.)

Jetzt könnt ihr ja mal raten, was obiger Forth-Code auf dem Arduino tut.

Auflösung
Wenn man den mittleren Anschluss eines Spannungsteilers mit einem normalen und einem lichtempfindlichen Widerstand an Eingang A2 anschließt und eine Leuchtdiode an D2, dann geht die LED an, wenn es dunkel wird.

An der Einrücktiefe erkennt man übrigens die Stapel-Höhe vor dem jeweiligen Befehl. So hinterlässt der Analogread-Befehl seinen Messwert natürlich (symbolisch sichtbar anhand der Einrückung darunter) auf dem Stapel. Daher “visuell” – denn wer mal versucht hat, Forth zu programmieren, ist entweder verrückt geworden oder hat sich dergleichen aufgemalt (Mehr zum Thema “Forth” und “verrückt” in diesem Buch).

Meinen Fork von Finf gibt es hier auf github.

Mehr zu diesem spannenden Maker-Thema demnächst.

Android-Speicher sparen mit Google Go

Ich wollte ja schon moppern: “Was hilft das Speicher sparende Google Go, wenn man die fette, große Google-App eh nicht deinstallieren kann?”
Aber es hilft tatsächlich, in Zahlen: Bei mir aufm Xperia 450 MB mehr freier Speicherplatz, wenn ich Google Go installiere und die Google-App deaktiviere (komplett deinstallieren geht ja nicht). Ob ich irgendwelche Features vermisse, oder ob Google Go sich mit der Zeit auch ein halbes Gigabyte reinpfeift, erzähl ich später …
Die Sache zeigt jedenfalls: Wenn man will (oder vom Boss dazu gezwungen wird), kann man durchaus speichersparend programmieren, liebe Entwickler!

(j)Box2d

Für unser neues Android-Gameprojekt (ist noch unter höchster Geheimhaltungsstufe) brauchte ich eine Physik-Engine. Natürlich trifft man als allererstes auf Box2D bzw. deren Java-Version jBox2D.

Ich griff zu letzterer, nachdem ich irgendwo gelesen hatte, der Performanceunterschied sei nicht allzu groß. Dass das Projekt seit 2014 kein Release mehr gesehen hat (aber durchaus Commits!), fand ich nicht weiter schlimm, es ist stabil, gut getestet, von recht hoher Codequalität und da die Physik selten Features hinzugewinnt, muss auch so eine Library nicht dauernd irgendwas nachziehen.

Ich litt etwas unter einem gewissen Mangel an Beispielcode – die meisten Programmierer verwenden heutzutage ja multiplattformhalber Unity und mühen sich nicht mit Android-Libraries ab. Ich bin da speziell – durch konsequente Nichtunterstützung von iPhones habe ich den Apfelkonzern schon an den Rand des Ruins gebracht.

Bei Levels mit etwas mehr physikalischen Objekten darin hatte die Engine merklich Probleme, die Framerate von mindestens 25fps zu halten, jedenfalls in Momenten mit vielen Kollisionen; teils flogen auch mal Teile durcheinander durch. Nun muss man wissen, dass jBox2Ds Funktion world.step() (die für die Physik zuständig ist) single-threaded ist, aber Phones und Tablets heutzutagen auch schon mit 2, 4 oder 8 Kernen daher kommen. Da wird eine Menge Potenzial nicht genutzt. Zwar gilt für die native C++-Version dasselbe, aber Maschinensprache ist eben per se schneller als Java.

Der große Aha-Effekt kam, als ich mir probeweise ein chinesisches Billig-Tablet beschaffte (XGody, 10 Zoll, knappe 70 Euro bei ebay, aber sogar mit OTG-Kabel in der Schachtel (zur hypercoolen Verwendung solcher Kabel in Kürze mehr an dieser Stelle)). Die Framerate sank bei Action im Bild auf unter 5 fps. Autsch.

Eine schnelle Messung ergab: Die Grafik ist nicht schuld, das komplette Zeichnen inklusive Debug-Hilfslinien etc. dauert (im TextureView) nur 25ms. Aber world.step() brauchte 40ms und mehr.

Also ging ich daran, jBox2D durch box2D zu ersetzen. Nun darf man sich das nicht zu einfach vorstellen, denn die Bibliothek gibt es nur im Quellcode, und übrigens auch auf dem Stand von 2014, wie gesagt: Seither hat sich an der Physik dieses Universums nichts verändert.

Die einzige praktikable Option heißt libgdx: Diese Multiplattform-Gameengine verfügt nämlich über ein Erweiterungsmodul, das die native box2D-Bibliothek enthält, und zwar verpackt in einen dünnen Java-Wrapper. Wie sich herausstellte, ließ sich jBox2D fast 1:1 durch libgdx-box2D ersetzen. Fast.

Ein paar Klassen heißen in box2D anders, z.B. Vector2 statt Vec2. Einige Attribute sind nur mit Gettern und nicht direkt zugreifbar. Und body.userdata lässt sich nicht über BodyDef setzen, nur direkt im Body. Eine Klasse AABB (zur Kollisionsberechnung) gibt es nicht, world.QueryAABB() nimmt direkt die Koordinaten des Rechtecks entgegen. Alles recht schmerzfrei.

Natürlich wollte ich nicht das ganze Projekt auf libgdx umstellen, deshalb konnte ich nicht den libgdx-eigenen Project-Wizard verwenden, der auf Wunsch direkt ein Gradle-Projekt mit Box2D-Unterstützung erzeugt. Und wie man das per Hand hinbekommt, steht nirgendwo. Also war probieren angesagt. Entscheidend sind ein paar Änderungen in der build.gradle. Als da wären:

android {
  ...
  defaultConfig {
    ...
    ndk {
      abiFilters "armeabi-v7a", "x86", "armeabi", "x86_64", "arm64-v8a"
    }
  }
}

Dies sorgt dafür, dass die App später die aufgeführten Architekturen unterstützt. Wichtig dabei: Ab 1. August ist Unterstützung der 64-Bit-Architekturen seitens Google Play obligatorisch!

sourceSets {
        main {
            jniLibs.srcDirs = ['lib']
        }
    }

Hiermit wird das Verzeichnis für die nativen Libs festgelegt. Aber woher kommen die?

task copyAndroidNatives {
    doFirst {
        file("lib/armeabi/").mkdirs()
        file("lib/armeabi-v7a/").mkdirs()
        file("lib/arm64-v8a/").mkdirs()
        file("lib/x86_64/").mkdirs()
        file("lib/x86/").mkdirs()

        configurations.natives.files.each { jar ->
            def outputDir = null
            if (jar.name.endsWith("natives-arm64-v8a.jar")) outputDir = file("lib/arm64-v8a")
            if (jar.name.endsWith("natives-armeabi-v7a.jar")) outputDir = file("lib/armeabi-v7a")
            if(jar.name.endsWith("natives-armeabi.jar")) outputDir = file("lib/armeabi")
            if(jar.name.endsWith("natives-x86_64.jar")) outputDir = file("lib/x86_64")
            if(jar.name.endsWith("natives-x86.jar")) outputDir = file("lib/x86")
            if(outputDir != null) {
                copy {
                    from zipTree(jar)
                    into outputDir
                    include "*.so"
                }
            }
        }
    }
}

tasks.whenTaskAdded { packageTask ->
    if (packageTask.name.contains("package")) {
        packageTask.dependsOn 'copyAndroidNatives'
    }
}

So wird Gradle beigebracht, die nativen Bibliotheken an Ort und Stelle abzulegen. (Man kann das später in Android Studio mit Analyze/APK… nachschauen.)

Fehlt noch:

configurations {
    natives
}
dependencies {
   ...
    implementation "com.badlogicgames.gdx:gdx-box2d:$gdxVersion"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-armeabi"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-armeabi-v7a"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-arm64-v8a"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-x86"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-x86_64"
}

Tatsächlich binde ich hier NUR gdx-box2d ein, und nicht die Hauptbibliothek libgdx selbst, die ich nicht brauche.

Die zu verwendende gdxVersion lege ich in der hierarchisch obersten build.gradle fest:

allprojects {
    repositories {
        google()
        jcenter()
        mavenCentral()
    }
    ext {
        gdxVersion = '1.9.9'
    }
}

Und nun zur Pointe: Die native Version der Bibliothek ist grob geschätzt um einen Faktor 25 schneller. Sogar das lahme-Ente-Tablet aus China erreicht damit eine spielbare Framerate:

Mit ins Bild geschummelt hat sich das mitgelieferte OTG-Kabel

Ein schnelleres Tablet oder Phone kommt locker auf 1ms Rechenaufwand für die Physik (also world.step()), während das Zeichnen “nur” um einen Faktor 3 schneller ist. Aber da lässt sich sicher auch noch was optimieren, das soll ein andermal erzählt werden.

Der Teufel steckt aber mal wieder im Detail. Während jBox2D und box2d selbst ihre physikalischen Objekte (bodies) in verketteten Listen verwalten, benutzt der libgdx-Wrapper zusätzlich eine LongMap. Deren Schlüssel sind aber nicht sortiert, daher geht die Reihenfolge der Bodies zwischen Hinzufügen und Zeichnen verloren! Da keine Möglichkeit vorgesehen ist, eine z-Ebene mitzugeben, kann es passieren, dass Objekte vor anderen (also später) gezeichnet werden, die eigentlich dahinter gezeichnet werden sollen (also früher). Da hat wohl jemand tief geschlafen, als er den Wrapper implementiert hat. Mal sehen, wie ich das löse. Es bleibt spannend.

TILT: Hier geht die Reihenfolge verloren, in der die Bodys hinzugefügt werden, da der Schlüssel der verwendeten LongMap keine Reihenfolge kennt (World.java).

Fazit: Finger weg von jBox2D, sondern gleich die native Version nehmen. Schneller ist schöner.

Ich bedanke mich für die Aufmerksamkeit und gehe mal besser coden.

Fundstücke (Ausgabe Februar ’19)

Natürlich völlig anonymisiert und verfremdet präsentiere ich mal wieder einige aktuelle Fundstücke aus meiner Tätigkeit als gefürchteter Softwarequälitäts-Ganzgenauhinschauerundbesserwisser. Manchmal läuft einem ein Schauer über den Rücken, wenn man den Kontext kennt, aus dem der fragliche Code stammt (den ich freilich nicht verraten darf, weil ich meterlange Verschwiegenheitserklärungen unterschrieben habe). Funktioniert diese Software wirklich genau so, wie sie soll? Und wenn ja: Wie lange noch?

package com.companyname.classesToDeleteWhenUsingJava6;
// TODO delete as soon as Java 1.6 available

Java 1.6, auch bekannt als 6.0, erschien Ende 2006, also vor 13 Jahren.

Nun ja, es hat sich wohl noch nicht überall herumgesprochen, dass Code auch nach Inbetriebnahme gewisser Pflege bedarf. Nur einer der Gründe, wieso Softwarekosten häufig zu niedrig angesetzt werden.

////// ????? ask norbert

Ja, über lustige Kommentare und deren (Un)Zulässigkeit kann man trefflich streiten. Nicht streiten kann man über TODOs, die nicht einmal als solche gekennzeichnet sind. Wenn hier tatsächlich fachlicher Klärungsbedarf besteht oder bestand, dann gehört die eigentliche Frage (die hier zudem nicht einmal hier steht!) nicht in den Code, wo sie ganz offensichtlich in Vergessenheit geriet, sondern in eine Mail an Norbert, in ein Ticket oder von mir aus auf ein Post-it, obwohl die den Nachteil haben, beim Durchlüften verloren zu gehen, und die positive Wirkung von Frischluft aufs Denkvermögen sollte man nicht unterschätzen. The answer my friend is blowing in the wind. But not in the code.

Hier mal kein Codebeispiel, sondern eine Auswirkung: Der direkte Weg in die Programmiererhölle, sogar im wahrsten Sinne des Wortes. Wer auch immer da bei Spotify (oder bei einem Musikverlag, von dem die Daten ursprünglich stammen) eine Art Metadaten-Migration von “V2 to V3” implementiert hat: Er hat irgendeinen Spezialfall nicht berücksichtigt, so dass beim Copyright dieses Albums ein unsinniger Default-Wert (“Default-C Credit”) eingesetzt wurde. Metadaten-Fehler sind auf den ersten Blick harmlos, weil an sie meist keine kritische Geschäftslogik geknüpft ist. Aus leidvoller Erfahrung mit dem Thema Musik-Metadaten kann ich jedoch verraten: Obacht! Es kann passieren, dass durch ähnliche Fehler ein Titel gar nicht erst in einem Suchindex landet und folglich nicht auffindbar ist. Bei einigen Songs für die Nicht-Hörer sicher verschmerzbar, nicht aber für den Künstler. Jedenfalls ein Fehler, der nicht hätte passieren müssen. Spätestens bei einem Codereview hätte jemand feststellen müssen, dass so etwas wie “Default-Credits” überhaupt keinen Sinn ergeben. Der Bug kann Stand heute (Februar 2019) übrigens weiterhin im Spotify-Webplayer besichtigt werden.

Android: Speichern ohne Genehmigung

Ein Appetizer aus meinem in Kürze erscheinenden Buch: Android-Apps entwickeln für Einsteiger (8. Auflage).

Von Ihrem PC kennen Sie den »Speichern unter«-Dialog. Jede installierte Anwendung funktioniert in dieser Hinsicht gleich: Sie überlässt Ihnen als Nutzer die Entscheidung, wo ein Dokument landen soll und unter welchem Namen.

Tatsächlich existiert ein solcher Dialog auch unter Android, bloß verwenden ihn nur wenige Apps. Dabei hat das sich dahinter verbergende Storage Access Framework sogar einen immensen Vorteil: Es kommt ohne die Genehmigung zum Speichern von Dateien auf der SD-Karte aus!

Lassen Sie uns als Beispiel einen Mini-Editor schreiben, der es dem Nutzer erlaubt, einen Text einzugeben und ihn mittels Storage Access Framework zu speichern. Dieser bescheidene Funktionsumfang rechtfertigt eigentlich nur den Projektnamen MiniMiniEditor.

Achten Sie darauf, beim Anlegen des Projekts die minSdkVersion auf 19 zu stellen (Android 4.4), denn zuvor existierte das Storage Access Framework noch nicht.

Schalten Sie außerdem die Unterstützung für Java 8 ein, da die folgenden Codezeilen eine Methodenreferenz verwenden.

Verwenden Sie im Layout activity_main.xml ein vertikales LinearLayout, und setzen Sie einen Speichern-Button und ein EditText hinein. Damit letztere View den gesamten verfügbaren Platz ausfüllt und mehrzeiligen Text entgegennimmt, setzen Sie die Attribute wie folgt:

 <EditText android:id="@+id/text"  android:layout_width="match_parent" android:layout_height="0dp"  android:gravity="top|left"  ndroid:layout_weight="1" android:inputType="textMultiLine" />

In der Klasse MainActivity verknüpfen Sie zunächst den EditText mit der festgelegten ID text mit einem Attribut editText und den Button mit einem Listener:

editText = findViewById(R.id.text); 
findViewById(R.id.save).setOnClickListener(this::onSaveClicked);

Wenn der Nutzer auf den Speichern-Button drückt, basteln Sie ein spezielles Intent-Objekt:

Intent intent = new Intent(Intent.ACTION_CREATE_DOCUMENT); 
intent.addCategory(Intent.CATEGORY_DEFAULT); intent.setType("text/plain");
intent.putExtra(Intent.EXTRA_TITLE, "");
startActivityForResult(intent, REQUESTCODE_SAVE);

Entscheidend ist hier die Action ACTION_CREATE_DOCUMENT. Als EXTRA_TITLE können Sie einen Dateinamen vorgeben, den der Nutzer noch ändern kann.

Was Sie hier nicht sehen, ist der eingegebene Text: Der wird nicht etwa an den Intent gehängt, sondern in einem zweiten Schritt gespeichert. Dadurch erhält die Dateiauswahl nie Zugriff auf die fraglichen Daten. Für das eigentliche Speichern sind Sie selbst zuständig.

Deshalb starten Sie den Intent mit startActivityForResult() und übergeben einen frei definierbaren Request-Code.

Der Storage Access Provider horcht mit einem Intent-Filter darauf und präsentiert dem Nutzer einen Auswahldialog.

Standardmäßig zeigt der Speichern unter-Dialog nicht viele mögliche Ziele an: meist nur das Downloads-Verzeichnis und Ihr Google Drive, falls vorhanden. Aber hinter dem Zahnrad rechts oben erreichen Sie den Einstellungen-Dialog, wo Sie mit Erweiterte Geräte anzeigen dafür sorgen können, dass auch Ihr interner Speicher sowie eine eventuell eingesetzte SD-Karte erscheinen. Die meisten neueren Android-Geräte zeigen hier auch USB-Speichermedien an, die Sie einstöpseln.

Sobald der Nutzer das gewünschte Ziel ausgewählt hat, sendet das Storage Access Framework Ihrer Activity ein Ergebnis. Das nehmen Sie entgegen, indem Sie die Methode onActivityResult() überschreiben:

 public void onActivityResult(int requestCode, int resultCode, Intent resultData) { }

Da an dieser Stelle grundsätzlich ganz unterschiedliche Mitteilungen eintreffen können, müssen Sie den requestCode mit Ihrer Definition vergleichen. Der resultCode verrät Ihnen, ob der Nutzer den Vorgang erfolgreich beendet hat – nur dann möchten Sie etwas speichern:

if(requestCode==REQUESTCODE_SAVE
&& resultCode==Activity.RESULT_OK) {
}

Das Storage Access Framework übergibt Ihnen im Intent resultData das Ziel für Ihre Datei, und zwar in Form einer URI:

Uri
uri = resultData.getData();

Diese URI zeigt auf einen Dateipfad, aber dessen genauer Ort muss Sie nicht interessieren. Sie verwenden lediglich den ContentResolver, um sich einen OutputStream zu beschaffen, der Ihre Daten an die richtige Stelle schreibt. Das Storage Access Framework sorgt dafür, dass Sie temporär die nötigen Schreibrechte besitzen, obwohl Ihre App keinerlei Genehmigung zum Schreiben auf den Datenträger besitzt.

Der Schreibvorgang funktioniert im Fall von Textdaten am einfachsten über einen PrintWriter:

 try {
OutputStream stream = getContentResolver().openOutputStream(uri);
PrintWriter writer = new PrintWriter(stream);
writer.write(editText.getText().toString());
writer.flush();
stream.close();
} catch (java.io.IOException e) {
Log.e(getLocalClassName(),"caught IOException",e);
}

Das war schon alles. Natürlich können Sie dem Nutzer jetzt noch eine Erfolgsmeldung zeigen (und im Fehlerfall eine Fehlermeldung), aber das überlasse ich Ihnen.

Das Storage Access Framework kann auch dazu dienen, vorhandene Dateien zum Öffnen auszuwählen, z. B? Mediendateien. Als Intent-Action verwenden Sie dann ACTION_OPEN_DOCUMENT, der Rest funktioniert analog – ebenfalls ohne irgendwelche Permissions. Letztlich entscheidet der Nutzer im Einzelfall darüber, auf welche Dateien Ihre App zugreifen darf, deshalb ist die allgemeine Permission verzichtbar – das ist durchaus manchmal ein Vorteil, denn viele skeptische Nutzer installieren nur Apps, die möglichst wenige Genehmigungen einfordern.

Diese und viele andere nützliche Tipps finden Sie in meinem Buch: Android-Apps entwickeln für Einsteiger (8. Auflage), erschienen im Rheinwerk-Verlag