2010-01-24 6 views
29

में परियोजनाओं के बीच कक्षाओं को साझा करना मेरे पास क्लाइंट < => सर्वर ऐप है जिसे मैं मैक ओएस एक्स के लिए बना रहा हूं, उद्देश्य-सी/कोको और एक्सकोड का उपयोग कर। मैंने अपने दोनों ऐप्स के लिए एक अलग प्रोजेक्ट बनाया है, और मैं उनके बीच कक्षाओं को साझा करने का सबसे अच्छा तरीका सोच रहा हूं। मैंने कई कक्षाएं बनाई हैं जो दोनों के लिए उपयोगी होंगी। अब तक मैं उन्हें चारों ओर कॉपी कर रहा हूं, लेकिन मुझे लगता है कि यह सबसे अच्छा समाधान नहीं है।एक्सकोड/उद्देश्य-सी

मैं कक्षाओं को प्रभावी ढंग से कैसे साझा करूं? क्या मुझे इसे 1 प्रोजेक्ट के रूप में दोबारा करना चाहिए और केवल दो बिल्ड लक्ष्य हैं? मैं यह कैसे करु?

कोई अन्य जानकारी?

धन्यवाद।

उत्तर

12

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

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

मैं वास्तव में, एक भी xcode परियोजना "छत" के नीचे रहने वाले हर संबंधित उत्पाद होने क्योंकि आप अभ्यस्त xcode परियोजनाओं के आसपास कूद करने के लिए है, और यह वास्तव में साझा फ़ाइलों के लिए एससीएम प्रबंधन को सरल की तरह। https://developer.apple.com/library/mac/#featuredarticles/XcodeConcepts/Concept-Targets.html

अपडेट::

यहाँ इस पर एप्पल के डॉक्स के लिए एक लिंक है वहाँ अतिरिक्त परेशानी शामिल जब यह xcode में लक्ष्य विशिष्ट हेडर फाइल को विन्यस्त (यह हमेशा कुछ ... सही है की बात आती है का एक छोटा सा है ?!); उदाहरण के लिए, इस लक्ष्य के लिए "myHeaderA.h" और उस लक्ष्य के लिए "myHeaderB.h" का उपयोग करें। यहां एक शानदार पोस्ट है जो साझा करता है कि यह कैसे करें: controlling which project header file Xcode will include। सावधानी: इस तरह से चीजों को इस तरह सेट करने के बाद, xcode अब आपके किसी भी लक्षित शीर्षलेख फ़ाइलों को खोजने के लिए कोई पथ नहीं जानता है, इसलिए आपको उन्हें मैन्युअल रूप से सेट करना होगा। ऐसा करने के लिए, अपने लक्ष्य पर जानकारी प्राप्त करें पर राइट-क्लिक करें, बिल्ड श्रेणी का चयन करें, फिर "शीर्षलेख खोज पथ" सेटिंग के माध्यम से अपने पथ जोड़ें। रास्ते में खोज की जाती है ताकि आप उन्हें दर्ज कर सकें।

+0

क्या यह अब नए वर्कस्पेस के साथ किया जा सकता है? –

+1

हां - अब मैं एक्सकोड 4.3.2 चला रहा हूं और किसी चीज़ को बदलने की आवश्यकता नहीं है। –

4

साझा वर्गों सहित एक अलग ढांचा बनाने का सबसे अच्छा तरीका है। इसे एक बार संकलित किया जा सकता है और दोनों अनुप्रयोग परियोजनाओं में जोड़ा जा सकता है।

Apple's doc on what are Frameworks देखें।

+2

मेरे अनुभव में, ढांचे केवल कोड के लिए उपयुक्त हैं जिन्हें आपने वास्तव में बंद कर दिया है; जहां आप परिवर्तन की उम्मीद नहीं करते हैं। (और, हकीकत में, ऐसा कभी नहीं होता है। चीजें हमेशा बदलती हैं।) वे कागज़ पर अच्छा लगते हैं, लेकिन ढांचे को मेरे रास्ते में मिलते हैं, वे तेजी से विकास और नवाचार को दबाते हैं (क्योंकि आप नहीं जाना चाहते हैं और ढांचे को बदलना नहीं चाहते हैं आप किसी अन्य ऐप में कुछ तोड़ते हैं) और आमतौर पर कोड साझा करने के लिए एक खराब विकल्प होते हैं जब तक कि आप साल में एक बार अपने पुस्तकालयों को अपडेट नहीं करते (जैसे ऐप्पल)। – Womble

+1

