Caliburn.Micro ढांचे (भाग 1) का उपयोग करके हल्के WP7 अनुप्रयोग विकास

आपका स्वागत है!

जैसा कि नाम से पता चलता है, इस लेख को Caliburn.Micro ढांचे के लिए प्रबुद्ध किया जाएगा। मैं यह दिखाने की कोशिश करूंगा कि WP7 प्लेटफॉर्म के लिए डेवलपर के लिए इस ढांचे का उपयोग उपयोगी जानकारी प्रदान कर सकता है, यह किस कार्य को हल करता है, इसके फायदे और नुकसान।

लेकिन सबसे महत्वपूर्ण सवाल जो मैं पूरे लेख में जवाब देने की कोशिश करूंगा, मुझे WP7 के एक काफी व्यवस्थित राज्य में, किसी तरह के ढांचे के रूप में एक और मध्यवर्ती परत की आवश्यकता क्यों है।

यदि आप इस विषय में रुचि रखते हैं, तो बिल्ली में आपका स्वागत है।

ट्रेनिंग

मुझे लगता है कि इस लेख की सामग्री मुख्य रूप से पहले से ही WP7 विकास से परिचित लोगों के लिए ब्याज की होगी। इसलिए, मैं वीएस आदि में एक परियोजना बनाने के बारे में बात नहीं करूंगा, लेकिन मैं यह मानूंगा कि आप पहले से ही यह जानते हैं या कई अन्य खुले स्रोतों से सीख सकते हैं।

स्वतंत्र प्रयोगों के लिए आपको आवश्यकता होगी:

1. वीएस 2010 SP1
2. विंडोज फोन एसडीके 7.1
3. Caliburn.Micro

एक विंडोज फोन एप्लिकेशन प्रोजेक्ट बनाएं जिसे हम परीक्षण के लिए उपयोग करेंगे।

एक भविष्यवक्ता के बजाय एमवीवीएम या अध्याय

WP7 एप्लिकेशन में स्क्रीन / पेज (विंडोज फोन पेज) का एक सेट होता है, ये स्क्रीन कुछ डेटा का प्रतिनिधित्व करते हैं, उदाहरण के लिए, डीबी में रिकॉर्ड। सवाल यह है कि इस डेटा और UI तत्वों को स्क्रीन पर कैसे जोड़ा जाए।

मान लीजिए कि हम AD समूह में उपयोगकर्ताओं की एक सूची दिखाना चाहते हैं। स्क्रीन का शीर्षक समूह का नाम होगा, और शरीर में उपयोगकर्ताओं की सूची के साथ एक लिस्टबॉक्स होगा। यह कैसे किया जा सकता है? एक सरल लेकिन सबसे अच्छा समाधान नहीं है कि पृष्ठ के शरीर में कुछ ala सही लिखें (* .xaml.cs)

// PageTitle - TextBlock PageTitle.Text = GroupConnector(GroupId).Name; // Users - ListBox Users.ItemsSource = GroupConnector(GroupId).Users; 

यह काम करेगा, लेकिन इस दृष्टिकोण के कई नुकसान हैं, उनमें से कुछ हैं:

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

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

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

WP7 अनुप्रयोगों को विकसित करते समय, MVVM दृष्टिकोण का उपयोग हर जगह किया जाता है। कुछ अपने स्वयं के निर्णय लेते हैं , अन्य तैयार किए गए विकास का उपयोग एक रूपरेखा (उदाहरण के लिए, प्रिज्म और एमवीवीएम लाइट टूलकिट ) के रूप में करते हैं। Caliburn.Micro सिर्फ एक ऐसी रूपरेखा है। यानी यह अच्छा बन्स के एक सेट के साथ MVVM दृष्टिकोण का कार्यान्वयन है।

शुरुआत हो रही है

ठीक है, हमने एक प्रोजेक्ट बनाया, चलो आवश्यक सीएम में प्लग करें (इसके बाद मैं इस शॉर्टकट का उपयोग करूंगा, ताकि हर बार Caliburn.Micro नहीं लिखूं) लाइब्रेरी। ऐसा करने के लिए:

1. प्रोजेक्ट के अंदर फ़ोल्डर CaliburnMicro (या किसी अन्य नाम के साथ) बनाएँ और फ़ाइलों को कॉपी करें Caliburn.Micro.dll , Caliburn.Micro.Extensions.dll और System.Windows.Interactivity.dll से CM वितरण (बिन \ WP71 \ रिलीज़)।
2. संदर्भ में नई फाइलें जोड़ें।

सीएम को काम करने के लिए, आपको अपने बूटस्ट्रैपर को एप्लिकेशन एप्लिकेशन के मुख्य वर्ग पर स्थापित करना होगा। यह आवरण एप्लिकेशन स्थिति (सक्रियण, निष्क्रियता, संक्रमण आदि) के सभी परिवर्तनों के लिए ज़िम्मेदार होगा और, सबसे महत्वपूर्ण बात, हमारे सभी ViewModel वर्गों का वर्णन यहाँ किया जाएगा, लेकिन बाद में और अधिक।

आइए, नमूनाबूटस्ट्रैपर क्लास, फोनबुटस्ट्रैपर वंशज बनाएं और इसे हमारी परियोजना में जोड़ें:

 public class SampleBootstrapper : PhoneBootstrapper { private PhoneContainer _container; protected override void Configure() { _container = new PhoneContainer(RootFrame); _container.RegisterPhoneServices(); AddCustomConventions(); } private static void AddCustomConventions(){} protected override object GetInstance(Type service, string key) { return _container.GetInstance(service, key); } protected override IEnumerable<object> GetAllInstances(Type service) { return _container.GetAllInstances(service); } protected override void BuildUp(object instance) { _container.BuildUp(instance); } } 

इस वर्ग को आपको भ्रमित न करने दें; बाद में इससे हमें केवल कॉन्फ़िगर विधि की आवश्यकता होगी।

अब आपको उस एप्लिकेशन को बताने की आवश्यकता है जिसे आपको नमूनाबूटस्ट्रैपर का उपयोग करने की आवश्यकता है। ऐसा करने के लिए, आपको हमारे बूटस्ट्रैपर के लिंक को छोड़कर वहां से सब कुछ हटाते हुए App.xaml फ़ाइल को संपादित करना होगा:

 <Application x:Class="CaliburnMicroSamples.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:CaliburnMicroSamples="clr-namespace:CaliburnMicroSamples"> <Application.Resources> <CaliburnMicroSamples:SampleBootstrapper x:Key="bootstrapper" /> </Application.Resources> </Application> 

क्योंकि इवेंट प्रोसेसिंग जैसे लॉन्चिंग , एक्टिनेटेड , आदि अब नमूनाबुटस्ट्रैपर पर ले जाते हैं , फिर इसके लिए जिम्मेदार पुराने तरीकों को App.xaml.cs. से हटाया जा सकता है। यानी App वर्ग अब बहुत सरल दिखाई देगा:

 public partial class App { public App() { InitializeComponent(); } } 

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

पहला दृश्यमॉडल

थर्ड-पार्टी फ्रेमवर्क का उपयोग किए बिना और ViewModel का उपयोग किए बिना, यह ViewModel निम्नानुसार बनाया गया है। ViewModel को लागू करने वाला एक वर्ग बनाया जाता है, फिर इसका लिंक PhoneApplicationPage पेज ala के अंदर DataContext को दिया जाता है:

 DataContext = ViewModelsConstructor.GetViewModel(this); 

एक ही बात xaml के साथ की जा सकती है। यह सब काम करने के लिए ViewModel और View तत्वों (UI नियंत्रण) के बाइंडिंग के लिए आवश्यक है।

सीएम में, यह दृष्टिकोण थोड़ा अलग है। संदर्भ को स्वयं निर्धारित करने की आवश्यकता नहीं है, यह रूपरेखा पर ले जाता है। विशेष रूप से DataContext और * .xaml.cs फ़ाइलों के साथ काम करने की कोई आवश्यकता नहीं है, जो आपको विशेष रूप से व्यू और xaml से आगे बढ़ते हुए आदर्श MVVM के करीब पहुंचने की अनुमति देता है। सीएम VM (ViewModel) का वर्णन करने के लिए एक घोषणात्मक दृष्टिकोण का उपयोग करता है, जिसे मैं बाद में प्रदर्शित करने का प्रयास करूंगा।

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

 public class MainPageViewModel : Screen { public MainPageViewModel() { } } 

अंतिम चीज़ जो हमारे VM को Bootstrapper'e में पंजीकृत करना है। ऐसा करने के लिए, नमूना विधि में, नमूना विधि में, बस निम्नलिखित कोड जोड़ें:

 _container.PerRequest<MainPageViewModel>(); 

और वह सब है! हमारा ViewModel बनाया गया है और इसे बनाए जाने पर CM द्वारा MainPage पेज से जोड़ा जाएगा। PerRequest का मतलब है कि MainPageViewModel क्लास को हर बार MainPage पेज बनाने का अनुरोध किया जाएगा। यदि आप सिंगलटन विधि का उपयोग करते हैं, तो MainPageViewModel वर्ग बाद के सभी अनुरोधों पर पुन: उपयोग करेगा।

