IOS पर ऑफलाइन मोड और दायरे पर इसके कार्यान्वयन की विशेषताएं

Ekaterina Semashko, मजबूत जूनियर iOS डेवलपर, DataArt द्वारा पोस्ट किया गया

परियोजना के बारे में थोड़ा: आईओएस प्लेटफॉर्म के लिए एक मोबाइल एप्लिकेशन, जो स्विफ्ट में लिखा गया है। आवेदन का उद्देश्य कंपनी के कर्मचारियों और उनके दोस्तों के बीच डिस्काउंट कार्ड साझा करने की क्षमता है।

परियोजना का एक लक्ष्य लोकप्रिय तकनीकों और पुस्तकालयों को सीखना और उनका अभ्यास करना था। Realm को स्थानीय डेटा संग्रहीत करने के लिए चुना गया था, सर्वर के साथ काम करने के लिए Alamofire का उपयोग किया गया था, Google साइन-इन का उपयोग प्रमाणीकरण के लिए किया गया था, PINRemoteImage का उपयोग छवि अपलोड के लिए किया गया था।

आवेदन के मुख्य कार्य:

• एक नक्शा जोड़ना, संपादन करना और उसे हटाना;
• अन्य लोगों के कार्ड देखना;
• स्टोर के नाम / उपयोगकर्ता नाम से कार्ड की खोज;
• त्वरित पहुँच के लिए अपने पसंदीदा में कार्ड जोड़ें।

नेटवर्क से कनेक्ट किए बिना एप्लिकेशन का उपयोग करने की क्षमता शुरुआत से ही मान ली गई थी, लेकिन केवल पढ़ने के तरीके में। यानी हम कार्ड के बारे में जानकारी देख सकते हैं, लेकिन इंटरनेट के बिना उन्हें संशोधित नहीं कर सकते। इसके लिए, आवेदन में हमेशा सर्वर से डेटाबेस के सभी कार्ड और ब्रांडों की एक प्रति होती है, साथ ही वर्तमान उपयोगकर्ता के लिए पसंदीदा सूची भी होती है। खोज को स्थानीय स्तर पर भी लागू किया गया था।

बाद में हमने रिकॉर्डिंग मोड जोड़कर ऑफ़लाइन विस्तार करने का निर्णय लिया। इंटरनेट कनेक्शन दिखाई देने पर उपयोगकर्ता द्वारा किए गए परिवर्तनों के बारे में जानकारी संग्रहीत और सिंक्रनाइज़ की गई थी। इस तरह के पढ़ने-लिखने के ऑफ़लाइन मोड के कार्यान्वयन पर चर्चा की जाएगी।

---

मोबाइल एप्लिकेशन में पूर्ण ऑफ़लाइन मोड के लिए क्या आवश्यक है? हमें विशेष रूप से इंटरनेट कनेक्शन की गुणवत्ता पर उपयोगकर्ता की निर्भरता को हटाने की आवश्यकता है:

1. यूआई में सर्वर से उसके कार्यों पर उपयोगकर्ता की प्रतिक्रियाओं की निर्भरता को हटा दें। सबसे पहले, अनुरोध स्थानीय भंडारण के साथ बातचीत करेगा, फिर इसे सर्वर पर भेजा जाएगा।
2. स्थानीय परिवर्तनों को चिह्नित और संग्रहीत करें।
3. एक सिंक्रनाइज़ेशन तंत्र को लागू करें - जब एक इंटरनेट कनेक्शन दिखाई देता है, तो आपको सर्वर में परिवर्तन भेजने की आवश्यकता होती है।
4. उपयोगकर्ता को दिखाएं कि परिवर्तन सिंक्रनाइज़ किए गए हैं, जो नहीं हैं।

ऑफलाइन-पहला दृष्टिकोण

सबसे पहले, मुझे सर्वर और डेटाबेस के साथ बातचीत के लिए मौजूदा तंत्र को बदलना पड़ा। लक्ष्य इंटरनेट की उपस्थिति या अनुपस्थिति के आधार पर उपयोगकर्ता को रोकना था। सबसे पहले, इसे स्थानीय डेटा वेयरहाउस के साथ बातचीत करनी चाहिए, और सर्वर अनुरोधों को पृष्ठभूमि में जाना चाहिए।

