2011-11-13 20 views
5

मेरे पास एक एंड्रॉइड ऐप है, जिसमें गतिविधियां पृष्ठभूमि में चलने वाले लंबे समय तक चलने वाले ऑपरेशन को आग लगती हैं। ये ऑपरेशन किए जाने पर क्रियाकलापों के साथ बातचीत करते हैं। मैं एक ऐसा घटक विकसित कर रहा हूं जो गतिविधि/लांग-रनिंग-टास्क युग्मन को नियंत्रित करता है, गतिविधियों को नष्ट और पुनर्निर्मित करने का ख्याल रखता है।लंबे समय से चल रहे एंड्रॉइड 'सेवा'

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

अब समस्या। गतिविधि एक स्टार्ट अप, सेवा से जुड़ा हुआ है और serviceApi.runTask (...) पर कॉल करता है। गतिविधि ए को तब नष्ट कर दिया जाता है (क्योंकि उपयोगकर्ता फोन को फ्लिप करता है, उदाहरण के लिए) और गतिविधि ए 'के रूप में बनाया गया। ए 'फिर सेवा के लिए फिर से बांधता है, अपने अस्तित्व की घोषणा करता है और सब कुछ अच्छी तरह से चलना चाहिए।

सिवाय इसके कि मेरी सेवा नष्ट हो गई है। जब गतिविधि ए नष्ट हो जाता है, तो यह सेवा से अनबाइंड होता है। एंड्रॉइड देखता है कि कोई और ग्राहक नहीं हैं, और सेवा को मारता है। जब गतिविधि ए 'बनाया जाता है, तो सेवा फिर से बनाई जाती है, और मैं पुरानी सेवा के सब कुछ खो देता हूं।

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


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

उत्तर

7

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

सही।

एंड्रॉइड संसाधन कम होने पर चिपचिपा सेवाओं को मार सकते हैं।

भी सही। सभी "चिपचिपा" का अर्थ यह है कि एंड्रॉइड सेवा को पुनरारंभ कर सकता है।

सेवा को मारने से एप्लिकेशन खराब हो जाएगा, और मेरे पास यह नहीं हो सकता है।

एक ऐसी सेवा बनाना असंभव है जो हमेशा के लिए चलाने की गारंटी है।शुरुआत करने वालों के लिए, जब भी वे चाहते हैं, उपयोगकर्ता आपकी सेवा से छुटकारा पा सकते हैं, क्योंकि उपयोगकर्ता ऐसे डेवलपर्स से घृणा करते हैं जिनके पास हमेशा के लिए चलने वाली व्यर्थ सेवाएं होती हैं। अनन्त सेवाओं को लिखना केवल कुछ ही मामलों में जरूरी है; अन्यथा, यह सिर्फ मैला प्रोग्रामिंग है।

एकमात्र समाधान जो मैं देख सकता हूं वह सेवा के लिए सिंगलटन का उपयोग कर रहा है। और फिर यह वास्तव में एक एंड्रॉइड सेवा नहीं है, केवल एक उदाहरण है जो हर किसी के लिए सुलभ है। क्या यह एंड्रॉइड में फंस गया है?

प्रक्रिया समाप्त होने पर सिंगलेट्स (ए.के.ए., स्थिर डेटा सदस्य) चले जाएंगे। अंततः प्रक्रिया समाप्त हो जाएगी, खासकर अगर कोई सक्रिय सेवाएं नहीं हैं और आपकी कोई भी गतिविधियां अग्रभूमि में नहीं हैं ..

+0

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

0

आपको लगातार सेवा बनाना है। this manual का संदर्भ लें।

कुछ शब्दों में - bindService पर कॉल न करें, startService पर कॉल करें।

1

कॉल स्टार्ट सेवा और ऑनस्टार्ट कमांड में START_STICKY लौटें। इसे सेवा जारी रखना चाहिए।

तुम भी अग्रभूमि सेवाओं पर गौर कर सकते हैं:

http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)

+0

संपादित टेक्स्ट देखें। – zmbq

+0

मैंने ऐसा ही किया लेकिन पृष्ठभूमि में ऐप की हत्या के दौरान काम नहीं कर रहा था? –

संबंधित मुद्दे

 संबंधित मुद्दे