Splync v1.5 umí přizpůsobit poměry rozdělení podle projektu a kategorie
16. září 2025 byla vydána verze Splync v1.5 — jen čtyři dny poté, co naše mezinárodní manželství konečně přijalo město. Před touto aktualizací nebylo možné u Splyncu přizpůsobit poměry rozdělení; každá výdaj byl ve výchozím nastavení rovnoměrně rozdělen. S verzí v1.5 mohou uživatelé nyní nastavit vlastní poměry jak pro projekt, tak pro kategorii. Tato změna umožňuje párům a přátelům rozdělit společné náklady způsobem, který lépe odráží jejich skutečný život, nikoli jen jednoduché 50:50. Můžete zahájit nový účetní projekt s rozdělením 60:40 pro každodenní výdaje od října, přičemž nájem za byt zůstane na férových 50:50, pokud vám to tak vyhovuje. A pokud se vám zdá, že potraviny jsou lépe vyvážené na 70:30, zatímco energie na 62:38, nyní můžete tyto poměry přiřadit zvlášť — kategorie po kategorii — v rámci stejného projektu.
Jak nastavit vlastní poměry
Nejviditelnější změnou v v1.5 je nová sekce Členové a výchozí podíly, kde můžete přidat členy projektu a přiřadit každému výchozí podíl. Pokud má projekt dva členy, poměr může být 50:50, 40:60 nebo jakýkoli jiný, který vám vyhovuje. S třemi členy to může být 33,33:33,33:33,34, 50:25:25 nebo jakákoli kombinace, kterou preferujete. To se stane výchozím poměrem projektu. Níže můžete rolovat, abyste upravili podíl každé kategorie, pokud chcete, aby se lišil od výchozího projektu. Když přiřadíte vlastní poměr kategorii, její modrý označník poměru se změní na oranžový — malý vizuální náznak, že kategorie používá vlastní pravidlo, nikoli to projektové. I když tato změna přidává mnohem větší flexibilitu do nastavení projektu, také činí pohled na vytváření/upravení projektu trochu složitějším. Abych pomohl, přidal jsem informační tlačítka do každé sekce, takže je můžete stisknout a zobrazit malé pomůcky typu Q&A.
Jak Splync implementuje vlastní poměry
Implementace této změny byla složitější, než jsem očekával. Splync vždy předpokládal čistý svět 50:50 — jedno číslo, aplikované všude, a matematika byla hotová. Jakmile jsem se rozhodl podporovat vlastní poměry, musela být celá interní struktura přehodnocena. Projekt se již nemohl spoléhat na jediný sdílený procentní podíl. Každá kategorie potřebovala svůj vlastní poměr a každý výdaj musel odkazovat jak na výchozí projektový poměr, tak na přepis kategorie. Aby to fungovalo, přepsal jsem výpočetní logiku od základů. Každý výdaj nyní nese malé rozhodovací schéma: „Má tato kategorie vlastní poměr? Pokud ano, použijte ho. Pokud ne, vraťte se k poměru projektu.“ Zní to jednoduše, když to vysvětlíte, ale udržet datový model konzistentní v celé aplikaci — iOS pohledy, FastAPI backend, a MariaDB schémata — vyžadovalo pečlivější doladění, než jsem očekával.
Provádění změn na serveru
Jakákoli aktualizace, která se dotýká serverové strany, musí být provedena s mimořádnou opatrností. Pokud náhodně změníte existující kód serveru, uživatelé stále na verzi v1.4 okamžitě narazí na chyby nebo systémové chyby. Například serverový program pro v1.5 očekává, že nastavení projektu budou obsahovat data o poměru, ale aplikace v1.4 posílá nastavení projektu bez jakýchkoli poměrů. V okamžiku, kdy se tyto dvě verze pokusí komunikovat, žádost selže — jednoduše proto, že mluví trochu jiným „jazykem“. Vývojáři samozřejmě mohou bezpečně provádět změny v testovacím prostředí. Obtížná část začíná po odeslání nové verze ke kontrole společnosti Apple, zatímco stávající uživatelé stále používají v1.4. Během celé doby od odeslání do vydání musí server podporovat obě verze současně, aby recenzenti Apple mohli testovat v1.5 a stávající uživatelé mohli pokračovat v používání v1.4 bez přerušení.
Správa endpointů během aktualizací verzí
Ve vývoji aplikací je „endpoint“ jednoduše místem, kam aplikace posílá své požadavky na server — něco jako konkrétní přepážka na radnici. Jedna přepážka řeší registrace manželství, další řeší záznamy obyvatel a další řeší pasy. Aplikace fungují stejně: každý endpoint je vyhrazené okno, kde server přijímá konkrétní typ požadavku jako přihlášení, vytvoření projektu, úprava výdajů, žádost o přátelství atd. Když Splync v1.4 pošle požadavek, jde k „starému“ oknu, které rozumí staršímu formátu. Splync v1.5 pošle svůj požadavek k „novému“ oknu, které rozumí datům o poměru. Pokud by server zavřel staré okno příliš brzy, uživatelé verze v1.4 by neměli kam „odeslat“ svá data. Proto, během aktualizace, server musí udržovat obě okna otevřená — oba endpointy — dokud každý uživatel bezpečně nepřejde na novější verzi. Abych byl upřímný, správa těchto dvou oken současně byla jako přemýšlení v další dimenzi.
A co rozdělení podle jednotlivých výdajů
Splync v1.5 umí přizpůsobit rozdělení podle projektu a kategorie, ale zatím ne podle jednotlivých výdajů. Pro podporu poměrů podle jednotlivých výdajů potřebujeme další strukturální vrstvu — v podstatě hlubší přepis toho, jak každý výdaj uchovává a vypočítává své podíly. Musíme být také opatrní, abychom neudělali uživatelské rozhraní aplikace najednou složitým jen kvůli přidání větší síly. Je to větší upgrade, než to zní. Prosím, dejte nám ještě trochu času, abychom se tam dostali. Je to na našem horizontu — a dosáhneme toho. Do té doby si pojďme prozkoumat, jak nové poměry podle projektu a kategorie už teď činí sdílené výdaje mnohem flexibilnějšími.