Splync v1.5 — પ્રોજેક્ટ અને કેટેગોરી માટે કસ્ટમાઇઝેબલ સ્પ્લિટ રેશિયોઝ

16 સપ્ટેમ્બર, 2025ના રોજ, Splync v1.5 રિલીઝ થયું — અમારા આંતરરાષ્ટ્રીય લગ્નને શહેર દ્વારા મંજૂરી મળ્યાના માત્ર ચાર દિવસ પછી. આ અપડેટ સુધી, Splync સ્પ્લિટ રેશિયોઝ કસ્ટમાઇઝ કરી શકતું ન હતું; દરેક ખર્ચને ડિફોલ્ટ મુજબ સમાન રીતે વહેંચવામાં આવતો હતો. v1.5 સાથે, વપરાશકર્તાઓ હવે પ્રોજેક્ટ અને કેટેગરી દીઠ કસ્ટમ રેશિયોઝ સેટ કરી શકે છે. આ બદલાવ ગોઠવણને વધુ વાસ્તવિક રીતે પ્રતિબિંબિત કરવાની સગવડ આપે છે, માત્ર સરળ 50:50 નહીં. તમે ઓક્ટોબરથી દૈનિક ખર્ચ માટે 60:40 સ્પ્લિટ સાથે નવું એકાઉન્ટિંગ પ્રોજેક્ટ શરૂ કરી શકો છો, જ્યારે તમને યોગ્ય લાગે તો તમારા એપાર્ટમેન્ટ ભાડાને સમાન 50:50 રાખી શકો છો. અને જો કરિયાણું 70:30 અને યૂટીલિટીઝ 62:38 પર વધુ બેલેન્સ્ડ લાગે, તો તમે હવે આ રેશિયોઝને અલગ-અલગ સોંપી શકો છો — કેટેગરી દ્વારા — તે જ પ્રોજેક્ટમાં.

v1.5 માં સૌથી વધુ ઓળખી શકાતો ફેરફાર નવો મેમ્બર અને ડિફોલ્ટ શેર સેકશન છે, જ્યાં તમે પ્રોજેક્ટ મેમ્બર્સ ઉમેરી શકો છો અને દરેક વ્યક્તિને ડિફોલ્ટ શેર આપી શકો છો. જો પ્રોજેક્ટમાં બે સભ્યો હોય, તો અનુપાત 50:50, 40:60, અથવા જે યોગ્ય લાગે તે હોઈ શકે છે. ત્રણ સભ્યો સાથે, તે 33.33:33.33:33.34, 50:25:25, અથવા તમારી પસંદગીની કોઈપણ કોબિનેશન હોઈ શકે છે. આ પ્રોજેક્ટનું ડિફોલ્ટ સ્પ્લિટ બની જાય છે. તે નીચે, તમે સ્ક્રોલ કરી દર કેટેગરીના શેરને એડજસ્ટ કરી શકો છો જો તમને તે પ્રોજેક્ટની ડિફોલ્ટથી અલગ કરવા માંગતા હોય. જ્યારે તમે એક કેટેગરીને કસ્ટમ રેશિયો સોંપો છો, ત્યારે તેની નીળી રેશિયો માર્ક ઓરેન્જ થઈ જાય છે — એક નાની દ્રશ્ય સૂચના કે કેટેગરી તેની પોતાની નિયમનો ઉપયોગ કરી રહી છે, સમગ્ર પ્રોજેક્ટના બદલે. જ્યારે આ ફેરફાર પ્રોજેક્ટ સેટિંગ્સમાં વધુ લવચીકતા ઉમેરશે, ત્યારે તે પ્રોજેક્ટ બનાવવા/સંપાદન દૃશ્યને વધુ જટિલ બનાવે છે. આ માટે, મેં દરેક વિભાગમાં માહિતી બટનો ઉમેર્યા છે જેથી તમે તેમને ટેપ કરી નાનાં Q&A હેલ્પર્સ જોઈ શકો.

આ ફેરફારને લાગુ કરવું મારી અપેક્ષાથી વધુ જટિલ હતું. Splync હંમેશા 50:50 વિશ્વ સ્વીકાર્યું — એક નંબર, દરેક જગ્યાએ લાગુ થતો, અને ગણિત પૂર્ણ થતું. એક વાર મેં કસ્ટમ રેશિયોઝને સપોર્ટ કરવાનો નિર્ણય લીધો, દરેક આંતરિક માળખાને ફરી વિચારવું પડ્યું. હવે પ્રોજેક્ટ એક જ શેયર્ડ ટકા પર આધારિત રહી શકતું નહોતું. દરેક કેટેગરીને તેના પોતાના રેશિયોની જરૂર હતી, અને દરેક ખર્ચને પ્રોજેક્ટ સ્તરની ડિફોલ્ટ અને કેટેગરી સ્તરની ઓવરરાઇડ બંનેને ઉલ્લેખ કરવાની જરૂર હતી. આ કાર્ય કરવા માટે, મેં મૂળભૂત રીતે ગણતરીના વાજબી શુંધારા ફરી લખ્યા. હવે દરેક ખર્ચે નાનું નિર્ણય વૃક્ષ વહન થાય છે: “શું આ કેટેગરી પાસે તેનો પોતાનો રેશિયો છે? જો હા, તો તેનો ઉપયોગ કરો. જો નહીં, તો પ્રોજેક્ટ રેશિયોને પાછા જાઓ.” તમે તેને સમજૂતી આપો ત્યારે તે સરળ લાગે છે, પરંતુ એપ્લિકેશનમાં ડેટા મોડલને એકસરખું રાખવું — iOS દૃશ્યો, FastAPI બેકએન્ડ, અને MariaDB સ્કીમાસમાં — તે વધુ કાળજીપૂર્વક ટ્યુનિંગની જરૂર હતી જેટલી મેં અપેક્ષા રાખી હતી.