आइए देखें कि बाध्यकारी गुण कैसे काम करते हैं। ऐसा करने के लिए, हमारे VM वर्ग में PageTitle गुण जोड़ें और इसे कुछ मान निर्दिष्ट करें, उदाहरण के लिए, "नमूना पृष्ठ":

 public class MainPageViewModel : Screen { public string PageTitle { get; set; } public MainPageViewModel() { PageTitle = "sample app"; } } 

और एप्लिकेशन चलाएँ। पृष्ठ का शीर्षक बदल गया है! ऐसा इसलिए हुआ क्योंकि सीएम ने ViewModel और View के बीच के संबंध के सभी सवालों को अपने ऊपर ले लिया और PageTitle संपत्ति को उसके नाम से जोड़ दिया (xaml में इसे भी कहा जाता है)।

Text="{Binding PageTitle, Mode=TwoWay}" डायरेक्ट लिंक निर्देशों (ala Text="{Binding PageTitle, Mode=TwoWay}" ) के माध्यम से परिचित बंधन भी काम करता है, लेकिन आपको Text="{Binding PageTitle, Mode=TwoWay}" स्वीकार Text="{Binding PageTitle, Mode=TwoWay}" होगा कि इसके बिना यह बहुत सरल है।

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

नेविगेशन

उपयोगकर्ताओं और AD से एक समूह के साथ हमारे उदाहरण को याद रखें? यह मान लेना तर्कसंगत है कि किसी समूह के बारे में जानकारी दिखाने के लिए, आपको समूह के बारे में जानकारी कहीं न कहीं प्रेषित करनी होगी। सादगी के लिए, यह उसका नाम है। यह वीएम का "कहीं न कहीं" है, क्योंकि उसे यह जानना आवश्यक है कि दृश्य में आवश्यक डेटा वापस करने के लिए यह समूह क्या है।

इस समस्या को हल करने का मानक तरीका मापदंडों के साथ नेविगेशन है। यानी हम कहते हैं कि हम ऐसी स्क्रीन पर जाना चाहते हैं (इस मामले में, उपयोगकर्ताओं की सूची के साथ), और एक पैरामीटर के रूप में हम समूह पहचानकर्ता को पास करते हैं। यह आमतौर पर इस तरह किया जाता है:

 NavigationService.Navigate(new Uri("/GroupPage.xaml?name=Administrators", UriKind.Relative)); 

और फिर GroupPage.xaml पेज के OnNavigatedTo में , यह पैरामीटर निर्माण द्वारा पुनर्प्राप्त किया जाता है:

 var name = NavigationContext.QueryString["name"]; 

फिर मॉडल को लागू करने वाले वर्ग के लिए (उदाहरण के लिए, कंस्ट्रक्टर के माध्यम से) इसे पारित किया जाता है और फिर इसे DataContext को पास किया जाता है।

सहमत हूं, इस तरह के एक सरल कार्य के लिए सबसे सुंदर समाधान नहीं है।

एक अन्य लोकप्रिय तरीका PhoneApplicationService.Current.State का उपयोग करके साझा किए गए डेटा का आदान-प्रदान करना है:

 PhoneApplicationService.Current.State["name"] = "Administrators"; 

या बस अनुप्रयोग वर्ग के अंदर वैश्विक चर के माध्यम से, इसके उदाहरण का लाभ Application.Current के माध्यम से कहीं भी प्राप्त किया जा सकता है।

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

और यहाँ यह कैसे करना है:

 _navigationService.UriFor<GroupPageViewModel>() .WithParam(x => x.Name, "Administrators") .Navigate(); 

GroupPageViewModel - VM, सादृश्य द्वारा बनाई गई, जैसा कि हमने MainPageViewModel, सार्वजनिक संपत्ति के नाम के साथ किया था:

 public class GroupPageViewModel : Screen { public string Name { get; set; } } 

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

यह है कि MainPageViewModel वर्ग के लिए एक INavigationService उदाहरण प्राप्त करना कैसा दिखता है, CM केवल MainPageViewModel निर्माता के लिए INavigationService ऑब्जेक्ट पास करता है:

 public class MainPageViewModel : Screen { private INavigationService _navigationService; public string PageTitle { get; set; } public MainPageViewModel(INavigationService navigationService) { PageTitle = "sample app"; _navigationService = navigationService; } } 

लाभ स्पष्ट हैं:

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

विपक्ष:

