मैंने एंड्रॉइड के लिए SQLite डेटाबेस प्रोग्रामिंग की है, लेकिन मुझे इसके अलावा कंटेंट-प्रोवाइडर के बारे में कुछ भी नहीं पता है: "जैसा कि मैंने एंड्रॉइड डेवलपर पेज को संदर्भित किया है , एंड्रॉइड एसडीके ने" कंटेंट-प्रोवाइडर "के बारे में बताया, क्योंकि इसका इस्तेमाल डेटा को स्टोर और रिट्रीव करने के लिए किया जाता है।"
परन्तु फिर,
कोई उदाहरण या मदद !!
जवाबों:
मैंने एक प्रमुख अंतर पाया, इस प्रकार है:
डेटाबेस में अपने डेटा को संग्रहीत करना आपके डेटा को बनाए रखने का एक अच्छा तरीका है , लेकिन एंड्रॉइड में बनाए गए एंड्रॉइड-डेटाबेस में एक चेतावनी है जो visibleकेवल उस एप्लिकेशन के लिए है जिसने उन्हें बनाया है। यह कहना है, एक आवेदन द्वारा Android पर बनाया गया एक SQLite डेटाबेस केवल उस एप्लिकेशन द्वारा उपयोग करने योग्य है, अन्य अनुप्रयोगों द्वारा नहीं।
इसलिए, यदि आप need to share data between applications, you need to use the content provider model as recommended in Android.यह लेख सामग्री प्रदाताओं की मूल बातें प्रस्तुत करते हैं और आप एक को कैसे लागू कर सकते हैं।
मुझे यह लेख इस लिंक पर मिला
वास्तव में अच्छी जानकारी प्रदान की।
"सामग्री-प्रदाता" और "SQLite डेटाबेस" के बीच सटीक अंतर क्या है?
ContentProviderएक पहलू है - एक एपीआई जिसे आप कार्यान्वित कर सकते हैं जो अन्य प्रक्रियाओं के लिए डेटाबेस को उजागर करता है। इसे एक तरह से लागू किया जा सकता है जहां डेटा को SQLite डेटाबेस में संग्रहीत किया जाता है, लेकिन यह होना आवश्यक नहीं है।
कौन सा डेटा स्टोर करने के लिए सबसे अच्छा है, कब?
जिसका सार में उत्तर देना असंभव है। आम तौर पर बोलना, जब तक कि किसी चीज का उपयोग करने की आवश्यकता न हो ContentProvider, बस एक डेटाबेस का उपयोग करें।
मैंने उन हजारों उपयोगकर्ताओं के साथ कई अच्छे ऐप बनाए हैं जो उनका उपयोग करते हुए बस SQLite विधियों का उपयोग करते हैं। लेकिन यह कुछ समय पहले था और मुझे मैन्युअल रूप से बहुत सारे कोड लिखने थे जो अब ContentProvider द्वारा आसानी से उठाए जा सकते हैं। वापस तब मैं सामग्री प्रदाताओं का उपयोग करने के पक्ष में नहीं था क्योंकि यह केवल कोड में जटिलता जोड़ने के लिए लग रहा था।
हालाँकि पिछले कुछ वर्षों से, जैसा कि एंड्रॉइड विकसित हुआ है, मैं ContentProvider में स्थानांतरित हो गया हूं क्योंकि यह समय बचाता है और आपको अधिक करने की अनुमति देता है। मैं अब इसका बड़े पैमाने पर उपयोग करता हूं। जब आपके पास एक कंटेंट प्रोवाइडर वर्ग लिखा जाता है, तो आपका जीवन बहुत आसान हो जाता है। ContentProvider के साथ मैं बहुत आसानी से Cursor Loaders, Loader Callbacks और Bulk Inserts से निपट सकता हूं जिसके लिए मुझे अतीत में मैन्युअल रूप से सब कुछ लिखना पड़ा था और फिर भी यह कुशलता से काम नहीं करता था। विशेष रूप से सूची दृश्य को अपडेट करते समय, जो अब स्वचालित रूप से केवल एक नोटिफ़िश () विधि के लिए धन्यवाद अपडेट किया गया है। इसका मतलब है कि अब मुझे अपने स्वयं के श्रोताओं को टाइप करने की ज़रूरत नहीं है और सूची दृश्य और एडेप्टर में सामग्री को मैन्युअल रूप से अपडेट करना है। इसके अलावा, मुझे डेटाबेस खोलने या बंद करने या मेमोरी लीक के बारे में चिंता करने की आवश्यकता नहीं है। यह सभी सामग्री प्रदाता द्वारा नियंत्रित किया जाता है। एकमात्र समस्या जो एक बार मेरे सामने आती है वह यह है कि आप ContentProviders में कुछ जटिल प्रश्न नहीं कर सकते हैं। इस मामले में आप अभी भी कच्चे प्रश्नों का उपयोग कर सकते हैं और पुराने जमाने के मैनुअल इंटरेक्शन का उपयोग स्क्लाइट के साथ कर सकते हैं।
यदि आपने पहले अपना खुद का DbAdapter, हेल्पर और ऑब्जर्वर लिखा है, तो आप सब कुछ ContentProvider में बदलने के लिए समय व्यतीत किए बिना सुरक्षित रूप से अपने नए ऐप्स पर ले जा सकते हैं। लेकिन अपने अनुभव के आधार पर, मैं ContentProvider को स्थानांतरित करने की अत्यधिक सलाह दूंगा। इसकी आदत पड़ने में कुछ समय लगेगा, लेकिन एक बार जब आपको इसके साथ अनुभव हो जाता है, तो आप इसके साथ बने रहेंगे।
UPDATE 2017 मैंने अब Realm पर स्विच कर लिया है , किसी भी प्लेटफ़ॉर्म पर डेटाबेस का उपयोग करने का बेहतर तरीका। इसे सीखने में कुछ घंटे बिताएं और अपने ऐप डेवलपमेंट करियर में अनगिनत घंटे बचाएं।
डिफ़ॉल्ट रूप से सामग्री प्रदाता थ्रेड सुरक्षित नहीं हैं। यदि आपके पास सामग्री प्रदाता का उपयोग करने वाले कई धागे हैं, तो आप कई अलग-अलग अपवादों को फेंकने और अन्य डेटा असंगतियों को देख सकते हैं। इसे ठीक करने का सबसे आसान तरीका सामग्री प्रदाता द्वारा उजागर किए गए प्रत्येक सार्वजनिक तरीकों पर सिंक्रनाइज़ कीवर्ड का उपयोग करना है।
इस तरह एक समय में केवल एक धागा ही इन विधियों तक पहुंच सकता है।
मुझे आवेदन द्वारा आंतरिक रूप से उपयोग किए जाने वाले डेटाबेस में बाइनरी फ़ाइलों से डेटा आयात करने के लिए नए सर्वल मैप्स एप्लिकेशन की आवश्यकता है। ऐसा करने के लिए और बाकी एप्लिकेशन के साथ अच्छा खेलने के लिए यह सबसे अच्छा है:
आयात करने के लिए एक नया धागा स्पॉन करें ताकि अन्य धागे प्रतिकूल रूप से प्रभावित न हों, विशेष रूप से यूआई को अपडेट करने के लिए थ्रेड प्रभारी; और अन्य धागे देने के लिए प्रत्येक आयात के अंत में संक्षेप में रोकें जो कि संकलित विधियों को एक मौका से अधिक उपयोग करने की आवश्यकता है।
जिस तरह से एंड्रॉइड में सामग्री प्रदाता काम करते हैं, वह आपके बाकी कोड और अंतर्निहित डेटाबेस के बीच अमूर्तता की एक परत प्रदान करता है। यह मुख्य रूप से इस तथ्य के कारण है, जहां तक मैं बता सकता हूं, कि सामग्री प्रदाता डेटाबेस के अलावा अन्य स्थानों से डेटा तक पहुंच सकते हैं।
इसका अर्थ है कि आप अंतर्निहित डेटाबेस पर कच्चे SQL प्रश्नों को निष्पादित नहीं कर सकते हैं और आपको क्वेरी विधि जैसे विभिन्न तरीकों से पारित चर का उपयोग करके SQL क्वेरी के विभिन्न घटकों को निर्दिष्ट करने की आवश्यकता है। यदि आपके पास एक ऐसा कार्य है जो उस तरीके से फिट नहीं बैठता है जो SQL एक सामग्री प्रदाता द्वारा संभाला जाता है तो आपके पास दो विकल्प हैं:
क्वेरी के बारे में बाद में सोचें, हो सकता है कि आपको वह डेटा मिल सके, जिसे आपको वैकल्पिक प्रश्नों की आवश्यकता है और कर्सर से परिणाम प्राप्त कर रहे हैं; और डेटा को सामान्य रूप से एक्सेस करने के लिए एक यूआरआई का उपयोग करें और एक विशेष यूआरआई जो उन कार्यों के लिए एक विशिष्ट क्वेरी से मेल खाता है जिनके पास विकल्प नहीं हैं।
मुख्य अंतर यह है: जब आपके ऐप को किसी अन्य ऐप को जानकारी साझा करने की आवश्यकता होती है, तो सामग्री-प्रदाता का उपयोग करें। SQLite केवल एप्लिकेशन के लिए डेटा संग्रहीत करता है जो इसे बनाता है
मैंने उसी संदेह की तलाश में यह उत्तर पढ़ा , इसलिए इसे साझा करने के बारे में सोचा। य़ह कहता है -
आंतरिक रूप से बदलने में आसान बनाने के लिए अपने डेटा पर अतिरिक्त स्तर प्रदान करना अच्छा अभ्यास है। क्या होगा यदि आप बाद के समय में अंतर्निहित डेटाबेस संरचना को बदलने का निर्णय लेते हैं? यदि आप एक ContentProvider का उपयोग करते हैं, तो आप इसके भीतर सभी संरचनात्मक परिवर्तन शामिल कर सकते हैं, जैसे कि यदि आप एक का उपयोग नहीं करते हैं, तो आपको कोड के सभी क्षेत्रों को बदलने के लिए मजबूर किया जाता है जो संरचनात्मक परिवर्तनों से प्रभावित होते हैं। इसके अलावा, डेटाबेस में निम्न-स्तरीय पहुँच के साथ अपने कोड को लिटाने के बजाय डेटा तक पहुँचने के लिए समान मानक API का पुनः उपयोग करने में सक्षम होना अच्छा है।
इसलिए, सामग्री प्रदाता का उपयोग करना एक अच्छा विचार होगा।
उन्नत सामग्री प्रबंधन प्रणाली के बारे में सोचो। प्रत्येक ऑब्जेक्ट (पृष्ठ, छवि, समाचार लेख, ईवेंट आइटम, आदि) में एक सामग्री, एक पता, उपयोगकर्ता की अनुमति है, और सिस्टम के विभिन्न हिस्सों से इसके साथ बातचीत करने के तरीके हैं। सामग्री प्रदाता Android के लिए ऐसा करते हैं। अब आप उन फ़ाइलों या छवियों को साझा कर सकते हैं जिन्हें आपने अपने एप्लिकेशन में संग्रहीत किया हो। आप कस्टम श्रॉबल ऑब्जेक्ट भी बना सकते हैं, जैसे कि बिजनेस कॉन्टैक्ट्स, एडिटेबल नोट्स इत्यादि। और किसी अन्य एप्लिकेशन से खोलने पर ऐसी ऑब्जेक्ट से निपटने के लिए सुरक्षा और डिफ़ॉल्ट एप्लिकेशन निर्दिष्ट करें।
एक अंतर यह है कि सामग्री प्रदाताओं को सामग्री पर्यवेक्षकों के लिए मंच समर्थन प्राप्त है। SQLite डेटाबेस के लिए अपने स्वयं के अवलोकन पैटर्न को लागू करने की आवश्यकता है।