StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>No offense, but your question is still damn vague. So, I'm going to outline a whole mess of scenarios and hope that one of them actually hits whatever problem you think you have.</p> <h2>Scenario A: Only The Activity</h2> <p>If you only need to receive the broadcast when you have an activity in the foreground, have the activity register the <code>BroadcastReceiver</code> using <code>registerReceiver()</code>. As @MisterSquonk indicated, you would register the receiver in <code>onResume()</code> and unregister it in <code>onPause()</code>. </p> <h2>Scenario B: Activity If In Foreground, Else Other; Ordered Broadcast</h2> <p>If you want the foreground activity to handle the broadcast, but you want something else to happen if that activity is not in the foreground (e.g., raise a <code>Notification</code>), and the broadcast is an ordered broadcast (e.g., incoming SMS), then you would still use the Scenario A solution, but with a higher-priority <code>IntentFilter</code> (see <code>setPriority()</code>). In addition, you would register a <code>BroadcastReceiver</code> via a <code><receiver></code> element in the manifest, with a lower-priority <code><intent-filter></code> for the same broadcast. In the activity's <code>BroadcastReceiver</code>, call <code>abortBroadcast()</code> to consume the event and prevent it from reaching your manifest-registered <code>BroadcastReceiver</code>.</p> <h2>Scenario C: Activity If In Foreground, Else Other; Regular Broadcast</h2> <p>If Scenario B almost fits, but the broadcast you are listening for is not an ordered broadcast, you will need to start with Scenario B. However, have the broadcast that both receivers have in their respective filters be one of your own, using a private action string as @MisterSquonk suggested. In addition, have <em>another</em> <code>BroadcastReceiver</code> registered in the manifest, whose <code><intent-filter></code> is for the real broadcast you're listening for. That receiver would simply call <code>sendOrderedBroadcast()</code> to send out the ordered broadcast that the other receivers are listening on.</p> <h2>Scenario D: Activity Regardless of Foreground</h2> <p>If some activity of yours needs to know about the broadcast, and it does not matter whether or not it is in the foreground, you need to rethink what you mean by that. Usually, this really means that the broadcast affects your data model in some way, in which case your concern should <em>not</em> be to let the activities know, but rather to update your data model, and use your already-existing "let the activities know about the data model change" logic handle the rest.</p> <p>If, however, you are convinced that this is not part of your data model, you can implement Scenario B or Scenario C, plus stick some information in a static data member. Your activities can examine that static data member in <code>onResume()</code> to pick up the information about the broadcast when they return to the foreground.</p> <p>If you're thinking "but, what if my process is terminated between the broadcast and the other activity coming to the foreground?", then your broadcast really <strong>is</strong> updating your data model, per the opening paragraph of this scenario.</p> <p>If you're thinking "but, I want to update an activity that is doing work in the background", then the activity in question is broken. Activities should never be doing work in the background. That work should be delegated to some form of service, and there's a whole related set of scenarios for getting a broadcast to the service.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload