IPhone से iPad के लिए लिखे गए एप्लिकेशन को पोर्ट करने के लिए सबसे अच्छा, आप केवल अपने लिए तय कर सकते हैं। मैं केवल कुछ व्यंजनों की पेशकश कर सकता हूं जो वेब अनुप्रयोगों के इस विशेष उदाहरण पर उपयोग करने के लिए सुविधाजनक होंगे।
अगला, एक कोड संगठन प्रतिमान प्रस्तावित किया जाएगा, और एसडीके 3.2 में उपलब्ध घटकों पर विचार किया जाएगा। और आप खुद डिज़ाइन पैटर्न सीखेंगे :-)
यह सब डिजाइन के साथ शुरू होता है। आमतौर पर, कई iPhone स्क्रीन एक सिंगल iPad स्क्रीन पर फिट होने की कोशिश करते हैं।
आईओएस प्लेटफॉर्म के लिए प्रोग्राम के लिए यूजर इंटरफेस लिखते समय, मॉडल-व्यू-कंट्रोलर प्रतिमान का उपयोग किया जाता है। हालांकि, यह iPhone और iPad के लिए अनुप्रयोगों को पोर्ट करने और समर्थन करने पर काफी असुविधाजनक है। आप इसके बारे में विकिपीडिया पर पता कर सकते हैं।
छवि दिखाती है कि मॉडल और दृश्य के बीच एक संबंध है, जो मॉडल के पुन: उपयोग की स्वतंत्रता का उल्लंघन करता है। यह नियंत्रक को कुछ हद तक मुश्किल बनाता है, जिसे iPad के लिए फिर से लिखना भी है।
बदले में, मेरा सुझाव है कि पहली बार .net प्लेटफॉर्म पर Microsoft द्वारा पेश किए गए प्रतिमान का उपयोग कर रहा हूं। यह पिछले एक से आया था, नियंत्रक को एक प्रस्तुतकर्ता के साथ बदलकर, जो मॉडल के सभी इंटरैक्शन लेता है और मॉडल के साथ दृश्य के कनेक्शन को तोड़ता है। नतीजतन, मॉडल अधिक सार्वभौमिक हो जाता है और नियंत्रक कोड कम हो जाता है।
लिखित कोड की मात्रा को कैसे कम करें और, तदनुसार, iOS के लिए त्रुटियों की संख्या को कम करें
आपको एक कोड संगठन रणनीति के साथ परियोजना शुरू करनी चाहिए। निम्नलिखित उदाहरण परियोजना सेटिंग्स का उपयोग करते हैं और कोड में एक btContinue बटन दृश्य बनाते हैं। ये विचार iPhone और iPad के लिए भिन्न हैं। जब हम दोनों उपकरणों के लिए दो अनुप्रयोगों को संकलित करते हैं, तो परिवर्तन को मैक्रोज़ द्वारा नियंत्रित किया जाना चाहिए जो संकलन चरण में व्यवहार को बदलते हैं। परिवर्तन संकलित किए जाते हैं और आवेदन में हार्ड-कोड किए जाते हैं। हम #define IPAD का उपयोग करते हैं। हमें दो एप्लिकेशन मिलते हैं: एक आईफोन के लिए, दूसरा आईपैड के लिए
समय-समय पर परिवर्तन की निगरानी की जाती है। हम UIDevice का उपयोग करते हैं। हमें एक आवेदन मिलता है: जो iPhone और iPad दोनों पर चलता है
एक सार्वभौमिक अनुप्रयोग बनाने के मामले में, प्रस्तुति की परिभाषा क्रमशः कोड निष्पादन मोड में होती है, यह ऑपरेशन प्रोग्राम को धीमा कर देगा।
जैसा कि आप इस उदाहरण से देख सकते हैं, दोनों दृष्टिकोण व्यावहारिक रूप से लिखे गए कोड की मात्रा में भिन्न नहीं हैं, लेकिन पहला विकल्प तेजी से काम करना चाहिए।
व्यक्तिगत अनुभव से
लोग बहुत ही सक्रिय रूप से कानूनी सॉफ्टवेयर का उपयोग करते हैं। उदाहरण के लिए, AppStore में प्रोजेक्ट " फाइल कैबिनेट" (मध्यस्थता मामलों की फाइल कैबिनेट) प्रति दिन 100 से अधिक डाउनलोड करता है
मध्यस्थता फ़ाइल लिखते समय, SDK 3.2 में उपलब्ध मानक घटकों का उपयोग करना असंभव था, जैसे कि UISplitViewController और UIPopoverController। उदाहरण के लिए, पूर्व UINavigationController के संचालन का समर्थन नहीं करता है और मुख्य स्क्रीन होना चाहिए। दूसरा घटक iPhone के साथ पिछड़ा संगत नहीं है। बाहर निकलें : अपने घटकों को लिखें। वैसे, तीसरे पक्ष के डेवलपर्स ने पहले ही अपने विकल्प बना लिए हैं। उदाहरण के लिए, हैबे पर एक लेख है
यदि आप चाहें, तो आप iPhone की स्क्रीन से उधार ली गई जानकारी के iPad स्क्रीन पर अधिक से अधिक डाल सकते हैं। बैकवर्ड संगतता परियोजना फ़ाइल कैबिनेट में मौजूद थी, अर्थात्, केस से केस इंस्टेंसेस में संक्रमण का उपयोग करने की सुविधा के लिए, UIPopoverController ड्रॉप-डाउन सूची का उपयोग किया गया था, जो किसी कारण से iPhone पर उपयोग पर प्रतिबंध है, और यह कोड निष्पादन के चरण में प्रकट होता है। बाहर निकलें : अपने घटकों को लिखें।
थोड़ा अभ्यास
आमतौर पर व्यवहार में, प्रस्तुतकर्ता में सीधे एक दृश्य बनता है।
Apple प्रतिमान में, स्क्रीन (दृश्य) को संसाधनों में संग्रहीत किया जाना चाहिए, लेकिन यह बहुत असुविधाजनक है। मॉडल का उल्लेख नहीं करने के लिए, नियंत्रक के साथ संचार को लगातार बनाए रखना आवश्यक है। यह निर्णय लिया गया कि प्रस्तोता में सीधे एक प्रस्तुति तैयार करना सबसे प्रभावी होगा। उसी समय, प्रस्तुतकर्ता के कोड को स्वयं बढ़ाना आवश्यक नहीं है, यहां तक कि इसके विपरीत - इसे कक्षाओं में और यहां तक कि उपवर्गों में भी चुना जा सकता है, जैसा कि एक सूची आइटम के लिए इस उदाहरण में दिखाया गया है।
यह याद रखना चाहिए कि हम कमजोर हार्डवेयर से निपट रहे हैं, जिसके लिए प्रोसेसर समय और, इसके अलावा, मेमोरी बहुत महत्वपूर्ण संसाधन बन जाते हैं। तदनुसार, ऐसी परिस्थितियां हैं जिनमें संसाधनों में प्रतिनिधित्व को संग्रहीत करना उचित है। इसके अलावा, इस विशेष कोड उदाहरण के लिए, यह पूरी तरह से उचित है, क्योंकि इन लिंक की सेवा करने वाले अनावश्यक लिंक और कोड नहीं हैं। फिर भी, xib (nib) में, आप एक UIView स्टोर कर सकते हैं, उदाहरण के लिए, जैसे UITableViewCell:
लेकिन इसका मतलब यह बिल्कुल नहीं है कि विभिन्न iPhone / iPad के कार्यान्वयन के लिए यह xib (nib) संसाधन एकल नहीं हो सकता है!
लोग अक्सर नए से डरते हैं। वे मैक्रोज़ को पुनर्जीवित नहीं करना चाहते और उन्हें नया जीवन देना चाहते हैं, भले ही वे प्रासंगिक हो जाएं। तथ्य यह है कि हम बस उन्हें खाना बनाना नहीं जानते हैं। यह न केवल उपयोगी भोजन है, जैसे दलिया, लेकिन यह भी बहुत स्वादिष्ट है, अगर दादी के जाम के साथ अनुभवी, उदाहरण के लिए। एक इंटरफ़ेस (वर्ग) के क्षेत्र घोषित करने के दो उदाहरणों पर ध्यान दें। उत्तरार्द्ध में, वैसे, पहले की त्रुटि तय हो गई है। लेकिन क्या प्रभाव है: कहीं भी अनुप्रेषित करने की आवश्यकता नहीं है जहां मैं कुछ समान और कॉम्पैक्ट भूल गया, और सबसे महत्वपूर्ण बात, कोड स्पष्ट है!
मैक्रोज़ का अनिवार्य उपयोग (घृणित!)
मैक्रोज़ का वांछनीय उपयोग (यह बेहतर है!)
परिणाम
सबसे पहले, आपको संकलन या निष्पादन स्तर पर दृश्य को परिभाषित करने के लिए परियोजना (ओं) के लिए सेटिंग्स को परिभाषित करने की आवश्यकता है। फिर आपको प्रस्तोता को उनकी बातचीत के तर्क को स्थानांतरित करके मॉडल-व्यू रिश्तों से छुटकारा पाने की आवश्यकता है।
जितना संभव हो हम xib के माध्यम से गठित अभ्यावेदन से छुटकारा पाते हैं, केवल परमाणु जाले छोड़ते हैं उनमें (उदाहरण के लिए, जैसे UIViewTableCell)।
फिर हम मैक्रोज़ को परिभाषित करते हैं जो iPhone / iPad डिवाइस के लिए प्रस्तुति को सीमित करता है। और यह मत भूलो कि उद्देश्य-सी एक "संदेश उन्मुख कार्यक्रम" भाषा है (हम अपना वीसीएल लिखते हैं)।