मोबाइल अनुप्रयोगों के विकास में क्रॉस-प्लेटफॉर्म और देशी दृष्टिकोण का संयोजन

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

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

क्रॉस-प्लेटफॉर्म मोबाइल एप्लिकेशन विकसित करने के लिए तीन दृष्टिकोण

शुरू करने के लिए, इस बात पर विचार करें कि जब आपको एक ही बार में दो एप्लिकेशन प्राप्त करने की आवश्यकता हो, तो कौन-सी एप्रोच का उपयोग किया जाए: iOS और Android के लिए।

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

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


लेकिन क्या होगा यदि उपयोग किए गए एपीआई की संख्या बढ़ती है?


यह सवाल है: मानव संसाधनों की आवश्यक मात्रा को कैसे कम करें? प्रत्येक प्लेटफ़ॉर्म के लिए डुप्लिकेट कोड की आवश्यकता से छुटकारा पाएं। इस समस्या को हल करने के लिए पर्याप्त संख्या में चौखटे और प्रौद्योगिकियां हैं।

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


कई लोग, मुझे लगता है, जानते हैं कि ज़मरीन क्या है, या कम से कम इसके बारे में सुना है, लेकिन यह कैसे काम करता है? Xamarin .NET प्लेटफॉर्म - मोनो के ओपन-सोर्स कार्यान्वयन पर आधारित है। मोनो में अपना सी # कंपाइलर, रनटाइम, साथ ही कई लाइब्रेरी शामिल हैं, जिसमें WinForms और ASP.Net का कार्यान्वयन शामिल है।

परियोजना का लक्ष्य विंडोज # के अलावा ऑपरेटिंग सिस्टम पर चलने के लिए C # में लिखे गए प्रोग्रामों की अनुमति देना है - यूनिक्स सिस्टम, मैक ओएस, और अन्य। Xamarin ढांचे में, संक्षेप में, एक वर्ग पुस्तकालय है जो डेवलपर्स को मंच के एसडीके और इन के लिए संकलक तक पहुंच प्रदान करता है। Xamarin.Forms, बदले में, आपको न केवल एक भाषा में दोनों प्लेटफार्मों के लिए लिखने की अनुमति देता है, बल्कि XAML मार्कअप का उपयोग करके स्क्रीन भी डिज़ाइन करता है, जो उन लोगों से परिचित हैं जिनके पास पहले से ही WPF अनुप्रयोगों के साथ अनुभव था। प्रोजेक्ट असेंबली के परिणामस्वरूप, हमें सभी प्लेटफार्मों पर लगभग समान रूप मिलता है, क्योंकि संकलन चरण पर सभी XF नियंत्रण प्रत्येक प्लेटफॉर्म के लिए मूल में परिवर्तित होते हैं।


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

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

यह तीसरे दृष्टिकोण पर आगे बढ़ेगा, जिसका उपयोग हम अनुप्रयोगों को विकसित करते समय करते हैं।

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

हमारे पास सभी तीन परियोजनाएं हैं: एक आम पीसीएल परियोजना, लेकिन बिना ज़ामरीन फॉर्म, और दो ज़मारिन एंड्रॉइड और ज़मारिन आईओएस परियोजनाएं। अभी भी एक भाषा में सब कुछ लिखने का अवसर है, दो परियोजनाओं के बीच आम तर्क है, लेकिन एक एकल एक्सएएमएल मार्कअप की कोई सीमा नहीं है। UI घटक प्रत्येक प्लेटफ़ॉर्म द्वारा नियंत्रित किया जाता है और मूल उपकरण का उपयोग करता है, Android पर - देशी AXML, iOS पर - XIB फ़ाइलें। प्रत्येक प्लेटफ़ॉर्म में अपने दिशानिर्देशों का पालन करने की क्षमता होती है, क्योंकि कोर और प्लेटफ़ॉर्म परियोजनाओं के बीच का कनेक्शन केवल डेटा स्तर पर आयोजित किया जाता है।