1. जटिल प्रकारों को इस तरह से पारित नहीं किया जा सकता है। यहां कोई जादू नहीं है, सीएम WP7 में ऐसा नहीं कर सकते हैं, क्योंकि अपनी क्षमताओं के आधार पर। कार्यान्वयन नेवीगेशन सर्विस (पहले उदाहरण में एक) के मानक कार्यान्वयन पर आधारित है। लेकिन इसे दरकिनार किया जा सकता है यदि आप क्रमांकन का उपयोग करते हैं और सीएम स्रोतों को थोड़ा मोड़ देते हैं।

INotifyPropertyChanged

हम उपयोगकर्ताओं को AD से छोड़ देंगे, और हम एक और उदाहरण पेश करेंगे। मान लीजिए हमारे पास एक मेल प्रोग्राम है, जिसके एक पेज पर बिना पढ़े संदेशों के बैज के साथ उपलब्ध मेलबॉक्सों की एक सूची है।

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

 public class MailboxPageViewModel : INotifyPropertyChanged { private int _unreadCount; public int UnreadCount { get { return _unreadCount; } set { _unreadCount = value; NotifyPropertyChanged("UnreadCount"); } } public event PropertyChangedEventHandler PropertyChanged; public void NotifyPropertyChanged(string propertyName) { if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } 

जैसा कि आप देख सकते हैं, जब UnreadCount प्रॉपर्टी में बदलाव होता है , तो प्रॉपर्टीचैन्ड को यहाँ सिग्नल किया जाता है , जिससे इसके मूल्य के व्यू को फिर से पढ़ना होगा।

इस कोड में दो कमियां हैं:

1. संपत्ति का नाम नाम से निर्धारित होता है, और यह त्रुटियों से भरा होता है।
2. UI थ्रेड से प्रॉपर्टी को अपडेट करते समय, एप्लिकेशन अमान्य क्रॉस-थ्रेड एक्सेस अपवाद के साथ क्रैश हो जाएगा।

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

 public class MailboxPageViewModel : Screen { private int _unreadCount; public int UnreadCount { get { return _unreadCount; } set { _unreadCount = value; NotifyOfPropertyChange(() => UnreadCount); } } } 

CM विधि NotifyOfPropertyChange वर्णित समस्याओं को हल करता है और तुरंत "बॉक्स से बाहर" उपलब्ध है।

CM में, आप BindableCollection वर्ग को भी खोज सकते हैं, जो किसी अन्य वर्ग के गैर- UI थ्रेड से पहुंच के साथ समान समस्याओं को हल करता है जो INotifyPropertyChanged को लागू करता है और ऑब्जेक्ट्स के संग्रह को संग्रहीत करता है, Observatololionion वर्ग। यानी BindableCollection का उपयोग करते समय, आपको यह चिंता करने की ज़रूरत नहीं है कि संग्रह विधियों को किस स्ट्रीम में बुलाया जाता है।

समाधि का पत्थर

WP7 के लिए आवेदन लिखते समय डेवलपर्स के पास जो समस्याएं हैं, उनमें से एक है समाधि की स्थिति से बाहर निकलने के बाद आवेदन की स्थिति को पुनर्स्थापित करने की आवश्यकता।

WP7 में, PhoneApplicationService.State , IsolatedStorage, और अन्य समाधान इसके लिए उपयोग किए जाते हैं। अतिरिक्त आवरण के बिना जो काम करना है, वह इतना सुविधाजनक नहीं है। सीएम ने दिया सुरुचिपूर्ण समाधान यदि आप चाहते हैं कि वीएम डेटा कब्र से बच जाए, तो बस वीएम और एंडिंग स्टोरेज नाम से एक क्लास बनाएं। उपयोगकर्ताओं की सूची के साथ हमारे उदाहरण के लिए समूह को GroupPageViewModelStorage कहा जाएगा और यह इस तरह दिखेगा:

 public class GroupPageViewModelStorage : StorageHandler<GroupPageViewModel> { public override void Configure() { Property(x => x.Name) .InPhoneState() .RestoreAfterActivation(); } } 

StorageHandler एक CM वर्ग है जो एक VM के अंदर डेटा संग्रहीत करने के लिए एक रणनीति लागू करता है। इस उदाहरण में, हम कहते हैं कि हम PhoneApplicationService.State के अंदर नाम की संपत्ति बचाना चाहते हैं और पृष्ठ की सक्रियता के साथ-साथ डेटा को पुनर्स्थापित करने की आवश्यकता है।

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

पहले भाग का अंत

यहाँ मुझे महसूस हुआ कि लेख मुझे शुरुआत में अपेक्षा से अधिक मिल रहा है और इसे और अधिक लिखना आवश्यक है। यह एक परिचयात्मक समीक्षा लेख के लिए पर्याप्त से अधिक है, इसलिए मैंने इसे दो भागों में तोड़ने का फैसला किया।

जारी रखने के लिए ...