これらの面白いBroadcastReceivers

AndroidManifest.xml



を介して直接コードで登録するときのBroadcastReceiver



のさまざまな動作に関する少しの観察。 このメモは初心者向けの段階的なガイドではありませんが、同様のレーキを踏む機会がまだない人のために時間を節約することを目的としています。



運命のプロジェクトマネージャーの意向により、無防備な子供たちの利益のためにすべてをブロックするプログラムを書く機会がありました。 私たちは問題の倫理的要素と子供のためにスマートフォンに数百または3ユーロを投じる親の精神的妥当性を無視し、10年前にこのハイテクデバイスをレンガに変えるソフトウェアをうらやましく探します：インターネットなし、SMSなし、通話なし、アプリはありません...未来への希望はありません。 子育てを完全なコントロールに置き換えようとすることは、ぐにゃぐにゃになりやすくするための確実な方法ですが、チュクチはここではソルバーではなく、チュクチはコードライターなので、問題の技術的な側面に注目することをお勧めします。



この種のプログラムの特定のサブタスクは、モバイルインターネット、Wi-Fi、Bluetoothの状態の変化に関する通知を受信し、偏執的な保護者の程度に応じてそれらをブロックすることです。 ご存知のように、Androidのこれらの種類のアラートはBroadcastReceiver



を介して実装されます。 また、2つの方法でレシーバーを登録できることは秘密ではありません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	マイアクティビティ	onCreate

対応するオプションのオン/オフごとに、たとえば次のようになります。

申込み	タグ付け	テキスト
com.habr	WiFiReceiver	onReceive

すべてがかなり予測可能です。

プログラムで。

最初に、 Bluetoothの例を使用してこの簡単なトリックを行います 。

 @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



またはConnectivityManager.CONNECTIVITY_ACTION



変更して同じコードを実行してみてくださいConnectivityManager.CONNECTIVITY_ACTION



と、Androidの皆さん、こんにちはConnectivityManager.CONNECTIVITY_ACTION



は次のように表示されます。

申込み	タグ付け	テキスト
com.habr	マイアクティビティ	onCreate
com.habr	WiFiReceiver	onReceive
com.habr	データ受信機	onReceive

実際、これは、一般に対応するオプションの状態に関係なく、両方のレシーバーがすぐにonReceive



れ、 Bluetoothのみが正しく動作したことを意味します。

おわりに

単純な状況を想像してください。アプリケーションのタスクはインターネットを破壊することです。 アプリケーションのインストール時には、オンまたはオフのどちらでもかまいません。 既にオンになっていて、 AndroidManifest.xml



を介して登録している場合、念のため、 レシーバーからブロッキングコードを呼び出す必要があります。 システムから通知されることはありません。これは正しいことです。昼食に遅れたため、対応する通知は、あなたとあなたのアプリケーションがまだシステムにないときに投げられたからです。 プログラムですべてを行った場合、別の電話をかける必要はありません。 繰り返しますが、ケースはBluetoothに関するものではありません。 「ああ、ソブスナ、どうして？」という質問をすると、答えは「できるから」だろう。 私に関しては、これは純粋なバグであり、ロジックは確認できません。 この記事が、地獄の機械に逆らう理由を理解するために、私が殺した日を誰かが救うことを願っています。



上記のすべては、 Gingerbread以降からAndroidのすべてのバージョンで再現されます（以下ではテストしませんでした）。



通話、SMS、インターネットなどを直接フィルタリングする方法については、誤解しない限り、トピックはすでに部分的にカバーされています（たとえば、 ここ） 。 しかし、もしそれが面白いのであれば、誰かを複製しないように貢献を試みることができます。