Rueckgabe-Erinnerung: ein Meldetag ist eine Meldung

Erinnert an faellige Rueckgaben verliehener Einzelstuecke, auf dem Weg der
Ablauf-Meldungen: lokale Benachrichtigung, geplant aus GET /loans?due_in=.
Je Server einstellbar - "X vorher", am Rueckgabetag, und taeglich weiter,
solange etwas ueberfaellig ist. Ein Verleih ohne Rueckgabedatum ist nie
faellig und kommt nicht vor.

Zwei Aenderungen am bestehenden Plan waren dafuer noetig, und beide haben
denselben Grund: Der Plan muss allein stehen. Der BGAppRefreshTask ist
keine Garantie - iOS fuehrt ihn nur aus, wenn es will -, also darf die
Erinnerung nicht davon abhaengen, dass die App geoeffnet wird.

1. Alles, was an einem Tag auf einem Server anliegt, wird EINE Meldung.
   Vorher waren es zwei Arten (bald ablaufend, abgelaufen) mit je eigener
   Kennung; mit dem Verleih waeren es vier geworden. iOS erlaubt 64
   geplante Mitteilungen je App - ein Platz je Tag statt je Art ist die
   Voraussetzung dafuer, dass der Horizont ueberhaupt hineinpasst. Ein
   vergessener Verleih hat sonst mit taeglicher Meldung den ganzen Monat
   belegt und alle MHD-Meldungen verdraengt, weil die weiter in der
   Zukunft liegen und bei der Kappung zuerst wegfallen.

2. Horizont 30 statt 60 Tage. Er ist damit die Zusage, wie lange die App
   ungeoeffnet bleiben darf, ohne dass Erinnerungen ausfallen. Ein
   laengerer Horizont haette nur spaetere Tage eingeplant und dafuer die
   naechsten verdraengt. Preis: Eine MHD-Regel mit mehr als 30 Tagen
   Vorlauf greift erst, wenn das Datum in dieses Fenster rueckt.

Der LoanPlanner ist wie der ExpiryPlanner netzfrei und ohne iOS-Typen
gebaut, damit sich die Entscheidungen ohne Geraet nachrechnen lassen.
Gespeicherte Konfigurationen werden mit decodeIfPresent gelesen - eine
bestehende Einstellung bleibt nach dem Update gueltig.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Scarriffle
2026-09-17 09:47:26 +02:00
co-authored by Claude Opus 5
parent aa72d8342a
commit b2dda78a7b
6 changed files with 326 additions and 44 deletions
+15 -5
View File
@@ -127,11 +127,21 @@ Selfhostbare Lebensmittel-Lagerverwaltung. Aufbau in mehreren Schritten.
*Verliehen / Überfällig / Im Haus*. Weil alle Scan-Wege (QR über
*Nachschlagen*, NFC-Tag, `vorrania://i/<UID>`) in derselben Ansicht enden, ist
„scannen und verleihen" damit überall möglich, ohne einen eigenen Weg dafür.
- Noch offen: die **Rückgabe-Erinnerung**. Sie kann nur den Weg der
Ablauf-Meldungen gehen (lokale Benachrichtigung der App aus einem
Server-Snapshot, `GET /loans?due_in=…` ist dafür schon die Datenquelle) –
echtes Push fehlt weiterhin, siehe Schritt 3. Beachten: iOS erlaubt 60
geplante Meldungen je App, die sich Verleih und MHD dann teilen müssen.
- **Rückgabe-Erinnerung** in der App, auf dem Weg der Ablauf-Meldungen: lokale
Benachrichtigung, geplant aus `GET /loans?due_in=…`. Einstellbar je Server:
„X vorher", am Rückgabetag, und täglich weiter, solange etwas überfällig ist.
Echtes Push (APNs) fehlt weiterhin, siehe Schritt 3.
- **Eine Meldung je Meldetag und Server** statt einer je Meldungsart. Vorher gab
es an einem Tag getrennte Mitteilungen für „bald ablaufend" und „abgelaufen";
mit dem Verleih wären es vier geworden. Der Grund ist nicht nur weniger Lärm:
iOS erlaubt 64 geplante Mitteilungen je App, und ein Platz je *Tag* statt je
Art ist die Voraussetzung dafür, dass der volle Planungshorizont hineinpasst.
- **Horizont auf 30 Tage** (vorher 60). Er ist die Zusage, wie lange die App
ungeöffnet bleiben darf, ohne dass Erinnerungen ausfallen – der
`BGAppRefreshTask` ist keine Garantie, iOS führt ihn nur aus, wenn es will.
Ein längerer Horizont hätte nur spätere Tage eingeplant und dafür die nächsten
verdrängt. *Preis:* Eine MHD-Regel mit mehr als 30 Tagen Vorlauf greift erst,
wenn das Datum in dieses Fenster rückt.
## Schritt 3 – Weitere Ideen – offen
- **Ablauf-Push-Benachrichtigungen** via APNs (setzt die App voraus).