Splync v1.9 kann benutzerdefinierte Teilungsverhältnisse für jede Ausgabe festlegen

Etwa anderthalb Monate nach der Veröffentlichung von Splync v1.5 – dem Update, das endlich benutzerdefinierte Teilungsverhältnisse pro Projekt und Kategorie ermöglichte – erreichte uns eine neue Welle von Feedback. Das v1.5-Update erforderte umfangreiche serverseitige Änderungen, daher glaubte ich zu dieser Zeit, dass die Detailgenauigkeit für die meisten Anwendungsfälle „ausreichend gut“ sei. Dann stellten einige neue Benutzer eine einfache, sehr vernünftige Frage: „Können wir benutzerdefinierte Teilungsverhältnisse für einzelne Ausgaben festlegen?“ Ihr Reiseprojekt hatte Momente, in denen nur zwei Mitglieder eine bestimmte Kosten tragen mussten, und andere Momente, in denen alle drei etwas teilen wollten. Unter Splync v1.8 war die Antwort leider nein. Ich erklärte, dass sie zusätzliche Kategorien mit angepassten Verhältnissen für diese speziellen Fälle erstellen könnten – ein Workaround, aber keine echte Lösung.

Es war etwas überwältigend, sich daran zu erinnern, wie viel Arbeit in v1.5 steckte. Zuerst musste ich Projekten ihre eigenen Teilungsverhältnisse zuweisen. Dann brauchten auch Kategorien ihre eigenen benutzerdefinierten Verhältnisse. Zu diesem Zeitpunkt dachte ich, ich hätte den ganzen Baum abgedeckt – jede Frucht von jedem Ast gesammelt. Doch an den Verhältnissen pro Ausgabe zu arbeiten, war anders. Es fühlte sich an, als würde jedes Mal, wenn ich eine Frucht pflückte, ein neuer Baum an dieser Stelle sprießen. Kein unendlicher Fraktalwald, aber eine klare zweistöckige Struktur: eine Ebene, die die nächste hervorbringt. In der v1.5-Logik erbte eine Ausgabe zunächst das Verhältnis des Projekts. Wenn seine Kategorie benutzerdefinierte Verhältnisse hatte, überschrieben diese die Projektwerte. Also versuchte ich, als ich die Verhältnisse pro Ausgabe hinzufügte, eine weitere Überschreibung über dieser Überschreibung hinzuzufügen. Die Struktur wurde zu einer Treppe von Überschreibungen – technisch korrekt, aber mental unübersichtlich. Es war schwer zu rechtfertigen, eine weitere Schicht von Flickwerk-Logik aufzubauen.

Der Durchbruch kam schließlich, als ich die Struktur umdrehte. Anstatt „Projekt → Kategorie → Ausgabe“ zu machen und jede Ebene mit der nächsten zu überschreiben, warum nicht in die andere Richtung denken? Per-Ausgabe-Anteile → Per-Kategorie-Anteile → Per-Projekt-Anteile. Diese Reihenfolge spiegelt wider, wie echte Menschen denken könnten: Wenn eine bestimmte Ausgabe ihre eigenen Regeln hat, sollte sie diesen einfach folgen. Wenn nicht, macht das Muster der Kategorie Sinn. Wenn auch das nicht passt, fällt man auf den Projektstandard zurück. Keine Treppe von Überschreibungen mehr – nur eine klare Hierarchie der Priorität. Sobald ich die Struktur auf diese Weise sah, lichtete sich der Nebel des Pseudo-Fraktalwaldes sofort. Der Implementierungspfad wurde offensichtlich: „Jede Ausgabe wird auf benutzerdefinierte Anteile pro Ausgabe überprüft. Wenn vorhanden, benutze sie. Wenn nicht, überprüfe die Anteile pro Kategorie. Wenn nicht, benutze den Projektstandard.“

Die neue Logik fühlte sich einfach, vorhersehbar und mathematisch solide an. Um dieses Prioritätssystem zu unterstützen, haben wir eine eigene MariaDB-Tabelle für Teilungen pro Ausgabe hinzugefügt, die der Tabelle für Teilungen pro Kategorie ähnelt. Auch die Ausgabendetails-Tabelle musste erweitert werden, genau wie die Kategoriedetails-Tabelle in v1.5. Sobald das zugrunde liegende „zweistöckige“ Design klar wurde, bestand der Rest aus sorgfältiger Codierung – sowohl in der App als auch auf dem Server. Dennoch fühlte sich der Weg an manchen Stellen riskant an, wie das Gehen durch einen dunklen Wald ohne Karte. Ich wollte meinen Kopf frei bekommen und trat nach draußen. Die Luft war scharf und klar. Während ich durch meine Nachbarschaft spazierte, sah ich den Fuji in der Ferne aufragen, kristallblau unter einem perfekt blauen Himmel. Er war fast 100 km entfernt und wirkte doch nah genug, um ihn zu berühren. Der Moment fühlte sich an wie eine Erinnerung: Selbst wenn ich denke, ich gehe in einem Wald, gehe ich tatsächlich unter freiem Himmel.

Splync v1.9 entstand aus diesem Moment der Klarheit. Ich kam nach Hause, schloss die neuen Endpunkte ab, bereitete die neue Serverlogik vor, organisierte die zugehörigen Schnittstellen, reichte v1.9 bei Apple ein und fiel schließlich in den Schlaf. Die Überprüfung war früher als üblich abgeschlossen. Als ich aufwachte, war Splync v1.9 bereits genehmigt und automatisch im App Store veröffentlicht worden. Ab dieser Version wird das Teilen wesentlich flexibler. Wenn Sie mit John und Kate reisen, können Sie grundlegende Ausgaben gleichmäßig unter Ihnen dreien aufteilen. Bei Lebensmitteln könnten Sie jedoch auf eine „25 % : 50 % : 25 %“-Aufteilung umschalten, da John normalerweise doppelt so viel isst. Und wenn John ein Abendessen auslässt – sagen wir, in einem Austernrestaurant – können Sie diese spezielle Mahlzeit auf „50 % : 0 % : 50 %“ einstellen, damit er nicht für etwas bezahlt, das er nicht gegessen hat. Mit v1.9 unterstützt Splync nun Projekte, Kategorien und Ausgaben mit benutzerdefinierten Verhältnissen in einer einheitlichen Logik. Die Grundlagen sind stabil und mathematisch fundiert. Die nächste Herausforderung ist die Benutzeroberfläche: Einige andere Apps zum Teilen bieten reibungslosere, stilvollere Möglichkeiten, diese Verhältnisse anzupassen. Splync hat jetzt die Backend-Stärke, um solche Verbesserungen zu unterstützen. Wir werden sie nacheinander angehen.