Halo heisst ab hier Flaro — die Marke stand im Weg
Der Upload zu App Store Connect scheiterte am Namen. „Halo" ist eine eingetragene Marke von Microsoft; im App Store heisst zwar keine App exakt so, aber reservierte und markenrechtlich belegte Namen tauchen in keiner Suche auf. Der einzige verlässliche Test war die Eingabe dort, und die ging daneben. **Der Name wurde diesmal vorher geprüft.** Zwanzig Kandidaten gegen den deutschen und amerikanischen App Store, auf exakte Treffer und auf ähnliche Namen. „Kavo" wäre dieselbe Wand gewesen — exakt belegt in beiden Stores, in Deutschland von KaVo Dental GmbH. „Flare" ist mit 42 ähnlichen Apps je Store der am dichtesten besetzte Name der ganzen Runde. **Flaro** ist in beiden frei und liest sich als eigenes Wort, nicht als Flare mit Tippfehler. Das bleibt eine Store-Suche und keine Markenrecherche — reservierte Namen ohne veröffentlichte App sieht sie nicht. Aber es ist mehr Prüfung, als beim letzten Mal stattfand. --- 2160 Textvorkommen in 273 Dateien, 49 Pfade. Betroffen ist diesmal auch der Server: `Flaro.Api`, `Flaro.Core`, `Flaro.Data`, `Flaro.Media`, `Flaro.Metadata`, `FlaroContext`, `FlaroPaths`, `flaro.db`, die Variablen `FLARO_DATA`, `FLARO_CACHE`, `FLARO_TRANSCODE`, `FLARO_WRITE_SIDECARS`, und das Image. **Vor dem Ersetzen geprüft**, ob „halo" irgendwo als Teil eines anderen Wortes steckt — und ob es im TMDB-Token vorkommt. Tat es nicht; ein blindes Ersetzen hätte den sonst zerlegt. `docs/superpowers/specs/` bleibt wie beim letzten Mal unangetastet: datierte Entwurfsdokumente sind ein Protokoll getroffener Entscheidungen. Das Server-Dokument hat stattdessen einen Nachtrag bekommen, damit es niemanden in die Irre führt. **Die Bundle-ID wandert mit**, zum zweiten Mal an einem Tag: `com.scarriffleservices.flaro`. Wer die vorige Fassung installiert hat, hat jetzt zwei Karteileichen auf dem Gerät — beide löschen, dann ist Ruhe. 308 Server-Tests grün, 368 im Swift-Paket, null Warnungen. iOS und tvOS bauen, das Image baut, und ein frischer Container läuft durch Einrichtung und Anmeldung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
f98b995050
commit
a7cf6c5def
@@ -0,0 +1,72 @@
|
||||
import Foundation
|
||||
|
||||
/// Etwas, das der Nutzer ausblenden und verschieben kann.
|
||||
public protocol Arrangeable {
|
||||
/// Eine Kennung, die über Abrufe hinweg gleich bleibt.
|
||||
///
|
||||
/// **Nicht** der angezeigte Titel: benennt der Server eine Reihe oder eine
|
||||
/// Mediathek um, wäre sonst alles Gespeicherte hinfällig.
|
||||
var arrangementID: String { get }
|
||||
var arrangementTitle: String { get }
|
||||
}
|
||||
|
||||
/// Was ausgeblendet ist und in welcher Reihenfolge der Rest steht.
|
||||
///
|
||||
/// War bis eben an die Startseiten-Reihen von Plex gebunden. Die Rechnung ist
|
||||
/// dieselbe für jede Liste, die jemand selbst zusammenstellt — Reihen,
|
||||
/// Seitenleisteneinträge, Sender. Sie ein zweites Mal zu schreiben hieße, sie
|
||||
/// ein zweites Mal falsch zu machen.
|
||||
public struct Arrangement: Sendable, Equatable {
|
||||
public var hidden: Set<String>
|
||||
public var order: [String]
|
||||
|
||||
public init(hidden: Set<String> = [], order: [String] = []) {
|
||||
self.hidden = hidden
|
||||
self.order = order
|
||||
}
|
||||
|
||||
/// Wendet Auswahl und Reihenfolge an.
|
||||
///
|
||||
/// Unbekannte Einträge landen am Ende statt zu verschwinden. Sie zu
|
||||
/// verwerfen wäre die einfachere Regel — und der Grund dafür, dass ein
|
||||
/// neu angelegtes Regal auf dem Server in der App nie aufgetaucht wäre.
|
||||
public func apply<Element: Arrangeable>(to elements: [Element]) -> [Element] {
|
||||
let visible = elements.filter { !hidden.contains($0.arrangementID) }
|
||||
guard !order.isEmpty else { return visible }
|
||||
|
||||
let positions = Dictionary(
|
||||
order.enumerated().map { ($1, $0) },
|
||||
// Ein doppelter Eintrag in der gespeicherten Reihenfolge — etwa
|
||||
// nach einem fehlgeschlagenen Schreibvorgang — soll nicht
|
||||
// abstürzen. Die erste Position gewinnt.
|
||||
uniquingKeysWith: { first, _ in first }
|
||||
)
|
||||
|
||||
return visible.enumerated().sorted { left, right in
|
||||
let leftPosition = positions[left.element.arrangementID] ?? Int.max
|
||||
let rightPosition = positions[right.element.arrangementID] ?? Int.max
|
||||
// Bei gleicher Position — beide unbekannt — bleibt die Reihenfolge
|
||||
// des Servers erhalten. Ohne diese Rückfalllinie wäre die
|
||||
// Anordnung neuer Einträge zufällig.
|
||||
if leftPosition == rightPosition { return left.offset < right.offset }
|
||||
return leftPosition < rightPosition
|
||||
}.map(\.element)
|
||||
}
|
||||
|
||||
/// Die Liste für den Einstellungsbildschirm: gespeicherte Reihenfolge
|
||||
/// zuerst, danach alles Übrige.
|
||||
///
|
||||
/// Gespeicherte Einträge, die es nicht mehr gibt, fallen heraus — sie
|
||||
/// anzuzeigen hieße, eine Reihe anzubieten, die niemand mehr hat.
|
||||
public func arrangedIdentifiers<Element: Arrangeable>(from elements: [Element]) -> [String] {
|
||||
let available = elements.map(\.arrangementID)
|
||||
let known = Set(available)
|
||||
let stored = order.filter(known.contains)
|
||||
return stored + available.filter { !stored.contains($0) }
|
||||
}
|
||||
}
|
||||
|
||||
extension MediaRowGroup: Arrangeable {
|
||||
public var arrangementID: String { id }
|
||||
public var arrangementTitle: String { title }
|
||||
}
|
||||
Reference in New Issue
Block a user