इस तरह के रिश्ते को व्यवस्थित करने के लिए, आप एमवीवीएम डिजाइन पैटर्न और इसके काफी लोकप्रिय कार्यान्वयन का उपयोग कर सकते हैं ज़मारिन - एमवीवीएमसीओस। इसका उपयोग आपको प्रत्येक स्क्रीन के लिए एक सामान्य ViewModel रखने की अनुमति देता है, जो काम के पूरे "व्यावसायिक तर्क" का वर्णन करता है, और इसके प्रतिपादन को मंच पर सौंपता है। यह दो डेवलपर्स को एक ही स्क्रीन (तर्क के साथ एक - यूआई के साथ दूसरे) के साथ काम करने की अनुमति देता है और एक दूसरे के साथ हस्तक्षेप नहीं करता है। पैटर्न के कार्यान्वयन के अलावा, हमें काम के लिए पर्याप्त संख्या में उपकरण मिलते हैं: DI और IoC का कार्यान्वयन। प्लेटफ़ॉर्म के साथ कॉमन कोड के स्तर पर बातचीत बढ़ाने के लिए, एक डेवलपर को केवल एक इंटरफ़ेस घोषित करने और इसे प्लेटफ़ॉर्म पर लागू करने की आवश्यकता होती है। विशिष्ट चीजों के लिए, MvvmCross पहले से ही अपने स्वयं के प्लगइन्स का एक सेट प्रदान करता है। टीम में, हम प्लेटफ़ॉर्म और कॉमन कोड और फ़ाइलों के साथ काम करने के लिए प्लगइन (गैलरी, आदि से छवियों का चयन) के लिए संदेशवाहक प्लगइन का उपयोग करते हैं।

हम जटिल डिजाइन और बहु-स्तरीय नेविगेशन की समस्याओं को हल करते हैं

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


उपयोगकर्ता इनपुट के साथ काम करने के दौरान, इस तरह के इनपुट नियंत्रण को यहां विकसित किया गया था। वह इनपुट फ़ील्ड के ऊपर अपना नाम बढ़ा सकता है, मास्क के साथ काम कर सकता है, उपसर्ग सेट कर सकता है, पोस्टफ़िक्स कर सकता है, कैप्सलॉक को दबाए जाने पर सूचित कर सकता है, दो मोड में जानकारी को मान्य कर सकता है: इनपुट का निषेध और त्रुटि की जानकारी का आउटपुट। नियंत्रण के अंदर तर्क लगभग ~ 1000 लाइनें लेता है। और, यह प्रतीत होता है: इनपुट क्षेत्र के डिजाइन में क्या जटिल हो सकता है?

एक जटिल नियंत्रण का एक सरल उदाहरण हमने देखा। स्क्रीन के बारे में क्या?


इसके साथ शुरू करने के लिए, मैं स्पष्ट करूँगा कि ज्यादातर मामलों में एक अनुप्रयोग स्क्रीन एक वर्ग है - UIViewController, इसके व्यवहार का वर्णन करता है। विकास के दौरान, बहु-स्तरीय नेविगेशन के निर्माण की आवश्यकता थी। विकसित एप्लिकेशन की अवधारणा आपकी अचल संपत्ति के प्रबंधन और पड़ोसियों और नगरपालिका संगठनों के साथ बातचीत करने के लिए नीचे आती है। इसलिए, नेविगेशन के तीन स्तर बनाए गए थे: संपत्ति, प्रस्तुति स्तर (घर, शहर, क्षेत्र) और सामग्री का प्रकार। सभी स्विचिंग को एक स्क्रीन में किया जाता है।

ऐसा इसलिए किया गया ताकि उपयोगकर्ता, जहाँ भी वह हो, समझे कि वह किस प्रकार की सामग्री को देखता है। इस तरह के नेविगेशन को व्यवस्थित करने के लिए, एप्लिकेशन की मुख्य स्क्रीन में केवल एक नियंत्रक नहीं होता है। नेत्रहीन, इसे 3 भागों में विभाजित किया जा सकता है, लेकिन क्या कोई यह अनुमान लगाने की कोशिश कर सकता है कि यहां कितने नियंत्रकों का उपयोग किया जाता है?


पंद्रह मुख्य नियंत्रक। और यह सिर्फ सामग्री के लिए है।

यहां ऐसा राक्षस मुख्य स्क्रीन पर रहता है और बहुत अच्छा महसूस करता है। एक स्क्रीन के लिए पंद्रह नियंत्रक, निश्चित रूप से, बहुत सारे हैं। यह संपूर्ण एप्लिकेशन की गति को प्रभावित करता है, और आपको इसे किसी तरह अनुकूलित करने की आवश्यकता है।

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

इतने सारे नियंत्रकों पर नज़र रखने के लिए आपको समझने की आवश्यकता है:

• किस हालत में उनमें से प्रत्येक है;
• उपयोगकर्ता कहां है;
• दूसरे नियंत्रक के पास जाने पर वह क्या देखने की उम्मीद करता है।

