आधुनिक मोबाइल विंडोज प्लेटफार्मों के लिए क्रॉस-प्लेटफॉर्म प्रोग्रामिंग

असली

मोबाइल ऑपरेटिंग सिस्टम की दुनिया में, पहले दो स्थान अब Android और iOS द्वारा साझा किए गए हैं। विभिन्न कंपनियों के विभिन्न मैट्रिक्स और अनुमानों के अनुसार, हम एक ऑपरेटिंग सिस्टम या किसी अन्य को पहला स्थान दे सकते हैं, लेकिन इसमें कोई संदेह नहीं है कि वे अग्रणी हैं। लेकिन किसी भी ओलंपिक की तरह, हमारे पास अभी भी कांस्य है। आइए उसके बारे में फैसला करने की कोशिश करें।

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





जवाब "हाँ!" है, और अब मैं आपको बताता हूँ कि क्यों। मेरा नाम वादिम बालाशोव है, मैं विंडोज 8 और विंडोज फोन के लिए एक मेल डेवलपर हूं, और पॉकेटम 2003 के बाद से मैं मोबाइल विंडोज विकसित कर रहा हूं।

विंडोज फोन की बिक्री का हिस्सा बढ़ रहा है। 2012 में, यह 2011 की तुलना में तेजी से बढ़ा। खासकर यदि आप पिछले कुछ महीनों के डेटा को देखते हैं जब विंडोज फोन 8 जारी किया गया था, तो विकास और भी अधिक गतिशील था । इसके अलावा, आईडीसी के अनुसार, जो अनुमान लगाया जाता है कि बेचे गए उपकरणों की संख्या, कुछ देशों में विंडोज फोन की बिक्री में 10% से अधिक है, और 26 देशों में बिक्री की हिस्सेदारी पहले ही ब्लैकबेरी की हिस्सेदारी को पार कर गई है, और 7 देशों में भी आईओएस । एक ही आईडीसी के पूर्वानुमान के अनुसार, इस समय विंडोज फोन की बिक्री का कुल हिस्सा 3.2% है , और 4 साल बाद यह 11.4% हो जाएगा। इसमें कोई संदेह नहीं है कि मंच गति प्राप्त कर रहा है।



अब विंडोज 8 पर नजर डालते हैं। डेस्कटॉप सिस्टम के लिए बाजार पूरी तरह से अलग है, यहां उपयोगकर्ताओं की संख्या के लिए थोड़ा अलग अनुमान है। लेकिन विंडोज 8 के आधिकारिक लॉन्च के 7 महीने बाद, यानी जून की शुरुआत में, यह पहले से ही 5.10% पर है ; यह पहले से ही सबसे लोकप्रिय मैक ओएस एक्स 10.8 से अधिक है।



इसी समय, विंडोज 8 की हिस्सेदारी बिना धीमे धीमे बढ़ती जा रही है:

परिचय

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

शब्दावली के बारे में थोड़ा। जब WP7 की बात आती है, तो हम प्लेटफ़ॉर्म के दो संस्करणों - 7.5 और 7.8 का मतलब करेंगे। कुछ मामलों में, विंडोज फोन 8 पर भी अलग से चर्चा की जाएगी, जिसमें पिछले संस्करण से कुछ अंतर हैं।

विंडोज 8. के ​​लिए शब्दावली के साथ चीजें बदतर हैं। इस लेख में हम इसके स्पर्श घटक के बारे में बात करेंगे, जिसे पहले मेट्रो यूआई कहा जाता था, फिर - आधुनिक यूआई। इस स्थिति में, ऑपरेटिंग सिस्टम का टैबलेट संस्करण, जहां केवल आधुनिक यूआई है, विंडोज आरटी कहा जाता है, और एप्लिकेशन को स्टोर एप्लिकेशन (विंडोज स्टोर के लिए एप्लिकेशन) कहा जाता है। यह सभी प्रकार की शर्तें विंडोज 8 की रिलीज के बाद दिखाई दीं, लेकिन वास्तव में एक ही बात को संदर्भित करती हैं, और इस लेख में हम बस "विंडोज विंडोज" कहेंगे।

कहानी

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



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

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

MVVM

अब MVVM पैटर्न के बारे में थोड़ा। IOS प्लेटफ़ॉर्म के सहकर्मियों ने पहले ही मुझसे दो बार एक सवाल पूछा है: "सर्विस लोकेटर क्यों नहीं?"। "सेवा लोकेटर" विचारधारा के बाद एमवीवीएम शायद अगला कदम है, जहां डेटा और डेटा प्रोसेसिंग के तरीके एक साथ स्थित हैं। यहाँ वे विभाजित हैं।



