दिलचस्प पोस्ट
फ़ोल्डर फिल्टर के साथ गैलरी एचटीएमएल फॉर्म केवल पढ़ने का चयन करें टैग / इनपुट मैं अजगर में भूखंडों की एक श्रृंखला के लिए एक मानक रंग पट्टी कैसे बना सकता हूं Jquery लंबन स्क्रॉलिंग प्रभाव – बहु दिशात्मक आर में प्लॉट पर मानक विचलन दिखाने के लिए त्रुटि बार जोड़ें सीटीपीएस सरणी से आंकड़े प्राप्त करने के लिए Plast को NSDictionary सहेजें कार्य <T> और कार्य <T> के बीच में अंतर क्या है? परिणाम? $ .post और $ .jax के बीच का अंतर? "कॉलबैक नरक" क्या है और यह कैसे और क्यों आरएक्स इसे हल करता है? रूबी पास या संदर्भ से पास है? गेटलाइन ठीक से काम नहीं कर रहा है? कारण क्या हो सकता है? जावा में गहरी पुनरावर्ती से ढेर अतिप्रवाह? कैसे छवि संसाधन से base64encoded स्ट्रिंग बनाने के लिए मैं jquery का उपयोग करके एक पेज रीफ्रेश कैसे खोज सकता हूं?

गतिविधि संदर्भ या एप्लिकेशन संदर्भ को कब कॉल करें?

इन दो संदर्भों के बारे में बहुत कुछ पोस्ट किया गया है .. लेकिन मैं अभी भी इसे सही नहीं मिल रहा हूं

जैसा कि मैंने अभी तक इसे समझ लिया है: प्रत्येक अपनी कक्षा का एक उदाहरण है जिसका मतलब है कि कुछ प्रोग्रामर आपको यह प्रयोग करने की सलाह देते हैं। this.getApplicationContext() जितनी बार संभव हो, किसी भी स्मृति को "रिसाव" न करने के लिए इसका कारण यह है कि अन्य ( Activity इकलौता संदर्भ प्राप्त करना) उस Activity को इंगित करता है जो हर बार उपयोगकर्ता को झुकाता है या ऐप आदि छोड़ देता है। जो जाहिरा तौर पर कचरा कलेक्टर (जीसी) पकड़ नहीं पाता और इसलिए इसका उपयोग करता है बहुत मेमोरी ..

लेकिन क्या कोई भी कुछ अच्छे कोडिंग उदाहरणों के साथ आ सकता है, जहां इसका उपयोग करने के लिए सही बात होगी (मौजूदा Activity उदाहरण के संदर्भ में) और आवेदन संदर्भ बेकार / गलत होगा?

Solutions Collecting From Web of "गतिविधि संदर्भ या एप्लिकेशन संदर्भ को कब कॉल करें?"

getApplicationContext() लगभग हमेशा गलत है। सुश्री Hackborn (दूसरों के बीच) बहुत स्पष्ट है कि आप केवल getApplicationContext() उपयोग करते हैं जब आप जानते हैं कि आप getApplicationContext() का उपयोग क्यों कर रहे हैं और केवल जब आपको getApplicationContext() का उपयोग करने की आवश्यकता है

कुंद होने के लिए, "कुछ प्रोग्रामर" getApplicationContext() (या getBaseContext() getApplicationContext() उपयोग कम हद तक) क्योंकि उनका जावा अनुभव सीमित है। वे एक आंतरिक कक्षा को लागू करते हैं (जैसे, एक Activity में एक Button लिए एक OnClickListener ) और एक Context आवश्यकता है। MyActivity.this उपयोग से बाहर 'वर्ग पाने के लिए, वे एक Context वस्तु प्राप्त करने के लिए getApplicationContext() या getBaseContext() का उपयोग करें।

आप केवल getApplicationContext() उपयोग getApplicationContext() जब आपको पता है कि आपको किसी ऐसी चीज़ के Context ज़रूरत है जो आपके निपटान में किसी अन्य संभावित Context से अधिक समय तक रह सकती है। परिदृश्य में शामिल हैं:

  • getApplicationContext() उपयोग करें यदि आपको किसी Context से बंधे कुछ की आवश्यकता है जो स्वयं को वैश्विक दायरे होगा मैं getApplicationContext() उपयोग करता getApplicationContext() , उदाहरण के लिए, WakefulIntentService , स्थिर WakeLock लिए सेवा के लिए उपयोग किया जा सकता है चूंकि getApplicationContext() स्थिर है, और मुझे इसे बनाने के लिए getApplicationContext() पर पहुंचने के लिए एक Context आवश्यकता है, यह getApplicationContext() का उपयोग करने के लिए सबसे सुरक्षित है getApplicationContext()

  • getApplicationContext() उपयोग करें जब आप किसी Activity से किसी Service लिए बाध्य हैं, यदि आप ServiceConnection onRetainNonConfigurationInstance() को पारित करना चाहते हैं (यानी, बाध्यकारी के लिए onRetainNonConfigurationInstance() ) के बीच Activity उदाहरणों पर onRetainNonConfigurationInstance() । एंड्रॉइड आंतरिक इन ServiceConnections कनेक्शन के माध्यम से बाइंडिंग को ट्रैक करता है और बाइंडिंग बनाने वाले सन्दर्भों के संदर्भ रखता है। अगर आप Activity से बाँधते हैं, तो नए Activity उदाहरण में ServiceConnection एक संदर्भ होगा, जिसमें पुरानी Activity का एक अंतर्निहित संदर्भ है, और पुरानी Activity कूड़ा एकत्र नहीं हो सकती है।

