साझा कोड बेस

Question

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

R14 जब से हम, संसाधनों के साथ पुस्तकालय परियोजनाओं का उपयोग कर सकते हैं, जिससे कि जहाँ तक मैं बता सकता है इस विशेष समस्या के लिए एक महान समाधान हो जाएगा। इसलिए मैंने library projects और सामग्रियों पर पढ़ा है, और मुझे यह जानकर उत्सुकता है कि विभिन्न संस्करणों की परियोजनाओं में आवश्यक न्यूनतम मात्रा में क्या फ़ाइलें हैं। इसलिए मेरे प्रश्न हैं;

• मैं साझा परियोजना में कोड के सभी है, और मूल रूप से सिर्फ एक प्रकट साथ नंगे हड्डी परियोजना मिल सकता है?
  • यदि हां, तो क्या मुझे चाहिए? क्या यह वैचारिक रूप से इष्टतम तरीका है? (इसलिए तथ्य यह है कि यह मेरे कोड बेस पर निर्भर करता है)
• मुझे लाइब्रेरी पैकेज नामकरण से कैसे निपटना चाहिए, क्या विशिष्ट नियम हैं?
• क्या ऐसे उपकरण हैं जो दो अलग-अलग परियोजनाओं से कोड की तुलना कर सकते हैं और शायद उन्हें ऑटो-जादुई या ऑटो-मैन्युअल रूप से मर्ज कर सकते हैं, और किसको प्राथमिकता दी जाती है?

Answer 1

1. हाँ, आप एक परियोजना मूल रूप से सिर्फ एक प्रकट निर्दिष्ट ऐप्लिकेशन का नाम, नाम अंतरिक्ष, आइकन आदि, सभी वास्तविक कोड के साथ और पुस्तकालय परियोजना में संसाधनों का 99% है कि हो सकता है।

2. हाँ, मुझे लगता है कि आपको इस दृष्टिकोण का उपयोग करना चाहिए। फ्री/पेड ऐप समस्या से निपटने के लिए पुस्तकालय परियोजनाओं का उपयोग करना बहुत आम है।

3. मुझे नामकरण के साथ कोई समस्या नहीं है, हालांकि आपको एक ही नाम का उपयोग करने से बचने के लिए अलग-अलग परियोजनाओं में किसी भी संसाधन से सावधान रहना चाहिए।

4. मुझे किसी भी उपकरण के बारे में पता नहीं है, और यदि यह मैं था तो मैं यह सुनिश्चित करने के लिए मैन्युअल रूप से ऐसा करना चाहता हूं कि मैं विलय कर रहा हूं और विलय की जरूरतों को अलग रखने की जरूरत है। आपके पास करने के लिए एक महत्वपूर्ण रिफैक्टर है, लेकिन एक बार सभी डुप्लिकेशंस हटा दिए जाने पर मुझे यकीन है कि यह बहुत आसान होगा।

Answer 2

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

मुझे लगता है कि आपके विभिन्न संस्करणों के बीच अंतर नाबालिग हैं, संसाधनों और ऐप नाम और पैकेज जैसी चीजें शामिल हैं, और एक स्विच जो एक मुक्त संस्करण के लिए उन्हें छोड़कर भुगतान संस्करण के लिए कुछ विशेषताओं को चालू करता है।

यहां तक ​​कि यदि यह मामला नहीं है, तो नीचे वर्णित तरीकों में बहुरूपता का उपयोग करके, आपके विभिन्न ऐप्स महत्वपूर्ण तरीकों से भिन्न हो सकते हैं और फिर भी एक सामान्य परियोजना लाइब्रेरी साझा कर सकते हैं।

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

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

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

मैंने कई एंड्रॉइड ऐप्स बनाने के लिए इस दृष्टिकोण का उपयोग किया है जो कुछ क्षमताओं को साझा करता है, और यह मेरे लिए बहुत अच्छा काम करता है।

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

http://winmerge.org/

अगर मैं अपने स्थिति में थे,,, हालांकि मैं केवल इस उपकरण का उपयोग मैन्युअल अंतर की पहचान करने के लिए होगा:

Windows में, एक अच्छा, मुक्त स्रोत कोड ठिकानों की तुलना के लिए उपकरण WinMerge है और लाइब्रेरी प्रोजेक्ट में आपके कोड के रिफैक्टरिंग को स्वचालित करने के लिए इसका उपयोग करने का प्रयास नहीं करेगा। यह आपके अपने (मैनुअल) नियंत्रण के तहत सबसे अच्छा किया जाएगा।

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