मॉडल केवल डेटा है, अर्थात सबसे सरल कक्षाएं जिनके पास डेटा संग्रहीत करने वाले फ़ील्ड हैं और संभवतः, कुछ साधारण फ़ील्ड प्रोसेसिंग या फ़ील्ड की गणना अन्य फ़ील्ड्स के आधार पर की जाती है, उदाहरण के लिए, FullName फ़ील्ड, जो स्वयं FirstName और LastName गुणों को समेटती है।

देखें कि इंटरफ़ेस में डेटा कैसा दिखता है, अर्थात उपयोगकर्ता उन्हें क्या देखते हैं।

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



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

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

मान लीजिए कि उपयोगकर्ता को वास्तव में पत्र पसंद आया है, तो वह इसे ध्वजांकित करना चाहता है। हम विपरीत दिशा में जाते हैं:

• उपयोगकर्ता UI में ध्वज पर क्लिक करता है; देखें कि कौन सी घटना को ट्रिगर किया जाना चाहिए;
• ViewModel एक कमांड को यह कहते हुए चलाता है कि आपको ऑब्जेक्ट को बदलने की आवश्यकता है;
• मॉडल स्थिति बदल रही है, अर्थात्, एक चेकबॉक्स है;
• डेटा हैंडलर सर्वर पर एक ध्वज सेट करने के लिए एक अनुरोध उत्पन्न करता है;
• LowLevel फ़ंक्शन सर्वर से अनुरोध को सीधे पारित करता है।

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

प्लेटफ़ॉर्म-स्वतंत्र घटक, क्रमशः, मॉडल, व्यूमॉडल और डेटाहैंडलर हैं।

मॉडल , अर्थात पत्र जो फोन पर है कि टैबलेट पर समान है। यह सर्वर से एक रूप में आता है; हमारे पास खेतों का एक निश्चित समूह है, जिसके साथ हम काम करेंगे।

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

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



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

अब थोड़ा और उन्नत योजना पर चलते हैं।



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

क्रॉस-प्लेटफॉर्म MVVM कार्यान्वयन

अब क्रॉस-प्लेटफॉर्म के कार्यान्वयन के बारे में थोड़ा और अधिक। ViewModel के लिए उपयोगकर्ता इंटरफ़ेस को सूचित करने के लिए कि उसका डेटा बदल गया है और इन परिवर्तनों को प्रदर्शित किया जा सकता है, ViewModel को IPropertyChange इंटरफ़ेस से विरासत में प्राप्त होना चाहिए।



चूंकि अधिकांश अनुप्रयोगों में एक से अधिक ViewModel हैं, इसलिए प्रत्येक ViewModel में इस इंटरफ़ेस को लागू करना अव्यावहारिक है और एकल ViewModelBase वर्ग को परिभाषित करना बेहतर है।

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



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

अब विपरीत स्थिति तब है जब आपको ViewModel में View से एक कमांड प्राप्त करने की आवश्यकता होती है, जैसा कि फ्लैगिंग के मामले में।



इस तरह की कमांड को ICommand इंटरफ़ेस से विरासत में मिला होना चाहिए। यहां स्थिति समान है - हम मूल कमांडबेस कमांड बनाते हैं और फिर इसके साथ काम करते हैं, क्योंकि किसी भी कार्यक्रम में, ViewModels से भी अधिक आदेश हैं।

अब डेटा हैंडलर के बारे में। डेटा प्रोसेसर वास्तव में उस कच्चे डेटा को बदलने में लगे हुए हैं जो हमें मॉडल में नेटवर्क पर प्राप्त हुआ था। और रिवर्स स्थिति यह है कि वे सर्वर में कमांड करने के लिए ViewModels (ध्वज को स्थापित करने के मामले में) से आए परिवर्तनों या आदेशों को परिवर्तित करते हैं।

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

निम्न-स्तर के कार्य उन प्लेटफ़ॉर्म-निर्भर फ़ंक्शंस हैं जिन्हें प्लेटफ़ॉर्म-इंडिपेंडेंट नहीं बनाया जा सकता है। उन्हें यथासंभव कम करने की आवश्यकता है। उन्हें न्यूनतम कार्यक्षमता लेनी चाहिए जिसे वास्तव में क्रॉस-प्लेटफ़ॉर्म नहीं बनाया जा सकता है। उदाहरण के लिए, एक डिस्क / नेटवर्क के साथ काम करने के लिए, निम्न-स्तरीय ऑब्जेक्ट को दो कार्य प्रदान करने चाहिए SaveBytes / SendBytes और LoadBytes / ReceiveBytes। किसी भी अन्य कार्यक्षमता (अखंडता की जाँच, प्रारंभिक प्रसंस्करण, आदि) को DataHandler में स्थानांतरित किया जाना चाहिए।

