एंड्रॉइड डिज़ाइन: पृष्ठभूमि लंबी चल रही सेवा या अलार्ममेनगर?

Question

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

• सबक्लास Service और मेरी गतिविधि से इसे बंद कर दें। इसे अग्रभूमि पर सेट करें, स्टिकी और क्या नहीं और उम्मीद है कि यह एंड्रॉइड द्वारा नहीं मारा गया है - और अगर एंड्रॉइड इसे पुन: प्रयास करता है तो सावधानी बरतें (वास्तव में वहां 3 सेवाएं होनी चाहिए ताकि उनके बीच समन्वय गड़बड़ हो)। सेवा में एक धागा शुरू करें (मुझे लगता है कि निष्पादकों के लिए कोई ज़रूरत नहीं है) और इसे Thread.sleep(REGULAR_INTERVAL) है। उठो, डेटा इकट्ठा करें उन्हें एक फाइल में लिखें। संग्रहित जानकारी को प्रसारित करें और इसे चलाने पर होने पर मेरी गतिविधि पर प्रदर्शित करें (जो ब्रॉडकास्ट रिसीवर पंजीकृत होगा)। कुल्ला और while(true) दोहराना। इस
• को बाधित करने का कोई तरीका है मेरी गतिविधि AlarmManager के साथ एक लंबित इंटेंन्टेंट पंजीकृत करें - जो प्रत्येक REGULAR_INTERVAL चलाएगी। मैंने इस दृष्टिकोण के तकनीकी विवरणों में बहुत कुछ नहीं देखा है - लेकिन मुझे आशा है कि मैं इस लंबित इंटेंट को बनाने और एक इंटेंट सेवा चलाने में सक्षम हो जाऊंगा (ऐसा लगता है कि यह थ्रेड मशीनरी मुफ्त में बंद हो रहा है और साथ ही बंद हो रहा है अपने दम पर)। इस दृष्टिकोण के लिए कुछ कंकाल कोड का स्वागत किया जाएगा।

मुझे लगता है कि मुझे दोनों मामलों में साझा प्राथमिकताएं (पहले से ही यह कर चुके हैं) की जांच करने के लिए बूट रिसीवर पंजीकृत करना है और यदि 1 सेवा में शुरू होता है तो 2 मामले में अलार्म ईवेंट के लिए रिसीवर पंजीकृत करते हैं और अलार्म मैनेजर सेट अप करें - यही वह हिस्सा है जिसे मुझे कुछ कंकाल कोड चाहिए।

तो - इससे पहले कि मैं इसे बनाना शुरू कर दूं - जो पसंदीदा दृष्टिकोण होगा?

रिकैप में - ऐप को कुछ फोन गुणों की निगरानी करनी चाहिए और उन्हें तब तक फ़ाइल में लिखना चाहिए जब तक उपयोगकर्ता इसे बंद करने का विकल्प नहीं चुनता।

Answer 1

जबकि मामले 2 में अलार्म घटना के लिए एक रिसीवर रजिस्टर और अलार्म प्रबंधक

आपका रिसीवर की स्थापना की पहले से ही प्रकट के माध्यम से पंजीकृत किया जाएगा।

जो पसंदीदा दृष्टिकोण होगा?

AlarmManager, REGULAR_INTERVAL संभालने रहे (उदा कुछ ही मिनटों में) शालीनता से लंबे समय से आम तौर पर है। आदर्श रूप में, वह अंतराल उपयोगकर्ता-विन्यास योग्य है।

यदि आप अन्यथा सोते समय भी ऐसा करने का इरादा रखते हैं, तो आपका विकल्प # 1 बस काम नहीं करेगा, जब तक कि आप हर समय WakeLock नहीं रखते हैं, जिससे आपके उपयोगकर्ता आपको चेहरे पर शूट करना चाहते हैं एक शॉटगन के साथ।

इस दृष्टिकोण के लिए कुछ कंकाल कोड का स्वागत किया जाएगा।

Here is a sample app गैर _WAKEUP अलार्म (यानी, आप ही होते हैं, जबकि डिवाइस पहले से ही अन्य कारणों के लिए जाग रही है इन घटनाओं की जरूरत है) के लिए AlarmManager के उपयोग का प्रदर्शन है।

Here is a sample app_WAKEUP अलार्म के लिए AlarmManager के उपयोग का प्रदर्शन, my WakefulIntentService का उपयोग कर। WakefulIntentService (या ऐसा कुछ) आवश्यक है क्योंकि AlarmManager डिवाइस को बहुत लंबे समय तक जागृत नहीं करता है (BroadcastReceiver के onReceive() के लिए बस इतना लंबा), और इसलिए आपको डिवाइस को जागने के लिए पर्याप्त कदम उठाने की आवश्यकता है ताकि आप अपने लिए ऐसा कर सकें काम। सैद्धांतिक रूप से, BroadcastReceiver के onReceive() में WakefulIntentService के साथ गड़बड़ी की आवश्यकता से बचने के लिए, आपका काम केवल onReceive() में करने के लिए पर्याप्त हो सकता है। हालांकि, आप इनमें से प्रत्येक बार डिस्क I/O कर रहे होंगे, जो आदर्श रूप से मुख्य अनुप्रयोग थ्रेड पर नहीं किया जाना चाहिए, जहां onReceive() कहा जाता है। और, जब आप अपना डेटा अपलोड करने के लिए जाते हैं, तो आपको WakefulIntentService की आवश्यकता हो सकती है, फिर भी, यदि आप पृष्ठभूमि में भी ऐसा करना चाहते हैं।

Answer 2

पुनरावर्ती कार्य की लंबाई के आधार पर आप कई दृष्टिकोणों में से एक चुन सकते हैं। यह प्रश्न उन पर चर्चा करता है - Scheduling recurring task in Android

अलार्ममेनगर का उपयोग सुविधाजनक है जब कार्य नींद के समय 15 मिनट या उससे अधिक होते हैं। पैटर्न अच्छी तरह से जाना जाता है।

Answer 3

उपयोग दूसरा विकल्प, और intentService + AlarmManager का उपयोग इस उदाहरण http://www.dotkam.com/2011/01/10/android-prefer-alarms-and-intent-receivers-to-services/