कंटेंट प्रोवाइडर का उपयोग कब करें


103

मैं समझता हूं कि सामग्री प्रदाताओं को सार्वजनिक रूप से अनुप्रयोगों के बीच डेटा साझा करने की अनुमति देने के लिए बनाया गया है। हालाँकि, मैं सोच रहा हूं कि क्या किसी के पास केवल अपने ऐप के भीतर सामग्री प्रदाता बनाने के बारे में विचार हैं। क्या ऐसा करने के कोई फायदे होंगे? कोई नुकसान?

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


2
मैंने कंटेंट प्रोवाइडर को लिखना आसान बनाने के लिए एक लाइब्रेरी बनाई। सादे SQLiteOpenHelper लिखने से भी आसान है। github.com/coocood/VContentProvider
Coocood

जवाबों:


59

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

हालाँकि, मैं सोच रहा हूं कि क्या किसी के पास केवल अपने ऐप के भीतर सामग्री प्रदाता बनाने के बारे में विचार हैं।

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


34
मैं आपके औचित्य से सहमत हूं, लेकिन मुझे यह भी लगता है कि यह महत्वपूर्ण है (विशेषकर शुरुआती के लिए) कि एक बार सामग्री प्रदाता के लागू होने के बाद आपको बहुत सारे लाभ मिलते हैं। उदाहरण के लिए, आप CursorLoaderएसिंक्रोनस प्रश्नों को करने के लिए उपयोग कर सकते हैं ... आपके पास एक सिंगलटन इंस्टेंस (ए ContentResolver) का उपयोग प्रश्न करने के लिए है, बेशक आप अपने खुद के लोडर को अपने SQLite डेटाबेस के लिए उपयोग करने के लिए कार्यान्वित कर सकते हैं ... बेशक आप पूरे अनुप्रयोग में एक ही डेटाबेस उदाहरण तक पहुँच को लागू कर सकता है ... और जब तक आप साझा नहीं करना चाहते तब तक एक ContentProvider की आवश्यकता नहीं है
एलेक्स लॉकवुड

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

8
हाँ, आप पूरी तरह से सही हैं लेकिन मुझे अभी भी लगता है कि यह ज्यादातर मामलों में प्रयास के लायक नहीं है। मैंने कम से कम 12 अलग-अलग एंड्रॉइड ऐप (प्ले स्टोर पर प्रकाशित) किए हैं और कभी भी इसकी आवश्यकता नहीं है ContentProvider। वास्तव में, जिस अंतिम ऐप पर हम काम कर रहे थे, वह शुरू में एक के साथ बनाया गया था ContentProviderऔर हमने बस इसे हटा दिया था क्योंकि यह वास्तव में गधे की तुलना में इसका उपयोग करने के लिए दर्द में अधिक है (मैंने इसे बुनियादी ContentProviderएस को लागू करने के लिए आसान बनाने के लिए एक पुस्तकालय भी लिखा है : github.com/casidiablo/persistence लेकिन इसका उपयोग कभी भी मेरे स्वयं के XD नहीं किया था)।
क्रिस्टियन

1
@ क्रिश्चियन सबसे व्यावहारिक सलाह प्रदान करता है। यहां तक ​​कि एंड्रॉइड दस्तावेज़ में कहा गया है कि ContentProviderअगर हमें ज़रूरत नहीं है तो हमें इसका उपयोग नहीं करना चाहिए - "यदि आपको पूरी तरह से आपके आवेदन के भीतर ही डेटाबेस का उपयोग करने की आवश्यकता नहीं है, तो आपको डेटाबेस या अन्य प्रकार के लगातार भंडारण की आवश्यकता नहीं है।" ऊपर दी गई सुविधाओं में से कोई भी। इसके बजाय, आप सेविंग ऐप डेटा पेज पर वर्णित भंडारण प्रणालियों में से एक का उपयोग कर सकते हैं। " अन्यथा, हम सिर्फ इंजीनियरिंग से अधिक हैं।
चोक यान चेंग

सारांश: यदि आप अपना डेटा साझा करने की योजना नहीं बना रहे हैं, तो आप सामग्री प्रदाता से बच सकते हैं लेकिन दूसरी ओर सामग्री प्रदाता आपके जीवन को आसान बनाता है यदि आप अपने ऐप के डेटाबेस को बदलना चाहते हैं। जैसे SQLite से MangoDB तक।
प्रशांत

116

मेरा तर्क है ContentProviderकि यदि आप इसे सार्वजनिक करने का इरादा नहीं रखते हैं तो भी इसका उपयोग करना निश्चित रूप से एक अच्छा विचार है ।