पिछले संस्करण में, डेटा संग्रहण परत और नेटवर्क परत के बीच एक मजबूत संबंध था। डेटा के साथ काम करने का तंत्र इस प्रकार था: पहले NetworkManager वर्ग के माध्यम से सर्वर से अनुरोध किया गया था, हमने परिणाम की प्रतीक्षा की, उसके बाद डेटा को रिपॉजिटरी वर्ग के माध्यम से डेटाबेस में सहेजा गया। फिर परिणाम यूआई को दिया गया, जैसा कि आरेख में दिखाया गया है।


ऑफ़लाइन-प्रथम-दृष्टिकोण को लागू करने के लिए, मैंने डेटा संग्रहण परत और नेटवर्क परत को अलग किया, एक नई फ़्लो क्लास की शुरुआत की जिसने उस क्रम को नियंत्रित किया जिसमें NetworkManager और Repository को बुलाया गया था। अब डेटा को पहले रिपॉजिटरी वर्ग के माध्यम से डेटाबेस में सहेजा जाता है, फिर परिणाम यूआई को भेजा जाता है, और उपयोगकर्ता एप्लिकेशन के साथ काम करना जारी रखता है। पृष्ठभूमि में, सर्वर से एक अनुरोध किया जाता है, प्रतिक्रिया के बाद, डेटाबेस और यूआई में जानकारी अपडेट की जाती है।

ऑब्जेक्ट आइडेंटिफ़ायर के साथ काम करें

नई वास्तुकला के साथ, कई नए कार्य दिखाई दिए, जिनमें से एक आईडी ऑब्जेक्ट्स के साथ काम कर रहा है। पहले, हमने उन्हें ऑब्जेक्ट बनाते समय सर्वर से प्राप्त किया। लेकिन अब ऑब्जेक्ट स्थानीय रूप से बनाया गया था, तदनुसार, एक आईडी उत्पन्न करना आवश्यक था और सिंक्रनाइज़ेशन के बाद उन्हें वर्तमान लोगों के लिए अपडेट किया गया। यहाँ मैं दायरे की पहली सीमा के पार आया: एक ऑब्जेक्ट बनाने के बाद, आप इसकी प्राथमिक कुंजी नहीं बदल सकते।

पहला विकल्प ऑब्जेक्ट में प्राथमिक कुंजी को छोड़ना था, आईडी को एक नियमित क्षेत्र बनाना था। लेकिन एक ही समय में, प्राथमिक कुंजी का उपयोग करने के फायदे खो गए थे: दायरे अनुक्रमण, जो ऑब्जेक्ट के भ्रूण को गति प्रदान करते हैं, ऑब्जेक्ट को फ्लैग फ्लैग के साथ अपडेट करने की क्षमता (यदि मौजूद नहीं है तो ऑब्जेक्ट बनाएं), और ऑब्जेक्ट की विशिष्टता का अनुपालन करें।

मैं प्राथमिक कुंजी को सहेजना चाहता था, लेकिन यह सर्वर से ऑब्जेक्ट की आईडी नहीं हो सकती थी। नतीजतन, काम करने वाले समाधान में दो पहचानकर्ता थे, जिनमें से एक सर्वर, वैकल्पिक क्षेत्र और दूसरा स्थानीय था, जो प्राथमिक कुंजी होगा।

परिणामस्वरूप, स्थानीय रूप से ऑब्जेक्ट बनाते समय क्लाइंट पर एक स्थानीय आईडी जनरेट की जाती है, और मामले में जब ऑब्जेक्ट सर्वर से आता है, तो यह सर्वर आईडी के बराबर होता है। चूंकि सत्य अनुप्रयोग के एकल स्रोत में एक डेटाबेस है, जब सर्वर से डेटा प्राप्त होता है, तो ऑब्जेक्ट को वर्तमान स्थानीय पहचानकर्ता के साथ अद्यतन किया जाता है, और केवल उसी के साथ काम करता है। सर्वर को डेटा भेजते समय, सर्वर पहचानकर्ता को प्रेषित किया जाता है।

असंबद्ध परिवर्तनों का संग्रहण

उन ऑब्जेक्ट्स में परिवर्तन जो अभी तक सर्वर पर नहीं भेजे गए हैं, उन्हें स्थानीय रूप से संग्रहीत किया जाना चाहिए। इसे निम्नलिखित तरीकों से लागू किया जा सकता है:

