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