दूसरे शब्दों में, एक लॉवेल फ़ंक्शन को एक सामान्य कार्यात्मक से अलग करने के लिए, यह समझना आवश्यक है कि डेटाहैंडलर में क्या नहीं छोड़ा जा सकता है। यह न्यूनतम लॉवेल फंक्शन होगा।

प्लेटफार्म आश्रित घटक

हम चार मंच-विशिष्ट कार्यों पर विचार करते हैं: एक नेटवर्क के साथ काम करना, एक रिपॉजिटरी के साथ काम करना, एक रिपॉजिटरी के साथ काम करने का एक अलग मामला (सेटिंग्स के साथ काम करना), और प्रेषण प्रवाह।

पोर्टेबल क्लास लाइब्रेरी में HttpRequest और HttpWebRequest कक्षाएं शामिल हैं। ये कक्षाएं HTTP के माध्यम से सर्वर के साथ काम को पूरी तरह से लागू करने के लिए पर्याप्त हैं। हालांकि, उनके पास पूरी कार्यक्षमता नहीं है जिसका उपयोग किया जा सकता है। उदाहरण के लिए, विंडोज 8 के लिए एपीआई में HttpClient वर्ग है, जो ट्रैफ़िक संपीड़न का समर्थन करता है, और प्लस POST अनुरोधों के साथ काम करने के लिए बहुत सुविधाजनक बनाता है। वास्तव में, एक ऑब्जेक्ट को कक्षा में पास किया जाता है, और यह एक POST अनुरोध उत्पन्न करता है। HttpRequest के मामले में, POST अनुरोध RFC के अनुसार, लगभग मैन्युअल रूप से उत्पन्न किया जाना चाहिए।

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

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

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

सेटिंग्स को संग्रहीत करने के लिए एक अलग स्थिति है। सामान्य तौर पर, सेटिंग्स का भंडारण किसी भी अन्य डेटा के भंडारण से किसी भी तरह से भिन्न नहीं होता है, क्योंकि सेटिंग्स को एक ही डिस्क भंडारण में संग्रहीत किया जाता है। हालांकि, सेटिंग्स के लिए, सिस्टम रैपर प्रदान करता है जो आपको अतिरिक्त प्रयास के बिना कुंजी-मूल्य शब्दकोशों को संग्रहीत करने की अनुमति देता है। स्थिति डिस्क स्टोरेज के समान है: विंडोज फोन के लिए विंडोज 8 - ApplicationData.Current.LocalSettings के लिए IsolatedStorageSettings.ApplicationSettings है। और फिर, विंडोज फोन 8 के साथ एक दिलचस्प स्थिति: एपीआई में सेटिंग्स के साथ काम करने के लिए दोनों वर्ग होते हैं, लेकिन व्यवहार में, अगर हम लोकलसेटिंग में सेटिंग्स को बचाने की कोशिश करते हैं, तो NotImforceedException को फेंक दिया जाएगा। यही है, हमारे पास सेटिंग्स वर्ग के लिए एक लिंक है, लेकिन व्यवहार में, इस लिंक के पीछे कुछ भी नहीं है।



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

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

UI स्ट्रीम में परिवर्तन डिस्पैचर के लिए कॉल के माध्यम से किया जाता है, जिसमें एक प्रतिनिधि भेजा जाता है, जो UI को सूचित करता है कि डेटा प्रदर्शन के लिए तैयार है।



समस्या यह है कि डिस्पैचर प्लेटफ़ॉर्म विशिष्ट है। विंडोज 8 और विंडोज फोन दोनों में एक डिस्पैचर होता है, और उनके काम का सार इस तथ्य में ठीक है कि वे यूआई स्ट्रीम में पृष्ठभूमि धाराओं से स्थानांतरित प्रतिनिधियों को निष्पादित करते हैं। लेकिन एक ही समय में उन्हें अलग-अलग तरीकों से लागू किया जाता है: वे अलग-अलग NameSpace'ah में स्थित होते हैं, कॉल अलग-अलग नामों के तरीकों पर जाती है, वे अलग-अलग पैरामीटर लेते हैं।

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



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

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



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

विंडोज फोन 7 और 8 के लिए, यह इस प्रकार है:

DoDispatched = action => Dispatcher.BeginInvoke(action);

विंडोज 8 के मामले में, हम लगभग एक ही काम करते हैं, केवल, कॉल बारीकियों के अनुसार, हम अतिरिक्त रूप से प्राथमिकता दर्शाते हैं:

DoDispatched = action => Dispatcher.RunAsync(priority, action.Invoke);

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

DoDispatched(() =>
{
…
}

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

मुझे उम्मीद है कि इस लेख को पढ़ने के बाद आप पहले ही सवाल का जवाब दे सकते हैं: