ContentProviders का काला पक्ष

ContentProvider अनुप्रयोगों के बीच डेटा के आदान-प्रदान के लिए एक Android वर्ग है। यह ठीक वैसा ही है जैसा कि javadocs में लिखा गया है : एक सामग्री प्रदाता केवल तभी आवश्यक होता है जब आपको कई अनुप्रयोगों के बीच डेटा साझा करने की आवश्यकता होती है । लेकिन सब कुछ काम करते हुए प्रलेखन कौन पढ़ता है? जाहिर है, केवल वह जो पर्याप्त शंकु भर जाता है, सभी प्रकार की रेक पर कदम रखता है।

इसलिए, इस लेख में, मैं एक एप्लिकेशन के भीतर डेटा स्रोत के रूप में ContentProviders का उपयोग करने के साथ अपने नकारात्मक अनुभव को साझा करना चाहूंगा। ऐसा क्यों है कि एक कार्यक्रम के अंदर डेटा तक पहुंचने के लिए उनका उपयोग अनुचित है?

अपवाद संभालना

मेरी राय में, सबसे महत्वपूर्ण, समस्या यह है कि getContentResolver ()। क्वेरी (..) या तो एक डेटा कर्सर या शून्य देता है। यदि ContentProvider के अंदर कोई अपवाद दिखाई देता है, तो कॉलिंग कोड को इसके बारे में पता नहीं चलेगा। अशक्त के लिए जांच करके आप जो अधिकतम पता लगा सकते हैं, वह यह तथ्य है कि कुछ गलत हुआ था।

एक अनुप्रयोग के अंदर काम करने के लिए, यह दृष्टिकोण निश्चित रूप से उपयुक्त नहीं है, क्योंकि कभी-कभी एक अपवाद उपयोगकर्ता इंटरफ़ेस तक के निम्नतम डेटा स्तर से उगता है। उदाहरण के लिए, वेब सेवा की अनुपलब्धता या प्राधिकरण की त्रुटि के बारे में एक संदेश।

बेशक वहाँ एक समाधान है। आप कर्सर को त्रुटि जानकारी लिख सकते हैं, और इसे कॉलिंग कोड में संसाधित कर सकते हैं। लेकिन यह बहुत ही कृत्रिम समाधान है।

जटिल डेटा संरचनाएं

जब तक लौटा डेटा टैब्लेबल नहीं होता तब तक कर्सर ठीक रहता है। लेकिन क्या होगा अगर एक अधिक जटिल संरचना की आवश्यकता है?

उदाहरण के लिए, एक वेब सेवा पृष्ठ द्वारा डेटा पृष्ठ वापस कर सकती है, जबकि पहले पृष्ठ पर कुछ मेटा जानकारी होगी, कम से कम पृष्ठों की संख्या। आप कई कर्सर को एक में जोड़ सकते हैं, और उन्हें कॉलिंग कोड में वापस इकट्ठा कर सकते हैं। लेकिन यह मॉडल स्तर और प्रस्तुतकर्ता स्तर पर तर्क को बहुत जटिल करेगा।

प्रगति हुई

अक्सर ऑपरेशन की प्रगति को ट्रैक करने की आवश्यकता होती है। उदाहरण के लिए, एक फ़ाइल से बड़ी मात्रा में डेटा पढ़ना। ContentProviders यह क्षमता प्रदान नहीं करते हैं।

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

निष्पादन बंद करो

ContentProvider में निष्पादित कोड को सबसे अधिक संभावना नहीं रोका जा सकता है। यदि आप AsyncQueryHandler का उपयोग नहीं करते हैं, तो सामान्य तौर पर ऑपरेशन पर हमारा कोई नियंत्रण नहीं होगा।

वर्कअराउंड पिछली समस्या के समान ही है - हम एक निजी ध्वज फ़ील्ड सेट करते हैं और जब अनुरोध को रोकने की आवश्यकता होती है तो इसे स्विच करते हैं। अनुरोध में, हम लगातार ध्वज की स्थिति की जांच करते हैं। यह समाधान समान कारणों के लिए फिट नहीं है।

निष्कर्ष

ऊपर से निष्कर्ष, मैं यह कर सकता हूं। यह तभी मायने रखता है जब उनके अंदर परमाणु संचालन किया जाता है, तभी ContentProviders का उपयोग किया जाता है, जो अधिक समय नहीं लेता है और कड़ाई से सजातीय डेटा लौटाता है जिसे अन्य अनुप्रयोगों द्वारा उपयोग किया जा सकता है। यहाँ ContetProviders'ov के अन्य सभी मामलों का उपयोग मुझे अनुचित लगता है।