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 ऐप किसी भी अनुपात के बिना प्रोजेक्ट सेटिंग्स भेजता है। जैसे ही ये दो संस्करण संचार करने का प्रयास करते हैं, अनुरोध विफल हो जाता है — केवल इसलिए कि वे थोड़ी भिन्न “भाषाओं” में बात करते हैं। डेवलपर्स निश्चित रूप से एक परीक्षण पर्यावरण में सुरक्षित रूप से बदलाव कर सकते हैं। कठिनाई तब शुरू होती है जब एक नया संस्करण Apple की समीक्षा के लिए जमा किया जा रहा होता है जबकि मौजूदा उपयोगकर्ता अभी भी v1.4 पर हैं। सबमिशन से रिलीज तक की पूरी अवधि के दौरान, सर्वर को दोनों संस्करणों का एक ही समय में समर्थन करना चाहिए ताकि Apple समीक्षक v1.5 का परीक्षण कर सकें और मौजूदा उपयोगकर्ता v1.4 का उपयोग जारी रख सकें।

ऐप विकास में, एक “एंडपॉइंट” बस वह जगह होती है जहाँ ऐप सर्वर पर अपनी अनुरोध भेजता है — जैसे कि शहर के हॉल में एक विशेष काउंटर। एक काउंटर विवाह पंजीकरण संभालता है, दूसरा निवासी रिकॉर्ड, और एक अन्य पासपोर्ट। ऐप्स उसी तरह काम करते हैं: प्रत्येक एंडपॉइंट एक समर्पित विंडो होती है जहाँ सर्वर एक विशेष प्रकार का अनुरोध स्वीकार करता है जैसे कि लॉगिन, प्रोजेक्ट निर्माण, खर्च संपादन, दोस्त अनुरोध आदि। जब Splync v1.4 एक अनुरोध भेजता है, तो यह “पुरानी” विंडो में जाता है जो पुराने प्रारूप को समझता है। Splync v1.5 अपनी अनुरोध एक “नई” विंडो में भेजता है जो अनुपात डेटा को समझती है। यदि सर्वर ने पुरानी विंडो को बहुत जल्दी बंद कर दिया, तो v1.4 उपयोगकर्ताओं के पास अपना डेटा “सबमिट” करने के लिए कोई जगह नहीं होगी। इसीलिए, एक अपडेट के दौरान, सर्वर को दोनों विंडो — दोनों एंडपॉइंट्स — को तब तक खुला रखना चाहिए जब तक कि हर उपयोगकर्ता सुरक्षित रूप से नए संस्करण में स्थानांतरित नहीं हो जाता। सच कहूँ तो, इन दोनों विंडोज को एक ही समय में प्रबंधित करना अतिरिक्त आयाम में सोचने जैसा महसूस हुआ।

Splync v1.5 प्रति प्रोजेक्ट और श्रेणी विभाजन को कस्टमाइज कर सकता है, लेकिन अभी तक प्रति खर्च नहीं। प्रति-खर्च अनुपात का समर्थन करने के लिए, हमें एक और संरचनात्मक परत की आवश्यकता है — मूल रूप से प्रत्येक खर्च कैसे अपने शेयर संग्रहीत करता है और गणना करता है इसका गहन पुनर्लेखन। इसके अलावा, हमें यह भी ध्यान रखना होगा कि केवल अधिक शक्ति जोड़ने के लिए ऐप का इंटरफ़ेस अचानक जटिल न हो जाए। यह सुनने में जितना लगता है उससे बड़ा अपग्रेड है। कृपया हमें वहाँ पहुँचने के लिए थोड़ा और समय दें। यह हमारे क्षितिज पर है — और हम इसे प्राप्त करेंगे। तब तक, आइए देखें कि नई प्रति-प्रोजेक्ट और प्रति-श्रेणी अनुपात पहले से ही साझा खर्चों को कितना अधिक लचीला बना रहे हैं।