2009-12-10 12 views
8

(संभवतः निम्नलिखित प्रश्न नहीं iPhone विशिष्ट, एक तरफ तथ्य यह है कि हम एक फ्रेमवर्क या गतिशील पुस्तकालय अन्यथा उपयोग होने की संभावना हैं से है।)स्टेटिक (iPhone) पुस्तकालयों, वितरण, और निर्भरता

मैं एक मालिकाना iPhone का निर्माण कर रहा हूँ एक ग्राहक के लिए एसडीके, अपने वेब बैक एंड के साथ एकीकृत करने के लिए। चूंकि हम ग्राहकों को स्रोत कोड वितरित नहीं करना चाहते हैं, इसलिए हमें एसडीके को स्थिर पुस्तकालय के रूप में वितरित करने की आवश्यकता है। यह सब ठीक काम करता है, और मैंने सत्यापित किया है कि मैं पुस्तकालय के खिलाफ नए आईफोन ऐप्स को लिंक कर सकता हूं और उन्हें डिवाइस पर इंस्टॉल कर सकता हूं।

मेरी चिंता तीसरे पक्ष के पुस्तकालयों के आसपास है जो हमारा एसडीके निर्भर करता है। उदाहरण के लिए हम वर्तमान में HTTPRiot और Three20 का उपयोग कर रहे हैं (सटीक पुस्तकालय बदल सकते हैं, लेकिन यह बात नहीं है)। मुझे चिंता है कि इससे विवाद हो सकता है यदि ग्राहक अपने ऐप में इनमें से किसी भी पुस्तकालय (और शायद यहां तक ​​कि विभिन्न संस्करण) का भी उपयोग कर रहे हैं।

इसके आसपास के सर्वोत्तम अभ्यास क्या हैं? क्या हमारी खुद की स्थिर पुस्तकालय से आश्रित पुस्तकालयों के प्रतीकों को बाहर करने का कोई तरीका है (जिस स्थिति में ग्राहकों को हमारे एसडीके के साथ-साथ HTTPRiot और Three20 दोनों को मैन्युअल रूप से लिंक करना होगा)? या क्या कोई अन्य स्थापित तंत्र है?

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

मुझे आशा है कि मेरे सवालों का कोई मतलब ... एक रूबी और जावा पृष्ठभूमि से मुख्य रूप से आ रहा है, मैं नहीं एक लंबे समय के लिए ... (पारंपरिक अर्थों में) संकलित पुस्तकालयों का सामना करना पड़ा है;)

उत्तर

1

यदि यह मैं था तो मैं निर्दिष्ट करता हूं कि उन तृतीय पक्ष पुस्तकालयों के कौन से संस्करण मेरी लाइब्रेरी के साथ इंटरऑपरेट करते हैं। इसके बाद मैं उनके खिलाफ परीक्षण करूँगा, उन्हें दस्तावेज दूंगा, और शायद रिलीज में शामिल उन विशेष संस्करणों के साथ वितरित करूंगा।

दो चीजें जिनके बारे में मुझे चिंता होगी:
- मैं यह सुनिश्चित करना चाहता हूं कि यह मेरे ग्राहक इसे इंस्टॉल करते समय 'केवल काम करता है'।
- मैं उन तृतीय पक्ष पुस्तकालयों के मनमानी भविष्य के संस्करणों के लिए समर्थन की गारंटी नहीं देना चाहता हूं।

ग्राहक के लिए नए संस्करणों में जाने की प्रक्रिया शामिल करना ठीक है, लेकिन यदि कुछ भी काम नहीं करता है तो मैं उम्मीद करता हूं कि ग्राहक उस विकास कार्य के लिए एक मुक्त बग के बजाय वृद्धि के रूप में भुगतान करेगा ठीक करें (जब तक कि आप मूल लाइसेंस/समर्थन व्यवस्था में शामिल न हों)।

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

+0

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

+1

इस बारे में सोचने के लिए समय नहीं था, लेकिन क्या "कमजोर लिंकिंग" आपकी मदद करता है? http://developer.apple।कॉम/आईफोन/समाचार/अभिलेखागार/नवम्बर 200 9/# add3xto2x –

+0

मुझे लगता है कि आप उन्हें संपूर्ण उत्पाद का पुनर्निर्माण करने के लिए एक स्क्रिप्ट दे सकते हैं (जिसमें आपकी लाइब्रेरी और अन्य तृतीय पक्ष शामिल हैं)? जब तक उनके पास (> 2 जीबी) आईफोन एसडीके स्थापित है, तो आप उन्हें एक स्क्रिप्ट दे सकते हैं जो एक साधारण एक्सकोड प्रोजेक्ट के लिए xcodebuild को आमंत्रित करता है जो सबकुछ एक साथ रखता है? हालांकि एक गड़बड़ का बिट। सबसे आसान बात यह है कि संस्करणों को जरूरी बनाना और आग्रह किया कि वे अपग्रेड किए गए पुस्तकालयों के खिलाफ एक नई रिलीज के लिए आपसे संपर्क करें (और भुगतान करें)। आप कीमत में स्वीकृति परीक्षण का थोड़ा सा भी शामिल कर सकते हैं ... आईएमओ यह करने के लिए आपके लिए बिल्कुल उचित है। –

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