Splync v1.5 — Mga Naaangkop na Paghahati ng Ratio bawat Proyekto at Kategorya

Noong Setyembre 16, 2025, inilabas ang Splync v1.5 — apat na araw lamang matapos tanggapin ng lungsod ang aming internasyonal na kasal. Bago ang update na ito, hindi kayang i-customize ng Splync ang mga ratio ng hati; lahat ng gastos ay pantay na hinahati bilang default. Sa v1.5, maaring magtakda ng mga custom ratio ang mga gumagamit bawat proyekto at kategorya. Ang pagbabagong ito ay nagpapahintulot sa mga mag-asawa at kaibigan na hatiin ang kanilang pinagsasaluhang gastos sa mga paraang mas akma sa kanilang tunay na buhay, hindi lang isang simpleng 50:50. Maaari kang magsimula ng bagong accounting project na may 60:40 na hati para sa pang-araw-araw na gastusin mula Oktubre, habang pinapanatili ang upa ng apartment sa pantay na 50:50 kung iyon ay patas para sa inyo. At kung sa tingin mo ay mas balanse ang grocery sa 70:30 habang ang utilities ay mas magandang nasa 62:38, maari mo nang italaga ang mga ratio na iyon nang magkahiwalay — kategorya bawat kategorya — sa loob ng parehong proyekto.

Ang pinakapansin-pansing pagbabago sa v1.5 ay ang bagong seksyon ng Member & Default Shares, kung saan maaari kang magdagdag ng mga miyembro ng proyekto at magtalaga sa bawat tao ng default na bahagi. Kung ang proyekto ay may dalawang miyembro, maaaring 50:50, 40:60, o anumang nararamdaman mong tama ang ratio. Kung tatlong miyembro, maaaring 33.33:33.33:33.34, 50:25:25, o anumang kumbinasyon na gusto mo. Ito ang magiging default na hati ng proyekto. Sa ibaba nito, maaari kang mag-scroll pababa para ayusin ang parte ng bawat kategorya kung nais mong ito ay magkaiba sa default ng proyekto. Kapag nagtalaga ka ng custom ratio sa isang kategorya, ang asul na marka ng ratio nito ay nagiging kulay kahel — isang maliit na palatandaan na ang kategoryang iyon ay gumagamit ng sarili nitong patakaran sa halip na ang pangkalahatang proyekto. Bagamat ang pagbabagong ito ay nagdadagdag ng higit na kakayahang umangkop sa mga setting ng proyekto, ito rin ay nagpapakumplikado sa paglikha/pag-edit ng view ng proyekto. Upang makatulong dito, nagdagdag ako ng mga information button sa bawat seksyon para maaari mong i-tap ito upang makita ang maliliit na Q&A helpers.

Ang pagpapatupad ng pagbabagong ito ay mas kumplikado kaysa sa inaasahan ko. Laging inaakala ng Splync ang isang malinis na mundong 50:50 — isang numero, inilalapat kahit saan, tapos ang matematika. Sa sandaling nagpasya akong suportahan ang mga custom ratio, kailangang muling isipin ang buong internal na istruktura. Hindi na maaring umasa ang isang proyekto sa isang shared percentage. Bawat kategorya ay nangangailangan ng sariling ratio, at bawat gastusin ay kailangang i-refer sa parehong project-level default at category-level override. Upang magawa ito, muling isinulat ko ang calculation logic mula sa pundasyon. Ang bawat gastusin ngayon ay may dalang maliit na decision tree: "May sariling ratio ba ang kategoryang ito? Kung oo, gamitin iyon. Kung hindi, bumalik sa project ratio." Mukhang simple ito kapag ipinaliwanag mo, ngunit ang pagpapanatiling pare-pareho ng data model sa buong app — iOS views, FastAPI backend, at MariaDB schemas — ay nangangailangan ng mas maingat na pag-tune kaysa sa inaasahan ko.

Ang anumang update na humahawak sa server side ay kailangang pag-ingatan. Kung aksidenteng mabago mo ang umiiral na server code, ang mga gumagamit pa rin ng v1.4 ay agad na makakaranas ng bugs o system errors. Halimbawa, ang server program para sa v1.5 ay inaasahan ang mga setting ng proyekto na kasama ang ratio data, ngunit ang v1.4 app ay nagpapadala ng mga setting ng proyekto na walang ratio. Sa sandaling subukan ng dalawang bersyon na makipag-usap, nabibigo ang request — dahil lang sa bahagyang magkaibang "wika" ang ginagamit nila. Ang mga developer ay maaaring, siyempre, gumawa ng mga pagbabago nang ligtas sa isang test environment. Ang mahirap na bahagi ay nagsisimula pagkatapos isumite ang bagong bersyon para sa pagsusuri ng Apple habang ang mga umiiral na gumagamit ay nasa v1.4 pa rin. Sa buong panahon mula pagsusumite hanggang paglabas, kailangan ng server na suportahan ang parehong bersyon sa parehong oras upang ang mga reviewer ng Apple ay masubukan ang v1.5 at ang umiiral na mga gumagamit ay maipagpatuloy ang paggamit ng v1.4 nang walang aberya.

Sa pag-develop ng app, ang "endpoint" ay simpleng lugar kung saan ang app ay nagpapadala ng mga requests sa server — parang specific counter sa city hall. Isang counter ang humahawak ng marriage registrations, isa pa ang humahawak ng resident records, at isa pa ang humahawak ng passports. Ganoon din ang apps: bawat endpoint ay isang dedikadong window kung saan tinatanggap ng server ang isang uri ng request gaya ng login, paglikha ng proyekto, pag-edit ng gastusin, friend request, atbp. Kapag ang Splync v1.4 ay nagpadala ng request, ito ay pumunta sa "luma" na window na nakakaintindi ng lumang format. Ang Splync v1.5 ay nagpapadala ng request nito sa "bagong" window na nakakaintindi ng ratio data. Kung ang server ay isinara ang lumang window nang maaga, ang mga gumagamit ng v1.4 ay wala nang mapaglalagyan ng kanilang data. Kaya't sa panahon ng pag-update, kailangan ng server na panatilihing bukas ang parehong mga window — parehong endpoints — hanggang sa ligtas na lumipat ang bawat gumagamit sa mas bagong bersyon. Sa totoo lang, ang pamamahala ng dalawang window nang sabay ay parang pag-iisip sa isang dagdag na dimensyon.

Ang Splync v1.5 ay kayang i-customize ang mga hati bawat proyekto at kategorya, ngunit hindi pa bawat gastusin. Upang suportahan ang per-expense ratios, kailangan natin ng isa pang structural layer — karaniwang isang mas malalim na pagsulat kung paano iniimbak at kinakalkula ng bawat gastusin ang kanyang bahagi. Kailangan din nating maging maingat na hindi gawing biglang kumplikado ang interface ng app para lamang magdagdag ng higit pang kapangyarihan. Mas malaking upgrade ito kaysa sa akala. Pakibigyan kami ng kaunting oras upang makarating doon. Nasa abot-tanaw namin ito — at maaabot namin ito. Hanggang doon, tuklasin natin kung paano ang bagong mga ratio na per-proyekto at per-kategorya ay nagpapadali na sa mga pinagsasaluhang gastos.