कुछ डेवलपर अपने स्वयं के वैश्विक डेटा के लिए Application कस्टम उप-वर्ग का उपयोग करते हैं, जो वे getApplicationContext() द्वारा प्राप्त करते हैं। यह निश्चित रूप से संभव है मैं स्थिर डेटा सदस्यों को पसंद करता हूं, अगर आपके पास केवल एक कस्टम Application ऑब्जेक्ट नहीं है, तो किसी अन्य कारण के लिए। मैंने एक कस्टम Application ऑब्जेक्ट का उपयोग करके एक ऐप का निर्माण किया और इसे दर्दनाक पाया सुश्री Hackborn भी इस स्थिति के साथ सहमत हैं ।

यहां ये कारण दिए गए हैं कि आप जहां भी getApplicationContext() का उपयोग करें:

  • यह एक पूर्ण Context नहीं है, जो सब कुछ करता है, जो Activity करता है। आप इस Context साथ करने की कोशिश करेंगे कई चीजें असफल होंगी, अधिकतर GUI से संबंधित हैं ।

  • यह मेमोरी लीक बना सकता है, अगर getApplicationContext() का Context आपके कॉल्स द्वारा बनाए गए कुछ चीज़ों पर रखता है, जिसे आप साफ़ नहीं करते हैं एक Activity साथ, अगर कुछ चीज़ों पर यह धारण हो जाता है, एक बार Activity कचरा एकत्रित हो जाती है, तो सब कुछ भी बाहर निकल जाता है। Application वस्तु आपकी प्रक्रिया के जीवनकाल के लिए बनी हुई है।

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

इसके बारे में सोचने और समीक्षा करने के लिए यहां अधिक है:

टोस्ट संदेश के लिए, Google देव मार्गदर्शिका एप्लिकेशन संदर्भ का उपयोग करती है और स्पष्ट रूप से इसका इस्तेमाल करने के लिए कहती है: टोस्ट नोटिफिकेशन

देव मार्गदर्शिका के संवाद अनुभाग में, आप देखते हैं कि एक AlertDialog.Builder एप्लिकेशन संदर्भ का उपयोग करता है, और फिर प्रगति बार गतिविधि संदर्भ का उपयोग करता है यह Google द्वारा समझाया नहीं गया है संवाद

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

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

मैं इस तालिका को विभिन्न प्रकार के संदर्भ जैसे कि अनुप्रयोग संदर्भ (जैसे: getApplicationContext() ) और गतिविधि संदर्भ , का उपयोग करने के लिए एक मार्गदर्शिका के रूप में उपयोग करता getApplicationContext() , BroadcastReceiver संदर्भ :

यहां छवि विवरण दर्ज करें

मूल जानकारी यहाँ अधिक जानकारी के लिए

किस संदर्भ का उपयोग करना है?

दो प्रकार के संदर्भ हैं:

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

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

चलो कुछ मामलों पर विचार करें:

  • MainActivity.this गतिविधि। यह मुख्य गतिविधि संदर्भ को संदर्भित करता है जो गतिविधि वर्ग को बढ़ाता है, लेकिन आधार वर्ग (गतिविधि) संदर्भ श्रेणी भी प्रदान करता है, इसलिए इसका उपयोग गतिविधि संदर्भ प्रदान करने के लिए किया जा सकता है।

  • getBaseContext() गतिविधि संदर्भ प्रदान करता है

  • getApplication() आवेदन संदर्भ प्रदान करता है

  • getApplicationContext() भी आवेदन संदर्भ प्रदान करता है।

अधिक जानकारी के लिए कृपया इस लिंक को देखें ।

जब आप गतिविधि संदर्भ बनाम बनाते हैं, तब के दो महान उदाहरण: अनुप्रयोग संदर्भ का प्रयोग करते समय, या तो एक टोस्ट संदेश या किसी अंतर्निहित डायलॉग संदेश को अनुप्रयोग संदर्भ के उपयोग के रूप में प्रदर्शित करते समय अपवाद उत्पन्न होता है:

 ProgressDialog.show(this, ....); 

या

 Toast t = Toast.makeText(this,....); 

इन दोनों को गतिविधि संदर्भ से जानकारी की आवश्यकता है जो अनुप्रयोग संदर्भ में प्रदान नहीं की गई है।

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

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

ने पाया है कि इन नियमों का पालन न करने वाले कुछ एंड्रॉइड संस्करण / डिवाइस संयोजनों पर समस्याएं हैं उदाहरण के लिए, अगर मेरे पास एक ब्रॉडकास्ट रिसीवर है जो एक प्रसंग दिया गया है और मैं उस प्रसंग को एक अनुप्रयोग संदर्भ में कनवर्ट करता हूं और फिर आवेदन संदर्भ पर रजिस्टर रिसीवर () को कॉल करने का प्रयास करता हूं, ऐसे कई उदाहरण हैं जहां यह ठीक काम करता है, लेकिन कई उदाहरण हैं जहां मुझे मिलते हैं एक रिसीवरकॉलनोटअलेखित अपवाद के कारण दुर्घटना ये दुर्घटनाएं एपीआई 15 से 22 तक के एंड्रॉइड संस्करणों की एक विस्तृत श्रृंखला पर होती हैं। https://possiblemobile.com/2013/06/context/#comment-2443283153

क्योंकि यह गारंटी नहीं है कि नीचे दिए गए सारणी में एप्लिकेशन संदर्भ द्वारा समर्थित सभी कार्यों को सभी Android उपकरणों पर काम किया जाएगा! यहां छवि विवरण दर्ज करें