ये मजेदार ब्राडकास्टाइवर्स

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

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

इस तरह के कार्यक्रम का विशिष्ट उप-कार्य मोबाइल इंटरनेट, वाई-फाई, ब्लूटूथ की बदलती स्थिति के बारे में सूचनाएं प्राप्त करना और उन्हें पैरानॉयड अभिभावक की डिग्री के आधार पर ब्लॉक करना है। जैसा कि आप जानते हैं, Android में इस तरह के अलर्ट BroadcastReceiver माध्यम से लागू होते हैं। इसके अलावा, यह कोई रहस्य नहीं है कि आप रिसीवर को दो तरीकों से पंजीकृत कर सकते हैं: AndroidManifest.xml फ़ाइल में और सीधे Activity (या Service , एक विकल्प के रूप में) में। आइए दोनों तरीकों पर विचार करें।

AndroidManifest.xml

/* */ । आगे की हलचल के बिना, हम उन घटनाओं की सदस्यता लेंगे जिनकी हमें ज़रूरत है। इस मामले में, यह किसी भी तरह के परिवर्तन से युक्त है ।

 <receiver android:name="com.demo.WiFiReceiver" android:enabled="true" > <intent-filter> <action android:name="android.net.wifi.WIFI_STATE_CHANGED" /> </intent-filter> </receiver> <receiver android:name="com.demo.DataReceiver" android:enabled="true" > <intent-filter> <action android:name="android.net.conn.CONNECTIVITY_CHANGE" /> </intent-filter> </receiver> <receiver android:name="com.demo.BluetoothReceiver" android:enabled="true"> <intent-filter> <action android:name="android.bluetooth.adapter.action.STATE_CHANGED" /> </intent-filter> </receiver> 

संबंधित वर्ग बहुत अधिक जटिल नहीं लगते हैं और सामान्य रूप से निम्न टेम्पलेट के अनुरूप होते हैं:

 public class MyReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { Log.d("MyReceiver", "onReceive"); } } 

हम कॉल के कालक्रम में रुचि रखते हैं, इसलिए हम प्रमुख घटनाओं की शुरुआत का लॉग रखेंगे।
LogCat में चेहरे पर परिणाम:

आवेदन	टैग	टेक्स्ट
com.habr	MyActivity	onCreate

और उदाहरण के लिए हमें मिलते-जुलते विकल्प में से प्रत्येक पर / बंद:

आवेदन	टैग	टेक्स्ट
com.habr	WiFiReceiver	onReceive

सब कुछ बहुत पूर्वानुमान है।

सॉफ्टवेयर।

सबसे पहले, हम ब्लूटूथ के उदाहरण का उपयोग करके यह सरल चाल करेंगे।

 @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); Log.d("MyActivity", "onCreate"); } @Override protected void onResume() { super.onResume(); receiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { Log.e("BluetoothReceiver", "onReceive"); } }; registerReceiver(receiver, new IntentFilter(BluetoothAdapter.ACTION_SCAN_MODE_CHANGED)); } @Override protected void onPause() { super.onPause(); unregisterReceiver(receiver); } 

व्यवहार पिछले लॉन्चों के समान होगा और कई लोगों ने शायद पहली बार सोचा था कि "क्यों, क्या वह हमें डॉक्टर नहीं बनाता है और वह यहां पर WifiManager.WIFI_STATE_CHANGED_ACTION इलाज करता है?", लेकिन WifiManager.WIFI_STATE_CHANGED_ACTION या ConnectivityManager.CONNECTIVITY_ACTION को कार्रवाई बदलकर समान कोड चलाने का प्रयास करें। ConnectivityManager.CONNECTIVITY_ACTION और यहां, एंड्रॉइड के लोगों से नमस्ते, आप पाएंगे कि LogCat निम्नलिखित दिखाता है:

आवेदन	टैग	टेक्स्ट
com.habr	MyActivity	onCreate
com.habr	WiFiReceiver	onReceive
com.habr	DataReceiver	onReceive

वास्तव में, इसका मतलब यह है कि onReceive दोनों रिसीवरों को तुरंत onReceive गया था, आम तौर पर संबंधित विकल्पों की स्थिति की परवाह किए बिना, और केवल ब्लूटूथ ने सही ढंग से व्यवहार किया।

निष्कर्ष

एक साधारण स्थिति की कल्पना करें: एप्लिकेशन का कार्य इंटरनेट को तोड़ना है। एप्लिकेशन इंस्टॉल करते समय, यह चालू या बंद हो सकता है। यदि यह पहले से ही चालू है और आप AndroidManifest.xml माध्यम से पंजीकरण कर रहे हैं, तो आप, बस सुनिश्चित करने के लिए, रिसीवर को स्वयं से अवरुद्ध कोड को कॉल करना होगा, क्योंकि आपको सिस्टम द्वारा अधिसूचित नहीं किया जाएगा और यह सही है, क्योंकि आपको दोपहर के भोजन के लिए देर हो गई थी, जब आप और आपका एप्लिकेशन सिस्टम में नहीं थे तब भी इसी सूचना को फेंक दिया गया था। यदि आपने सब कुछ प्रोग्रामिक रूप से किया है, तो आपको एक अलग कॉल नहीं करना होगा। फिर, बशर्ते कि मामला ब्लूटूथ के बारे में नहीं है। यदि आप प्रश्न पूछते हैं "आह, सोबस्ना, क्यों नहीं?", इसका उत्तर सबसे अधिक संभावना है "क्योंकि हम कर सकते हैं!" मेरे लिए, यह एक शुद्ध बग है और कोई तर्क नहीं देखा जा सकता है। मुझे उम्मीद है कि यह लेख किसी दिन बचाता है जिसे मैंने हीन मशीन की अवज्ञा के कारण को समझने के लिए मारा था।

उपरोक्त सभी Android के सभी संस्करणों पर पुन: प्रस्तुत किए जाते हैं, जिंजरब्रेड और उच्चतर के साथ शुरू होता है (मैं इसे नीचे परीक्षण नहीं करता)।

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