Splync v1.5 — Testreszabható megosztási arányok projektenként és kategóriánként

2025. szeptember 16-án megjelent a Splync v1.5 – alig négy nappal azután, hogy nemzetközi házasságunkat végre elfogadta a város. Eddig a frissítésig a Splync nem tudott megosztási arányokat testreszabni; minden költség alapértelmezetten egyenlően volt osztva. Az 1.5-ös verzióval a felhasználók most már megadhatják az arányokat projektenként és kategóriánként is. Ez a változás lehetővé teszi a pároknak és barátoknak, hogy úgy osszák meg közös költségeiket, ahogy az a valós életben jobban tükrözi őket, nem csak egy egyszerű 50:50. Októbertől elindíthatsz egy új számviteli projektet napi költségekre 60:40 megosztással, miközben lakásbérletedet egyenlő 50:50 arányban tartod, ha az mindkettőtöknek igazságosnak tűnik. És ha az élelmiszerek 70:30, míg a közüzemi számlák 62:38 arányban kiegyensúlyozottabbnak hatnak, most már külön-külön rendelheted hozzá ezeket az arányokat — kategóriánként — ugyanazon projekten belül.

A legszembetűnőbb változás az 1.5-ös verzióban az új Tagok és Alapértelmezett Részek szekció, ahol felveheted a projekt tagjait és mindenkinek hozzárendelhetsz egy alapértelmezett részt. Ha egy projektnek két tagja van, az arány lehet 50:50, 40:60, vagy ami jónak tűnik. Három tag esetén lehet 33.33:33.33:33.34, 50:25:25, vagy bármilyen kombináció, amit preferálsz. Ez lesz a projekt alapértelmezett megosztása. Alatta lejjebb görgethetsz, hogy minden kategória részesedését külön beállíthasd, ha az eltér a projekt alapértelmezettjétől. Amikor egy kategóriának egyedi arányt rendelsz hozzá, annak kék arányjelzője narancssárgára változik — egy kis vizuális jele annak, hogy a kategória saját szabályt használ a projekt általános helyett. Míg ez a változás sokkal nagyobb rugalmasságot ad a projektbeállításokhoz, egyúttal bonyolultabbá teszi a projekt létrehozás/szerkesztés nézetet. Ehhez minden szekcióhoz információs gombokat adtam, hogy rákattintva kisméretű Q&A segédleteket láthass.

Ennek a változásnak a megvalósítása bonyolultabb volt, mint vártam. A Splync mindig is egy tiszta 50:50 világot feltételezett — egy szám, ami mindenhol alkalmazva és a számítás kész. Amint eldöntöttem egyedi arányok támogatását, az egész belső struktúrát újra kellett gondolni. Egy projekt nem támaszkodhatott többé egyetlen közös százalékra. Minden kategóriának szüksége volt saját arányra, és minden költségnek hivatkoznia kellett mind a projektszintű alapértelmezettre, mind a kategóriaszintű felülírásra. Hogy ez működjön, újraírtam a számítási logikát az alapoktól. Minden költség most egy kis döntési fát hordoz: „Van-e ennek a kategóriának saját aránya? Ha igen, használd azt. Ha nem, térj vissza a projekt arányához.” Egyszerűen hangzik, ha elmagyarázod, de az adatszerkezet következetességének fenntartása az alkalmazás különböző részein — iOS nézetek, FastAPI backend és MariaDB sémák — több gondos hangolást igényelt, mint vártam.

Bármilyen frissítés, ami a szerveroldalt érinti, rendkívüli óvatossággal kell kezelni. Ha véletlenül módosítod a meglévő szerverkódot, a még 1.4-es verziót használó felhasználók azonnal hibákba vagy rendszerhibákba ütközhetnek. Például az 1.5-ös verzió szerverprogramja elvárja, hogy a projektbeállítások tartalmazzanak arányadatokat, de az 1.4-es alkalmazás arányok nélkül küldi el a projektbeállításokat. Abban a pillanatban, amikor a két verzió megpróbál kommunikálni, a kérés meghiúsul — egyszerűen azért, mert kissé eltérő „nyelvet” beszélnek. A fejlesztők természetesen biztonságosan végezhetnek változtatásokat tesztkörnyezetben. A trükkös rész azután kezdődik, hogy benyújtottak egy új verziót az Apple felülvizsgálatához, miközben a meglévő felhasználók még mindig az 1.4-es verziót használják. A benyújtástól a kiadásig terjedő teljes időszak alatt a szervernek egyszerre kell támogatnia mindkét verziót, hogy az Apple ellenőrei tesztelhessék az 1.5-öst, és a meglévő felhasználók zavartalanul folytathassák az 1.4 használatát.

Az alkalmazásfejlesztésben egy „végpont” egyszerűen az a hely, ahová az alkalmazás küldi a kéréseit a szerverre — kicsit mint egy adott ablak a városházán. Egy ablak a házassági bejegyzéseket kezeli, egy másik a lakosnyilvántartásokat, és egy harmadik az útleveleket. Az alkalmazások ugyanígy működnek: minden végpont egy dedikált ablak, ahol a szerver egy adott típusú kérelmet fogad, mint például bejelentkezés, projektlétrehozás, költségszerkesztés, barátkérelem stb. Amikor a Splync v1.4 küld egy kérést, az a „régi” ablakhoz megy, amely a régi formátumot érti. A Splync v1.5 a „új” ablakhoz küldi a kérését, amely az arányadatokat érti. Ha a szerver túl korán bezárja a régi ablakot, a v1.4 felhasználóknak nem lenne hová benyújtani az adataikat. Ezért kell a szervernek a frissítés során mindkét ablakot nyitva tartania — mindkét végpontot —, amíg minden felhasználó biztonságosan át nem tér az újabb verzióra. Őszintén szólva, ennek a két ablaknak az egyidejű kezelése olyan volt, mint egy extra dimenzióban gondolkodni.

A Splync v1.5 lehetővé teszi a projektenkénti és kategóriánkénti megosztásokat, de költségenként még nem. A költségenkénti arányok támogatásához szükségünk van egy újabb szerkezeti rétegre — gyakorlatilag mélyebben át kell írni, hogyan tárolja és számítja ki az egyes költségeket. Arra is ügyelnünk kell, hogy az alkalmazás felülete ne váljon hirtelen bonyolulttá csak azért, hogy több erőt adjunk hozzá. Nagyobb frissítés, mint amilyennek hangzik. Kérjük, adj nekünk még egy kis időt, hogy elérjük. Látóhatáron van — és elérjük. Addig is nézzük meg, hogyan teszik a projektenkénti és kategóriánkénti új arányok már most sokkal rugalmasabbá a közös költségeket.