docs: Entwurf fuer die Konzert-Meldungen im Backlog festhalten
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
7879e37a7b
commit
1366ec3832
1 file changed
+19
-2
+19
-2
@@ -1319,8 +1319,25 @@ Polish release: Android navigation and offline resilience, download accuracy for
|
||||
Daten liegen schon vor (`POST /api/artist-releases`), es fehlt der Vergleich „was ist seit
|
||||
deinem letzten Besuch dazugekommen" und der Eintrag in der vorhandenen Benachrichtigungsglocke
|
||||
(wahlweise Push).
|
||||
- **Konzert-Meldungen:** die vorhandene **Ticketmaster**-Anbindung wiederverwenden und melden,
|
||||
wenn ein gefolgter Künstler in der Nähe spielt. Bewusst zurückgestellt — erst die Neuheiten.
|
||||
- **Konzert-Meldungen:** die vorhandene **Ticketmaster**-Anbindung wiederverwenden und zeigen,
|
||||
wann gefolgte Künstler spielen. Bewusst zurückgestellt — erst die Neuheiten. Der Entwurf steht
|
||||
aber schon (25.9.2026):
|
||||
- **Ein Einstieg, zwei Reiter**, kein zweiter Knopf in der Favoriten-Kopfzeile. Neuheiten und
|
||||
Konzerte sind dasselbe Thema; zwei Knöpfe drängeln sich, und man muss sich merken, welcher
|
||||
was zeigt. Die Zeitleiste bekommt oben *Neu erschienen* / *Konzerte*, die Tages-Chips
|
||||
(90/30/365) gelten nur für die Neuheiten.
|
||||
- **Nicht in eine gemeinsame Liste mischen.** Veröffentlichungen liegen in der Vergangenheit,
|
||||
Konzerte in der Zukunft. Chronologisch gemischt stünde „heute" mittendrin und man wüsste nie,
|
||||
ob man gerade vorwärts oder rückwärts liest.
|
||||
- **Ort erst später, dann per `.env` im Backend** (Land, optional Stadt und Umkreis). Fürs
|
||||
Erste reicht, was die API von sich aus liefert — die Abfrage sucht heute weltweit
|
||||
(`/api/events/:artist`, `keyword=`, `size=20`, nach Datum sortiert).
|
||||
- **Offene Schwachstelle: die Abfrage läuft über den Namen, nicht über eine ID.** Dieselbe
|
||||
Falle wie bei der Deezer-Zuordnung — „TPR" oder „MORE" treffen als Stichwort alles Mögliche.
|
||||
Ticketmaster hat dafür `attractionId`; die einmal pro Künstler auflösen und zwischenspeichern,
|
||||
so wie die Deezer-IDs.
|
||||
- Aufwandsseite unkritisch: eine Anfrage pro Künstler, im Backend gecacht wie die Releases. Bei
|
||||
50 Künstlern und sechs Stunden Haltbarkeit bleibt das weit unter Ticketmasters Tagesgrenze.
|
||||
- **Android** — Playlist drag-and-drop / sort order
|
||||
- **Android** — Artist page iTunes fallback (for artists not in Navidrome)
|
||||
- **Android** — Romaji / Japanese sort support
|
||||
|
||||
Reference in new issue
Block a user