Weiterlesen, wo ich war!

yomikata

Manga-Reader für Android und Browser, mit eigenem Backend vor meiner Bibliothek. Der Lesestand gilt auf beiden Geräten, Bände auch offline.

Worum es geht

Ich lese Manga unterwegs auf dem Telefon und zu Hause auf dem Tablet, dieselbe Serie auf beiden. Die Bände liegen auf meinem eigenen Grimmory-Server, und dessen eingebauter Leser taugte dafür wenig. Die fremden Apps, die ich danach probiert habe, scheiterten am Server oder kannten keinen Lesestand, den beide Geräte teilen.

yomikata ist der Leser dafür: eine Android-App und eine Weboberfläche, beide gegen ein eigenes Backend, das seinerseits mit der Bibliothek spricht. Dazu kommt, was einen Manga-Leser von einem Comic-Leser unterscheidet: Die Leserichtung wird pro Serie gesetzt, weil eine gemischte Bibliothek beide Richtungen enthält und der Server dazu bei jeder Serie dasselbe sagt. Heruntergeladene Bände sind im Flugmodus vollständig lesbar und räumen sich nach dem Durchlesen selbst weg. Helligkeit und Warmfilter sitzen im Leser selbst, nicht drei Ebenen tief in den Einstellungen: abends ist die Mindesthelligkeit des Systems zu hell.

Der Panel-Modus ist das, was ich am liebsten vorführe. Auf dem Telefon entscheidet er, ob Lesen dort überhaupt geht. Eine Doppelseite mit sieben Panels ist auf sechs Zoll ein Suchbild: zoomen, schieben, die Leserichtung verlieren, die bei Manga von rechts nach links läuft. Deshalb kennt die Seite ihre Panels. Ein Doppeltipp schaltet um, danach führt jeder Tipp zum nächsten Panel, herangezoomt und zentriert, alles andere abgedunkelt, am Seitenende von selbst weiter auf die nächste. Die Reihenfolge steht in den Daten, schon in Leserichtung, der Leser sortiert nie selbst. Die Panels findet Magi, ein Bildmodell, das eigens für Manga trainiert wurde. Gerechnet wird auf meinem Rechner, in einem eigenen Werkzeug, das für große Läufe Grafikkarten mietet und sie hinterher wieder abschaltet.

Die App ist für wenige Leute mit je zwei Geräten gebaut, und dabei bleibt es: ein Erscheinungsbild, ein Dateiformat, keine Filter, keine Sortierung. Eigene Konten, eigene Zugänge und eigene Lesestände trägt das Backend darunter, und wer das helle Erscheinungsbild vermisst, liest im Browser. Einfach vor allgemein, das habe ich mir als Regel aufgeschrieben.

Warum es so gebaut ist

Fünf Stellen, an denen es auch anders gegangen wäre.

Den Server vermessen, statt der Beschreibung zu glauben
Die Grimmory-Instanz bietet eine Schnittstelle, hält aber nicht alles, was deren Beschreibung verspricht: ausgerechnet einen Lesestand abzulegen war nicht darunter, und zwar bei keinem einzigen Buch. Wäre das erst beim Bauen aufgefallen, hätte es die einzige Funktion gekostet, derentwegen es die App gibt. Statt auf ein Update fremder Software zu warten, ist die App auf das zugeschnitten, was der Server nachweislich kann.
Die höhere Seite gewinnt
Zwei Geräte melden für dasselbe Buch verschiedene Seiten, und einer der beiden Stände muss weichen. Die übliche Regel (der neuere gewinnt) wäre hier die falsche. Wer am Tablet auf Seite 80 ist und das Buch am Telefon versehentlich aufschlägt, hätte mit Seite 1 den frischeren Eintrag, und der Fortschritt wäre weg. Deshalb gewinnt die höhere Seite, und nur ein ausdrückliches Zurücksetzen darf darunter.
Zwischengespeichert ist nicht heruntergeladen
Gelesene Seiten bleiben auf der Platte liegen, damit Zurückblättern sofort geht. Das sieht aus wie ein Download, ist aber keiner. Und ein Zwischenspeicher, den man für eine Offline-Garantie hält, führt zum schlimmsten Fehlerbild: im Zug ein Buch öffnen, das gestern noch da war. Beide Speicher werden deshalb getrennt geführt, getrennt geräumt und getrennt angezeigt. Die Offline-Markierung trägt nur, was ausdrücklich geladen wurde.
Das Rechnen gehört nicht auf den Server
Die Panels müssen irgendwo entstehen, und der naheliegende Ort wäre das Backend: eine Warteschlange, ein Job je Band, fertig. Der Server ist aber ein kleiner VPS. Er trüge damit ein Job-System und eine Bildverarbeitung für eine Aufgabe, die je Band genau einmal anfällt. Stattdessen rechnet ein lokales Werkzeug, das Panel-Studio, und lädt die fertige Geometrie hoch. Der Server prüft nur, ob sie stimmt. Auch verworfen: die Rechtecke in die Dateien selbst zu legen. Dafür gibt es kein Format, das eines der beteiligten Programme liest. Und jedes Umpacken änderte die Prüfsummen der Dateien, und an denen hängt der Lesestand.
Grafikkarten mieten statt die eigene zu quälen
Eine Seite zu vermessen dauert auf der eigenen CPU dreieinhalb Sekunden. Achtzig neue Bände sind damit sechzehn Stunden, in denen der Rechner nichts anderes vernünftig tut. Auf einer gemieteten Karte dauert dieselbe Seite gut ein Zehntel einer Sekunde, abgerechnet wird nach Minuten. Der größte Lauf bisher waren 16.366 Seiten auf zwei Maschinen, vierzehn Minuten, fünfzig Cent. Dass fremde Hardware einen Ausweis für die eigene Bibliothek bekommt, war der eigentliche Einwand. Deshalb holen sich die gemieteten Maschinen ein zweites, kurzlebiges Token, das nach dem Lauf widerrufen wird.

yomikata

Worum es geht

Warum es so gebaut ist

Den Server vermessen, statt der Beschreibung zu glauben

Die höhere Seite gewinnt

Zwischengespeichert ist nicht heruntergeladen

Das Rechnen gehört nicht auf den Server

Grafikkarten mieten statt die eigene zu quälen

Mitmachen? Fragen zu einem Projekt? Schreib mir.

Die ganze Seite in einem anderen Design