1. मौजूदा ऑब्जेक्ट में फ़ील्ड जोड़ना
2. अलग-अलग तालिकाओं में अनियंत्रित वस्तुओं को संग्रहीत करना;
3. कुछ प्रारूप में व्यक्तिगत फ़ील्ड परिवर्तन संग्रहीत करना।

मैं सीधे अपनी कक्षाओं में Realm ऑब्जेक्ट्स का उपयोग नहीं करता, लेकिन मैं मल्टीथ्रेडिंग के साथ समस्याओं से बचने के लिए अपनी मैपिंग स्वयं करता हूं। इंटरफ़ेस ऑटो-अपडेट परिणाम अपडेट करने वाले नमूनों का उपयोग करके किया जाता है, जहां मैं अनुरोधों को अपडेट करने के लिए सदस्यता लेता हूं। केवल पहले दृष्टिकोण ने मेरी वर्तमान वास्तुकला के साथ काम किया, इसलिए पसंद मौजूदा वस्तुओं में फ़ील्ड जोड़ने पर गिर गई।

मैप ऑब्जेक्ट में सबसे अधिक परिवर्तन हुए हैं:

• सिंक किया गया - क्या सर्वर पर डेटा है;
• हटाए गए - सही, यदि कार्ड केवल स्थानीय रूप से हटा दिया जाता है, तो सिंक्रनाइज़ेशन की आवश्यकता होती है।

पिछले हिस्से में चर्चा की गई पहचानकर्ता:

• LocalId - अनुप्रयोग में इकाई की प्राथमिक कुंजी, या तो सर्वर आईडी के बराबर, या स्थानीय रूप से उत्पन्न;
• serverId - आईडी सर्वर से।

अलग से ध्यान देने योग्य है छवियों का भंडारण। संक्षेप में, अटैचमेंट फ़ील्ड डिस्कूरल को सर्वर पर छवि के सर्वरल क्षेत्र में जोड़ा गया था, जो स्थानीय असंबद्ध छवि का पता संग्रहीत करता है। छवि को सिंक्रनाइज़ करते समय, स्थानीय एक को हटा दिया गया था ताकि डिवाइस मेमोरी को रोकना न हो।

सर्वर सिंक

सर्वर के साथ सिंक्रनाइज़ करने के लिए, रीचैबिलिटी के साथ काम जोड़ा गया था, ताकि जब इंटरनेट दिखाई दे, तो सिंक्रनाइज़ेशन तंत्र शुरू हो।

सबसे पहले, यह देखने के लिए जाँच करता है कि क्या डेटाबेस में कोई बदलाव करना है जिसे प्रस्तुत करने की आवश्यकता है। फिर, सर्वर को वास्तविक डेटा कास्ट के लिए एक अनुरोध भेजा जाता है, परिणामस्वरूप, क्लाइंट को भेजे जाने की आवश्यकता नहीं होने वाले परिवर्तनों की जांच की जाती है (उदाहरण के लिए, ऑब्जेक्ट पर एक परिवर्तन जो पहले से ही सर्वर पर हटा दिया गया है)। शेष परिवर्तन सर्वर के अनुरोधों को कतारबद्ध करते हैं।

परिवर्तनों को भेजने के लिए, बल्क अपडेट को लागू करना, एक सरणी में परिवर्तन भेजना, या सभी डेटा को सिंक्रनाइज़ करने के लिए एक बड़ा अनुरोध करना संभव था। लेकिन उस समय तक, बैकएंड डेवलपर पहले से ही किसी अन्य परियोजना में व्यस्त था, और केवल हमारे खाली समय में हमारी मदद करता था, इसलिए हम प्रत्येक प्रकार के परिवर्तन के लिए अनुरोध करते हैं।

मैंने ऑपरेशन क्यू के माध्यम से कतार को लागू किया और प्रत्येक अनुरोध को एक अतुल्यकालिक ऑपरेशन में लपेट दिया। कुछ ऑपरेशन एक दूसरे पर निर्भर करते हैं, उदाहरण के लिए, हम नक्शा बनाने से पहले नक्शा छवि को लोड नहीं कर सकते हैं, इसलिए मैंने छवि ऑपरेशन की निर्भरता को मानचित्र ऑपरेशन में जोड़ा। इसके अलावा, सर्वर पर छवियों को अपलोड करने के संचालन को बाकी सभी की तुलना में कम प्राथमिकता दी गई थी, और मैंने उनके भारी होने के कारण उन्हें कतार में भी जोड़ा।