ऐसा करने के लिए, मैंने एक अलग नेविगेशन प्रोसेसर लिखा है जो उपयोगकर्ता के स्थान, उस सामग्री का प्रकार जो वह देख रहा है, नेविगेशन इतिहास आदि के बारे में जानकारी संग्रहीत करता है। वह आरंभ के क्रम और आवश्यकता को नियंत्रित करता है।

चूंकि प्रत्येक टैब एक नियंत्रक स्लाइडर है (उन पर एक स्वाइप संक्रमण बनाने के लिए), आपको समझने की आवश्यकता है: उनमें से प्रत्येक अपनी स्थिति में हो सकता है (उदाहरण के लिए, "समाचार" एक पर खुला है, और दूसरे पर "वोटिंग")। इसके बाद उसी नेविगेशन प्रोसेसर का उपयोग किया जाता है। यहां तक ​​कि घर से क्षेत्र तक प्रस्तुति के स्तर को बदलते हुए, हम उसी प्रकार की सामग्री पर बने रहेंगे।

हम वास्तविक समय में डेटा के प्रवाह को नियंत्रित करते हैं

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

1. एपीआई तक पहुंच टाइमर या ट्रिगर और स्क्रीन पर प्रासंगिक सामग्री का फिर से अनुरोध करें;
2. सर्वर से स्थायी संबंध रखें और वास्तविक समय में परिवर्तन प्राप्त करें;
3. सामग्री परिवर्तन के साथ पुश प्राप्त करें।

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

यह पता चला है:

• गर्म सामग्री - एपीआई के साथ स्थायी संबंध;
• सामान्य सामग्री - एपीआई के लिए http-request;
• सिस्टम सामग्री - पुश सूचनाएँ।

सबसे दिलचस्प बात एक निरंतर संबंध बनाए रखना है। वेब सॉकेट्स के साथ काम करने के लिए अपने स्वयं के क्लाइंट लिखना खरगोश के छेद में एक कदम है, इसलिए आपको अन्य समाधानों की तलाश करने की आवश्यकता है। परिणामस्वरूप, हम सिग्नलआर लाइब्रेरी में रुक गए। आइए देखें कि यह क्या है।

ASP.Net सिग्नलआर Microsoft की एक लाइब्रेरी है जो क्लाइंट और सर्वर के बीच द्वि-दिशात्मक संचार प्रदान करते हुए वास्तविक समय में क्लाइंट-सर्वर इंटरैक्शन को सरल बनाती है। सर्वर में कनेक्शन, कनेक्शन-वियोग घटनाओं, समूहों में जुड़े क्लाइंट को संयोजित करने के लिए एक तंत्र और प्राधिकरण के प्रबंधन के लिए एक पूर्ण एपीआई शामिल है।

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

कुल, हमें क्या लाभ मिलता है:

• क्लाइंट और सर्वर के बीच किसी भी प्रकार के संदेशों का आदान-प्रदान करने की क्षमता;
• वेब सॉकेट, लॉन्ग पूलिंग और एचटीपी अनुरोधों के बीच स्वचालित रूप से स्विच करने के लिए तंत्र;
• कनेक्शन की वर्तमान स्थिति के बारे में जानकारी;
• समूहों में ग्राहकों को एकजुट करने का अवसर;
• एक समूह में संदेश भेजने के तर्क में हेरफेर करने के लिए व्यावहारिक तरीके;
• सर्वर को स्केल करने की क्षमता।

यह, ज़ाहिर है, सभी जरूरतों को पूरा नहीं करता है, लेकिन ध्यान देने से जीवन आसान हो जाता है।

परियोजना के अंदर, सिग्नलर लाइब्रेरी पर एक आवरण का उपयोग किया जाता है, जो आगे इसके साथ काम करने को सरल बनाता है, अर्थात्:

• कनेक्शन की स्थिति पर नज़र रखता है, निर्दिष्ट स्थितियों के अनुसार और एक ब्रेक की स्थिति में फिर से जोड़ता है;
• जल्दी से एक कनेक्शन को बदलने या फिर से खोलने में सक्षम, पुराने को मारकर उसे फाड़ने के लिए कचरा कलेक्टर को दे - जैसा कि यह निकला, कनेक्शन सेटअप विधि क्लोजर विधि (डिस्पोज या स्टॉप) की तुलना में दस गुना तेजी से काम करती है, और इसे बंद करने का एकमात्र तरीका है;
• संदेश भेजने के लिए एक कतार आयोजित करता है ताकि कनेक्शन को फिर से जोड़ने या फिर से खोलने से भेजने में बाधा न आए;
• अनपेक्षित त्रुटियों के मामले में उपयुक्त प्रतिनिधियों को स्थानांतरण नियंत्रित करता है।