आंतरिक रूप से बदलने में आसान बनाने के लिए अपने डेटा पर अतिरिक्त स्तर प्रदान करना अच्छा अभ्यास है। क्या होगा यदि आप बाद के समय में अंतर्निहित डेटाबेस संरचना को बदलने का निर्णय लेते हैं? यदि आप एक का उपयोग करते ContentProviderहैं, तो आप इसके भीतर सभी संरचनात्मक परिवर्तन शामिल कर सकते हैं, जैसे कि यदि आप एक का उपयोग नहीं करते हैं, तो आपको कोड के सभी क्षेत्रों को बदलने के लिए मजबूर किया जाता है जो संरचनात्मक परिवर्तनों से प्रभावित होते हैं। इसके अलावा, डेटाबेस में निम्न-स्तरीय पहुँच के साथ अपने कोड को लिटाने के बजाय डेटा तक पहुँचने के लिए समान मानक API का पुनः उपयोग करने में सक्षम होना अच्छा है।

इसके अलावा, इस बात की भी संभावना है कि आप भविष्य में अपने डेटा को उजागर करना चाहें। यदि आप एक ContentProviderअप फ्रंट का उपयोग नहीं करते हैं , तो बाद की तारीख में इसे वापस लेना बहुत कठिन होगा।

फिर, एंड्रॉइड के अन्य हिस्से हैं जहां ContentProviderआवश्यक हैं / अनुशंसित हैं जैसे कि SyncAdapterएस का उपयोग करते समय और यदि आप एक ऐप विजेट चाहते हैं जिसमें उदाहरण के लिए डेटा एक्सेस शामिल है।

संक्षेप में, एक ContentProviderअप फ्रंट लिखने में बहुत कम ओवरहेड शामिल है (एक बार जब आपने एपीआई सीख लिया है जो वैसे भी एक अच्छा विचार है) तो यह ऐसा करने के लिए समझ में आता है, यहां तक ​​कि निजी डेटा के लिए भी।


1
मैं और अधिक सहमत नहीं हो सका। यह आपको एक तरह से अपनी डेटा लेयर को अमूर्त करने के लिए मजबूर करता है जो व्यावहारिक रूप से सुनिश्चित करता है कि एक नया डेवलपर यूआई को इसके साथ जोड़े नहीं रख पाएगा।
गेब्रियल

3
एंड्रॉइड सीखने के तुरंत बाद, मैंने ठीक इसी तरह से सोचना शुरू कर दिया। यहां तक ​​कि अगर सार्वजनिक नहीं है, तो आप हमेशा बढ़े हुए अमूर्त और अपने वास्तु निर्णयों के कार्यान्वयन के एकल बिंदु से लाभ उठा सकते हैं। मुझे ContentProviders से प्यार है।
davidcsb

1
आप सामग्री प्रदाता को केवल इस विशेषता के साथ अपने स्वयं के आवेदन के लिए उपलब्ध करा सकते हैं:android:exported="false"
टोबी 1 केनोबी

4
मेरी विनम्र राय में, आप कन्टैंटप्रॉइडर को लागू करने की आवश्यकता के बिना अपने डेटा को पूरी तरह से अमूर्त तरीके से संभाल सकते हैं।
hmartinezd

2
जैसा कि मैं अपने आंतरिक sqlite db (अन्य ऐप्स के साथ कोई इंटरैक्शन नहीं) के लिए एक सामग्रीप्रदाता समाधान को लागू करने के तरीके पर था, मैंने डेवलपर पर टिप्पणी देखी ।android.com/guide/topics/ providers/…
सेल्कुक सिहान

7

ग्रहण के लिए MOTODEV स्टूडियो पर एक नज़र डालें। यह एक विकास वातावरण है जो ग्रहण का विस्तार करता है। उनके पास एक उपकरण है जहां आप डेटाबेस के लिए सामग्री प्रदाता स्वचालित रूप से उत्पन्न कर सकते हैं। यदि कोई सामग्री प्रदाता आपके डेटा को एक्सेस करना आसान बनाता है और इसका प्रदर्शन पर कोई महत्वपूर्ण प्रभाव नहीं पड़ता है तो आगे बढ़ें और इसका उपयोग करें। ज्यादातर स्थितियों में यही होगा।


5

संक्षेप में, आपके डेटा को प्रभावी ढंग से प्रबंधितContent Providers करने में मदद करता है । मैं निम्नलिखित कारणों से उनका उपयोग करने का सुझाव दूंगा।

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

तो भले ही आपको इनमें से किसी भी प्रकार की कार्यक्षमता की आवश्यकता नहीं है, फिर भी आपको भविष्य में इसकी आवश्यकता हो सकती है और अतिरिक्त मील जाने और अभी इसे लागू करने के लिए अच्छा है।


बहुत बढ़िया जवाब। एकल वाक्य का वर्णन ContentProvidersऔर तीन अलग-अलग कारणों से हमें उनका उपयोग क्यों करना चाहिए। कभी-कभी सरल स्पष्टीकरण सबसे अच्छे होते हैं। +1
AdamInTheOculus

4

मैं मानता हूं कि ContentProviders को पकड़ना थोड़ा मुश्किल है, लेकिन वे निश्चित रूप से सहायक हैं, भले ही आप उन्हें आंतरिक रूप से अपने ऐप के लिए उपयोग करना चाहते हों। इसके बारे में सबसे अच्छी बात यह है कि आप उपयुक्त यूआरआई के लिए कंटेंटप्रूवर्स को कस्टमाइज़ कर सकते हैं।

यहां एक परिदृश्य है जहां आपके डेटाबेस में 5 टेबल हो सकते हैं, लेकिन आपको उनका उपयोग करने से पहले उनमें से कुछ को निश्चित क्रम में जोड़ना होगा। और इनमें से प्रत्येक जोड़ के लिए एक सामग्री यूआरआई बनाएं। तब आप प्रत्येक तालिका के रूप में इन URI का उपयोग कर सकते हैं :)

मेरा सुझाव है कि आप सामग्री प्रदाता के साथ आगे बढ़ें, आप यह देखकर चकित होंगे कि यह कितना शक्तिशाली है।


2

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

मैं पसंद करता हूं कि आप दिशानिर्देश का पालन करें क्योंकि एक दिन आपको सामग्री-प्रदाता से जुड़ी कुछ उपरोक्त विशेषताओं को लागू करने की आवश्यकता हो सकती है

वैसे, आप सामग्री प्रदाता जनरेटर का उपयोग करके 5 मिनट से कम समय में डेटाबेस और सीपी का निर्माण कर सकते हैं


1

जैसा कि प्रलेखन में कहा गया है: सामग्री प्रदाता बनाना

यदि आपको पूरी तरह से अपने आवेदन के भीतर उपयोग होता है, तो आपको एक SQLite डेटाबेस का उपयोग करने के लिए एक प्रदाता की आवश्यकता नहीं है।

तो इस ओवरहेड को विकसित करने में परेशान क्यों? आप आसान और तेज विकास चाहते हैं, है ना? तो एब्सट्रैक्शन (SQLiteOpenHelper descendent) की एक परत काफी है।

देखें ओकाम का रेजर बहुत अच्छे कारण के बिना एक संस्था नहीं बनाते हैं।


0

यदि अन्य एप्लिकेशन के साथ डेटा साझा करने की इच्छा नहीं है, तो सामग्री प्रदाता का उपयोग न करें। डेटाबेस ऑपरेशन करने के लिए सरल sqlitedatabase का उपयोग करें। गोपनीय डेटा संग्रहीत करने के लिए सामग्री प्रदाताओं का उपयोग करते समय सावधान रहें क्योंकि आपकी गोपनीय जानकारी अन्य ऐप्स द्वारा एक्सेस की जा सकती है


डिफ़ॉल्ट रूप से सामग्री प्रदाताओं को उजागर नहीं किया जाता है, और उन तक पहुंच प्रतिबंधों को प्रबंधित करना आसान है। गलत सूचना फैलाने के लिए पतन।
TBridges42

2
@ TBridges42 आप गलत हैं। वास्तव में जब तक एपीआई स्तर 17 सामग्री प्रदाता उजागर नहीं हुए थे । और उत्तर के समय तक 25% Android डिवाइस इस व्यवहार से प्रभावित थे और अभी भी आपकी टिप्पणी के समय 10% । इसलिए, यह अधिक अन्य तरीके से है: आपकी टिप्पणी खतरनाक है, क्योंकि आप कुछ सुरक्षित होने के लिए कहते हैं जो कि / तथ्य नहीं था।
मुलमेल

0

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

यदि आपका कन्टैंट प्रदाता SQLite को लिख रहा है, तो डेटा-एट-रीसेट (DAR) को एन्क्रिप्ट करने के लिए मैं SQLcipher का उपयोग करने की सलाह दूंगा और मैं आपको SQLcipher का उपयोग करने की सलाह दूंगा। (मैंने कुछ समाधानों में एक सामग्री प्रदाता का उपयोग किया है और डिबगिंग और परीक्षण के लिए परिचालन मूल्यों का लाइव "स्नैप शॉट" लेने की क्षमता प्रदान की है।)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.