ऑफ़लाइन मोड की योजना बनाते समय, बड़ा प्रश्न सिंक्रनाइज़ेशन के दौरान सर्वर के साथ संघर्षों को हल कर रहा था। लेकिन जब हम कार्यान्वयन के दौरान इस बिंदु पर पहुंचे, तो हमने महसूस किया कि जब उपयोगकर्ता विभिन्न उपकरणों पर एक ही डेटा बदलता है तो मामला बहुत दुर्लभ है। इसलिए हमारे लिए अंतिम लेखक जीत तंत्र को लागू करना पर्याप्त है। सिंक्रनाइज़ेशन के दौरान, प्राथमिकता हमेशा क्लाइंट पर असंतुलित परिवर्तनों को दी जाती है, उन्हें रगड़ा नहीं जाता है।

त्रुटि हैंडलिंग अभी भी अपनी प्रारंभिक अवस्था में है, यदि सिंक्रनाइज़ेशन विफल हो जाता है, तो अगली बार इंटरनेट दिखाई देने पर ऑब्जेक्ट को परिवर्तन कतार में जोड़ा जाएगा। और फिर अगर यह मर्ज के बाद भी सिंक से बाहर लटका रहता है, तो उपयोगकर्ता यह तय करेगा कि इसे छोड़ना है या इसे हटाना है।

दायरे के साथ काम करते समय अतिरिक्त समाधान

जब Realm के साथ काम करना कई और समस्याओं का सामना करना पड़ा। शायद यह अनुभव किसी के लिए भी उपयोगी होगा।

स्ट्रिंग द्वारा क्रमबद्ध करने पर, क्रम UTF-8 में वर्ण क्रम के अनुसार चलता है, कोई केस-संवेदी खोज समर्थन नहीं है। हमें ऐसी स्थिति का सामना करना पड़ता है जहां ऊपरी मामले में नामों के बाद निचले मामले में नाम आते हैं, उदाहरण के लिए: चुंबक, पायटेचोर्का, रिबन। यदि सूची बहुत बड़ी है, तो निचले मामले में सभी नाम सबसे नीचे होंगे, जो बहुत अप्रिय है।

सॉर्ट ऑर्डर को संरक्षित करने के लिए, मामले की परवाह किए बिना, हमें एक नया लोअरकेसडैम फ़ील्ड पेश करना था, नाम को अपडेट करते समय इसे अपडेट करें और इसे सॉर्ट करें।

इसके अलावा, पसंदीदा में एक कार्ड की उपस्थिति के आधार पर छंटनी के लिए एक नया क्षेत्र जोड़ा गया था, क्योंकि संक्षेप में इस वस्तु के संबंधों के लिए एक उपश्रेणी की आवश्यकता होती है।

जब दायरे में खोज की जाती है, तो केस-असंवेदनशील खोजों के लिए CONTAINS [c]% @ विधि होती है। लेकिन, अफसोस, यह केवल लैटिन वर्णमाला के साथ काम करता है। रूसी ब्रांडों के लिए, हमें अलग-अलग फ़ील्ड बनाने और उन पर खोज करने की भी आवश्यकता थी। लेकिन बाद में खोज करते समय विशेष पात्रों को बाहर करना हमारे हाथ में रहा।

---

जैसा कि आप देख सकते हैं, मोबाइल एप्लिकेशन के लिए परिवर्तनों को सहेजने और थोड़े से रक्त के साथ सिंक्रनाइज़ करने के साथ ऑफ़लाइन मोड को लागू करना काफी संभव है, और कभी-कभी बैकएंड पर न्यूनतम बदलाव के साथ भी।

कुछ कठिनाइयों के बावजूद, आप लाइव अपडेट, शून्य-कॉपी आर्किटेक्चर और एक सुविधाजनक एपीआई के रूप में सभी फायदे प्राप्त करते हुए, इसे लागू करने के लिए दायरे का उपयोग कर सकते हैं।

इसलिए कनेक्शन की गुणवत्ता की परवाह किए बिना किसी भी समय आपके उपयोगकर्ताओं को डेटा तक पहुंच से वंचित करने का कोई कारण नहीं है।