एंड्रॉइड: सिंगलटन जिसका उपयोग गतिविधि और सेवा

Question

के बीच किया जाता है, मुझे आश्चर्य है कि क्या कुछ एंड्रॉइड क्रियाकलापों और एंड्रॉइड सेवा के बीच सिंगलटन बनाने का बुरा विचार होगा। जहां तक ​​मैं स्थिर क्षेत्रों को जानता हूं, मेरे मामले में सिंगलटन, तब तक उपलब्ध है जब तक पूरी प्रक्रिया जीवित न हो।

मेरी योजना मेरी गतिविधियों और पृष्ठभूमि सेवा के बीच डेटा साझा करने के लिए पार्ससेल के बजाय सिंगलटन का उपयोग करना है। तो मेरी गतिविधि 1 MySingleton.getInstance() को जोड़कर कुछ डेटा जोड़ देगा। AddData (foo); तो मैं अपनी सेवा को सूचित करने के लिए एक इरादा भेजूंगा कि सिंगलटन में नया डेटा जोड़ा गया है। इसके बाद मेरी पृष्ठभूमि सेवा इरादे को संभालेगी और MySingleton.getInstance() को कॉल करेगी। GetLatestData(); तो यह डेटा को संसाधित करेगा (कुछ समय लगता है)। सेवा का नतीजा सिंगलटन का उपयोग करके "पोस्ट" वापस होगा और एक प्रसारण इरादा को आग लगा देगा, जिसे गतिविधि 1 (यदि जीवित) द्वारा संभाला जाता है और गतिविधि 1 सिंगलटन से परिणाम पुनर्प्राप्त करेगा।

क्या आप लोग सोचते हैं कि यह एक बुरा विचार है?

संपादित करें: मैं जो कार्यान्वित करना चाहता हूं वह एक सॉफ्टवेयर की शांति है जो वेब सर्वर से डेटा डाउनलोड करता है और परिणाम देता है। तो मेरी गतिविधि DownloadJob ऑब्जेक्ट बनायेगी। DownloadJob-Object को DownloadScheduler (सिंगलटन) में रखा जाएगा जो सभी डाउनलोड जॉब्स को कतार और प्रबंधित करता है। DownloadScheduler एक ही समय में 5 DownloadJobs चलाने की अनुमति देगा और प्रतीक्षा को संग्रहीत करने के लिए कतार का उपयोग करेगा। प्रभावी डाउनलोड डाउनलोड सेवा (IntentService) द्वारा किया जाएगा, जो इस इरादे से सूचित हो जाता है कि अभी एक नया डाउनलोडजोब अब निष्पादित (डाउनलोड किया जाना चाहिए)। DowanlodService DownloadSchedulers कतार (PriorityBlockingQueue) से अगली नौकरी पुनर्प्राप्त करेगा और DownloadJob.setResult (...) को सेट करके परिणाम लौटाएगा और एक प्रसारण उद्देश्य को सक्रिय करेगा, परिणाम तैयार है, जो डाउनलोडशेड्यूलर द्वारा प्राप्त किया जाएगा जो होगा कतार से नौकरी हटाएं और गतिविधि को पूरा करें कि डाउनलोड पूर्ण हो गया है।

तो मेरे परिदृश्य में मैं डाउनलोड जॉब्स को डाउनलोड जॉब्स को डाउनलोडजोब पार्ससेलबल बनाने और इसे इरादे से पास करने के बजाय डाउनलोड सेवा से एक्सेस करने के लिए उपयोग करता हूं। तो मैं समस्या से बचूंगा, कि मेरे पास स्मृति में दो डाउनलोड जॉब्स हैं (एक "गतिविधि साइट" पर और एक "सेवा साइट" पर)।

कोई सुझाव यह बेहतर कैसे हल करें?

क्या यह सच है कि स्थिर उदाहरण, जैसे डाउनलोडशेड्यूलर (सिंगलटन), एंड्रॉइड सिस्टम द्वारा कम स्मृति पर मुक्त किया जाएगा? तो आवेदन को उपclassing होगा और इस समस्या से बचने के संदर्भ (गैर स्थैतिक) वहाँ पकड़ लेंगे?

Answer 1

इस तरह के सिंगलटन का उपयोग करना एक बुरा विचार नहीं है, लेकिन अगर एंड्रॉइड आपकी प्रक्रिया को रोकने का फैसला करता है तो आप इसकी स्थिति खो देंगे। आप SQL स्थिति डेटाबेस या लगातार कतार में अपने राज्य को संग्रहीत करने पर विचार करना चाह सकते हैं (अच्छे उदाहरण के लिए tape पर एक नज़र डालें)।

Answer 2

एक बेहतर विचार एप्लिकेशन को उपclass करना और वहां किसी भी लंबी जीवित वस्तुएं रखना है। एप्लिकेशन को उप-वर्गीकरण करके आप एप्लिकेशन के स्टार्टअप और शट डाउन को ठीक से संभाल सकते हैं जिसे आप आसानी से सिंगलटन के साथ नहीं कर सकते हैं। इसके अलावा एक एप्लिकेशन एक्टिवेट्स और सर्विसेज का उपयोग करके पार्ससेलबल्स का उपयोग किये बिना आपके प्रोग्राम के मॉडल में एक्सेस साझा कर सकते हैं। और आप सिंगलटन अपने कार्यक्रम में लाने वाली सभी समस्याओं से बच सकते हैं।

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

आप Roboguice जैसे कुछ भी उपयोग करने में देख सकते हैं जो आपके क्रियाकलापों और सेवाओं में साझा मॉडल को इंजेक्ट करता है।

आप इस सहायक हो सकते हैं:

what's design pattern principle in the Android development?

Answer 3

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

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

दूसरी ओर, यदि यह सिंक्रनाइज़ किया गया है, तो आप एआरआर त्रुटि का सामना करने का जोखिम उठा रहे हैं क्योंकि डेटा को पढ़ने वाली गतिविधि को सिंगलटन में डेटा लिखने के लिए सेवा को समाप्त करने के लिए अवरुद्ध किया जा सकता है।

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

मैं नहीं बल्कि एक घटना बस का उपयोग करेंगे जैसे otto या eventbus

संपादित करें:

पृष्ठभूमि (इरादे) के प्रवेश बिंदु के रूप में एक सिंगलटन का उपयोग करते हुए सेवा दृष्टिकोण 2010 के बारे में वर्जिल Dobjanschi talk में सुझाव दिया है एंड्रॉइड के लिए आराम क्लाइंट अनुप्रयोगों का निर्माण।

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

कुछ समय पहले मैंने इसे लाइब्रेरी के शुरुआती बिंदु के रूप में लेने की भी कोशिश की, जो अभी भी अधूरा रहता है। आप स्रोतों को पा सकते हैं here

मैं निश्चित रूप से नहीं करूँगा कि आपके डेटा को सिंगलटन में स्टोर करना है। जिस दृष्टिकोण को मैं पसंद करूंगा वह कुछ स्थिर स्टोरेज (जैसे एसक्यूएल/वरीयताओं/फ़ाइल/सामग्री प्रदाता) में डेटा को स्टोर करना है और क्लाइंट को प्रसारण संदेश के माध्यम से परिवर्तन की जानकारी देना चाहिए (या, यदि आप सामग्री प्रदाता का उपयोग कर रहे हैं, एक पर्यवेक्षक)।

अंत में, कुछ हद तक यह दृष्टिकोण robospice लाइब्रेरी के बाद दृष्टिकोण है, जो काफी परिपक्व दिखता है और कैशिंग जैसे कई रोचक विशेषताओं को भेजता है।