@Womble अच्छी तरह से, ऐसा कुछ भी न बदलें जो शायद किसी अन्य ऐप में कुछ तोड़ सकता है ...यदि आप खुद को ऐसा करना चाहते हैं, तो पुरानी विधि को बहिष्कृत करें और एक नया लिखें ... –

2

सबसे तेज़ समाधान परियोजनाओं में से एक को .h और .m फ़ाइलों के संदर्भों को जोड़ना है। एक्सकोड में "मौजूदा फाइलें जोड़ें" -डिअलॉग में "प्रतिलिपि" - चेकबॉक्स को अनचेक करें। ध्यान रखें कि अगर आप अपनी परियोजना को स्थानांतरित/साझा करते हैं तो आपको संदर्भित फ़ाइलों की प्रतिलिपि बनाने की भी आवश्यकता हो सकती है।

+1

क्या यह स्रोत नियंत्रण के साथ अच्छी तरह से खेलेंगे? मैं अनुमान लगा रहा हूं कि ढांचे का समाधान सीवीएस और दोस्तों के साथ अधिक स्वाभाविक रूप से काम करेगा। – Spina

1

मुझे इस विषय पर एक अच्छा लेख मिला: http://www.clintharris.net/2009/iphone-app-shared-libraries/ यह मेरे प्रश्न का उत्तर देता है जो विशेष रूप से एकाधिक आईफोन ऐप्स साझाकरण कोड के बारे में है। इसमें ढांचे (ऊपर) का उल्लेख नहीं है, इसलिए मैं यह नहीं कह सकता कि उनके सुझाव (एक्सकोड परियोजना संदर्भ) ढांचे के समाधान के अनुकूल हैं।

+0

आईफोन पर इसकी फाइल सिस्टम और साझा लाइब्रेरी प्रतिबंधों के साथ स्थिति बहुत अलग है। –

11

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

यह IMO करने के अन्य तरीकों से अधिक बड़ा लाभ हैं:

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

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

+2

हाय चक, मैं इस दृष्टिकोण पर विचार कर रहा हूं लेकिन मुझे यकीन नहीं है कि "इसमें शामिल प्रत्येक प्रोजेक्ट में इसे शामिल करें" वास्तव में क्या शामिल है। क्या आप एक्सकोड में कुछ करने या एसवीएन बाहरी गुणों की तरह कुछ करने के बारे में बात कर रहे हैं? वास्तव में आप का अर्थ क्या है? धन्यवाद। – Cal

+1

उत्तर चक के लिए धन्यवाद, यह मेरे पास जाने के रास्ते की तरह लगता है। हालांकि, मैं इस विषय पर काफी रूकी हूं। क्या आपके पास अधिक विस्तृत स्पष्टीकरण/उदाहरण के साथ कोई स्रोत है? – Tom

+0

@chuck कोई भी मौका आप एक ट्यूटोरियल में आ गए हैं या आप जो प्रस्ताव देते हैं उस पर लिख सकते हैं? –

2

मेरे पास एक समान समस्या थी, और ऊपर दिए गए स्वीकृत उत्तर से नौसिखिया के लिए समस्याएं हो सकती हैं।

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

मैं एक ऐप्स और एक बंडल प्लगइन के साथ एक परियोजना के लिए किया था, यहां दिए गए चरणों मैं Xcode 6 में पीछा कर रहे हैं:

  1. एक रूपरेखा बनाएँ, पर सभी साझा कोड को कॉपी करें।
  2. ढांचे के मुख्य शीर्षलेख में, सभी साझा कोड के शीर्षलेख शामिल करें।
  3. इसे बनाने के लिए ढांचे का निर्माण करें (उदाहरण के लिए ढांचे की योजना का चयन करें और प्ले पर क्लिक करें)
  4. एप्लिकेशन और प्लगइन बंडल दोनों के बिल्ड चरण अनुभाग पर जाएं और 'लक्ष्य निर्भरता' पर नया ढांचा जोड़ें और 'के साथ लिंक बाइनरी पुस्तकालयों'
  5. , एप्लिकेशन और बंडल में कोड में चौखटे सामान शामिल करने के लिए सिर्फ मुख्य शीर्षक का प्रयोग, और < का उपयोग> बल्कि "से" जैसे अगर आपके ढांचे फू
#import का उपयोग बुलाया गया था

जब आप मुख्य ऐप चलाते हैं तो ढांचे में परिवर्तन स्वचालित रूप से संकलित किए जाएंगे, ताकि आप प्रभाव में पहलू को अनदेखा कर सकें टी वे अलग-अलग लक्ष्य हैं।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^