इनमें से प्रत्येक रैपर (हम उन्हें क्लाइंट कहते हैं) कैशिंग सिस्टम के साथ मिलकर काम करता है, और, वियोग की स्थिति में, केवल उस डेटा का अनुरोध कर सकता है जो इस समय के दौरान छूट गया हो। "प्रत्येक क्योंकि कई सक्रिय यौगिक एक साथ आयोजित किए जाते हैं। एप्लिकेशन के अंदर एक पूर्ण संदेशवाहक है, और इसे सेवा देने के लिए एक अलग क्लाइंट का उपयोग किया जाता है।

दूसरा क्लाइंट सूचना प्राप्त करने के लिए जिम्मेदार है। जैसा कि मैंने पहले ही कहा था, सामान्य प्रकार की सामग्री http-request के माध्यम से प्राप्त की जाती है, भविष्य में इसका अद्यतन इस क्लाइंट के साथ होता है, जो इसमें सभी महत्वपूर्ण बदलावों की रिपोर्ट करता है (उदाहरण के लिए, मतदान एक स्थिति से दूसरी स्थिति में, नई समाचार का प्रकाशन)।

एप्लिकेशन में डेटा की कल्पना करें

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

1. अपठित सामग्री की अधिसूचना;
2. स्क्रीन पर डेटा का स्वचालित अद्यतन;
3. सामग्री की पेशकश।

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

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

जब आपको सूची में नई सामग्री जोड़ने की आवश्यकता होती है तो कठिनाइयाँ आती हैं। आवेदन में सभी सूचियाँ, वास्तव में, स्क्रॉलव्यू हैं और इनमें कई विशेषताएं हैं: खिड़की का आकार, सामग्री का आकार और स्क्रॉल स्थिति। उन सभी की एक स्थिर शुरुआत है (निर्देशांक 0; 0 के साथ स्क्रीन के ऊपर) और नीचे विस्तार हो सकता है। सूची में नई सामग्री जोड़ें, अंत में, कोई समस्या नहीं है, सूची अंतिम होगी। लेकिन शीर्ष पर नई सामग्री दिखाई देनी चाहिए और यह चित्र है:


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

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

इस दृष्टिकोण के साथ, हम, बेशक, सामग्री की "बाजीगरी" की समस्याओं से बचते थे, लेकिन उन्हें अभी भी हल करना था। अर्थात्, चैट स्क्रीन पर, स्क्रीन के साथ संचार और बातचीत के दौरान, नई सामग्री को विभिन्न स्थानों पर प्रदर्शित किया जाना चाहिए।

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

दूसरा बिंदु: स्क्रॉल करते हुए इतिहास लोड करना। बस कहानी को लोड करते समय, हम खुद को ऐसी स्थिति में पाते हैं, जहां समीक्षा स्तर से ऊपर संदेशों को रखना आवश्यक होता है (जो पूर्वाग्रह पैदा करेगा) ताकि स्क्रॉल चिकनी और निरंतर हो। और जैसा कि हम पहले से ही जानते हैं, उपयोगकर्ता को परेशान नहीं करने के लिए, स्क्रॉल स्थिति को मैन्युअल रूप से नियंत्रित करना असंभव है।

और हमें एक समाधान मिला: हमने इसे बदल दिया। स्क्रीन फ्लिप ने एक ही बार में दो समस्याओं को हल किया:

1. सूची की पूंछ सबसे ऊपर है, इसलिए हम उपयोगकर्ता स्क्रॉल के साथ हस्तक्षेप किए बिना एक कहानी जोड़ सकते हैं;
2. अंतिम संदेश हमेशा सूची में सबसे ऊपर होता है और इससे पहले हमें स्क्रीन को स्क्रॉल करने की आवश्यकता नहीं है।

इस समाधान ने स्क्रॉलिंग नियंत्रण के साथ अनावश्यक संचालन को समाप्त करते हुए, रेंडरिंग को गति देने में भी मदद की।

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

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

नतीजतन, हमें एक चिकनी स्क्रॉल मिलती है और ओवरलोडेड यूआई स्ट्रीम नहीं।

संक्षेप में:

• क्रॉस-प्लेटफ़ॉर्म विकास समय और पैसा बचाता है;
• , , ;
• , ;
• ;
• SignalR – - ;
• ;
• , , ;
• , SignalR-, , , , .