वहाँ कैसे xcode में किसी व्यक्ति के समाधान को व्यवस्थित करने के लिए किसी भी सर्वोत्तम प्रथाओं हैंएक्सकोड समाधान संगठन सर्वोत्तम प्रथाओं और दिशानिर्देश क्या हैं?
यह जड़ से पल में मेरी है:
मेरा है:
Main application
Model
Singletons
Helper+managers
Controllers // I keep nibs with their respective class files
View
Resources
images
plists
// ... groups from other types of resources if needed
Supporting files
Unit tests
Frameworks
पुन: प्रयोज्य कोड के लिए iOS पर मैं स्थिर पुस्तकालयों का उपयोग और Xcode कार्यक्षेत्र में अलग परियोजनाओं के रूप में इन जोड़ें। यहां तक कि तृतीय-पक्ष कोड के लिए, यदि कोई स्थिर लाइब्रेरी लक्ष्य नहीं है, तो मैं एक बना देता हूं। इस तरह, मैं तीसरे पक्ष के कोड का इलाज उसी तरह करता हूं जैसा कि मैं अपने पुस्तकालय कोड का इलाज करता हूं। इसके अलावा, मुझे तीसरे पक्ष के कोड के संस्करण के बारे में चिंता करने की ज़रूरत नहीं है।
मुझे यह पता चला है कि कोड के फ़ाइल सिस्टम संगठन को कम से कम कुछ स्तर तक एक्सकोड दर्पण करना महत्वपूर्ण है। मैंने this blog post पढ़ने के बाद इस अभ्यास को अपनाया। मैं ऊपर सूचीबद्ध किए गए स्तरों के नीचे ऐसा नहीं करता हूं, हालांकि। उदाहरण के लिए, जब आप github पर कोड साझा करते हैं, यह इससे मदद करता है। डाउनलोडर या योगदानकर्ताओं को आपके सभी स्रोतों के माध्यम से एक निर्देशिका में डालने की बजाय, इसे कार्यात्मक बाल्टी में व्यवस्थित किया गया है। मैंने कुछ परियोजनाएं देखी हैं जहां एक्सकोड संगठन ठीक है, लेकिन फ़ाइल सिस्टम में प्रत्येक एकल स्रोत फ़ाइल को एक निर्देशिका में डाला जाता है।
हालांकि कोई विशेष विधि नुकसान से रहित हो सकता है, यहाँ है कि हम क्या आवेदन कोर या मॉडल के लिए उपयोग
फ़ोल्डर है। इसमें के लिए उप-फ़ोल्डर शामिल हैं जो किसी भी तृतीय पक्ष पुस्तकालयों का उपयोग करते हैं और विशेष मॉडल कक्षाओं के लिए फ़ोल्डरों का उपयोग करते हैं। उदाहरण के लिए वेब सेवा हैंडलिंग के लिए फ़ोल्डर होगा।
एक प्रमुख मॉड्यूल जो वर्ग फ़ाइलों, महत्वपूर्ण व्यक्ति और संसाधनों से युक्त प्रत्येक स्क्रीन के लिए उप-फ़ोल्डर (इस जरूरत के अनुसार अधिक उप-फ़ोल्डर शामिल हो सकते हैं) को शामिल किया जाएगा के लिए फ़ोल्डर। दूसरा प्रमुख मॉड्यूल और इतने पर के लिए
फ़ोल्डर ..
यह मॉडल हमें एक प्रमुख उद्देश्य में कार्य करता। हमारे एप्लिकेशन कोर में लॉगिंग, डेटा एन्क्रिप्शन/डिक्रिप्शन इत्यादि जैसी चीजें हैं, इसलिए हमारे द्वारा विकसित कई अनुप्रयोगों के लिए इसे बदलने की संभावना बहुत कम है। इसी तरह कुछ ऐसे अनुप्रयोग होंगे जिनके लिए प्रमुख मॉड्यूल की कार्यक्षमता की आवश्यकता होगी और कुछ अन्य चीजें शामिल होंगी। इसलिए इन तीन फ़ोल्डर समूहों को उपversण पर अलग भंडार के रूप में बनाए रखा जाता है।
अब जब हम एक नई परियोजना शुरू करते हैं, तो हम इस परियोजना के लिए एक नया भंडार बनाते हैं और आवश्यकता के अनुसार एप्लिकेशन कोर रिपोजिटरी और अन्य प्रमुख मॉड्यूल भंडारों से लिंक करते हैं। तो एक परियोजना टीम द्वारा आवेदन कोर में किए गए किसी भी बदलाव, अन्य परियोजनाओं में भी दिखाई देता है। अन्य प्रमुख मॉड्यूल के साथ ही। यह हमें पूर्ण मॉड्यूलरिटी प्राप्त करने में भी मदद करता है।
बेशक इस योजना के नुकसान होंगे, लेकिन इस योजना ने हमें कई वर्षों से अच्छी तरह अनुकूल किया है :)