કોઈપણ અપડેટ જે સર્વર સાઇડને સ્પર્શે છે તેને ખૂબ કાળજીપૂર્વક સંભાળવું પડે છે. જો તમે અચાનક અસ્તિત્વમાં રહેલા સર્વર કોડમાં ફેરફાર કરો છો, તો v1.4 પર હજી પણ વપરાશકર્તાઓ તરત જ ભૂલો અથવા સિસ્ટમ ભૂલોમાં ચાલશે. ઉદાહરણ તરીકે, v1.5 માટેનો સર્વર પ્રોગ્રામ પ્રોજેક્ટ સેટિંગ્સમાં રેશિયો ડેટાનો સમાવેશ કરી શકે છે તેવી અપેક્ષા રાખે છે, પરંતુ v1.4 એપ્લિકેશન કોઈ રેશિયો વિના પ્રોજેક્ટ સેટિંગ્સ મોકલે છે. જ્યારે આ બે સંસ્કરણો વાત કરવાની કોશિશ કરે છે, તો વિનંતી નિષ્ફળ થાય છે — માત્ર કારણ કે તેઓ થોડા અલગ “ભાષાઓ” બોલે છે. ડેવલપરો ચોક્કસપણે ટેસ્ટ એન્વાયરમેન્ટમાં સુરક્ષિત રીતે ફેરફારો કરી શકે છે. મુશ્કેલ ભાગ એ પછી શરૂ થાય છે જ્યારે એપલના સમીક્ષામાં નવી સંસ્કરણને સબમિટ કરવામાં આવે છે જ્યારે અસ્તિત્વમાં રહેલા વપરાશકર્તાઓ હજી v1.4 પર હોય છે. સબમિશનથી રિલીઝ સુધીની સંપૂર્ણ સમયગાળા દરમિયાન, સર્વરે બંને સંસ્કરણોને એકસાથે સપોર્ટ કરવું જોઈએ જેથી કે એપલ સમીક્ષક v1.5 ને પરીક્ષણ કરી શકે અને અસ્તિત્વમાં રહેલા વપરાશકર્તાઓ કોઈ વિક્ષેપ વિના v1.4 નો ઉપયોગ ચાલુ રાખી શકે.

એપ્લિકેશન વિકાસમાં, “એન્ડપોઈન્ટ” એ પાત્ર છે જ્યાં એપ્લિકેશન તેના સર્વર પર વિનંતીઓને મોકલે છે — થોડીક શહેરના હોલમાં ચોક્કસ કાઉન્ટર જેવી. એક કાઉન્ટર લગ્ન નોંધણી સંભાળે છે, બીજું નિવાસી રેકોર્ડસને સંભાળે છે, અને બીજું પાસપોર્ટસને. એપ્લિકેશનો પણ તે જ રીતે કામ કરે છે: દરેક એન્ડપોઈન્ટ એ સમર્પિત ઝરુખો છે જ્યાં સર્વર વિશિષ્ટ પ્રકારની વિનંતી સ્વીકારતું છે જેમ કે લોગિન, પ્રોજેક્ટ રચના, ખર્ચ સંપાદન, મિત્ર વિનંતી, વગેરે. જ્યારે Splync v1.4 વિનંતી મોકલે છે, ત્યારે તે “જૂના” ઝરુખે જતું છે જે જૂના ફોર્મેટને સમજતું છે. Splync v1.5 તેની વિનંતી “નવા” ઝરુખે મોકલે છે જે રેશિયો ડેટાને સમજતું છે. જો સર્વરે જૂના ઝરુખને જલદી બંધ કરી નાખ્યું હોય, તો v1.4 વપરાશકર્તાઓનો ડેટા “સબમિટ” કરવાની જગ્યાએ ક્યાંય નહીં હોય. આ કારણે, અપડેટ દરમિયાન, સર્વરે બંને ઝરુખોને ખુલ્લું રાખવું પડે છે — બંને એન્ડપોઈન્ટ્સ — જ્યાં સુધી દરેક વપરાશકર્તા સુરક્ષિત રીતે નવા સંસ્કરણમાં ન જાય. સત્ય કહેવું, આ બે ઝરુખને એકસાથે મેનેજ કરવું એ વધારાના પરિમાણમાં વિચારવું લાગતું હતું.

Splync v1.5 પ્રોજેક્ટ અને કેટેગરી દીઠ સ્પ્લિટ કસ્ટમાઇઝ કરી શકે છે, પરંતુ હજી સુધી પ્રતિ-ખર્ચ માટે નહીં. પ્રતિ-ખર્ચ રેશિયોઝને સપોર્ટ કરવા માટે, આપણને બીજું માળખાકીય સ્તર જોઈએ છે — મૂળભૂત રીતે દરેક ખર્ચનો શેર કેવી રીતે સંગ્રહાય છે અને ગણતરી થાય છે તેની વધુ ઊંડાઈથી પુનર્લેખન. આપણે એપ્લિકેશનના ઇન્ટરફેસને અચાનક જટિલ ન કરવા માટે પણ સાવધાન રહેવું પડશે માત્ર વધુ શક્તિ ઉમેરવા માટે. તે સાંભળવાથી મોટા અપગ્રેડ છે. કૃપા કરીને અમને ત્યાં પહોંચવા માટે થોડો વધુ સમય આપો. તે અમારી હોરાઈઝન પર છે — અને અમે ત્યાં પહોંચીશું. ત્યારે સુધી, નવા પ્રતિ-પ્રોજેક્ટ અને પ્રતિ-કેંગરી રેશિયોઝ કેવી રીતે શેર ખર્ચોને વધુ લવચીક બનાવે છે તે શોધીએ.