LISTENING FOR INTENTS AT RUNTIME

Another method for receiving events that pertain only to your application or for receiv-ing events broadcast by the Android system itself is to listen for the intents at runtime.

Let’s say that your activity would like to show a special screen or take a custom action when the user enables Airplane mode. To do this, you’ll need to create a temporary IntentFilter and an inner BroadcastReceiver object instance.

CREATE A RECEIVER

Let’s add the runtime BroadcastReceiver to the MyActivity class. A Broadcast Receiver is, as you can probably guess, an object with a single onReceive method.

Change the MyActivity class to look like the following:

public class MyActivity extends Activity {

private BroadcastReceiver simpleReceiver=new BroadcastReceiver() { public void onReceive(Context context, Intent intent) {

if(intent.getAction().equals(

//Rest of the Activity is here.

}

THE INTENT CLASS 41

ptg7794906 In this code, you are creating a locally accessible receiver for use within the

activity. When the system calls onReceive, you’ll need to check what the intent’s action is. This is a good idea, as BroadcastReceiver could register for any number of different intents.

When you receive the event that you’re looking for, you’ll use Android’s Toast API to print a simple message on the screen (in this case, the contents of the string named airplane_change). In practice, this might be the time to show a screen indicating that network connectivity is required for the application to run correctly.

TELL ANDROID WHAT YOU WANT TO HEAR

Now that you’ve created a BroadcastReceiver, you can register it with the system.

I’ll show you the code first and then go over what’s happening:

public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);

setContentView(R.layout.main);

IntentFilter intentFilter = new IntentFilter();

intentFilter.addAction(Intent.ACTION_AIRPLANE_MODE_CHANGED);

registerReceiver(simpleReceiver, intentFilter);

}

A TOAST?

A toast is a short message shown to the user in a small pop-up along the bottom of the screen. This is a reference, as far as I can tell, to the short speech given before glasses are raised, tapped together, and then partaken of. As always with toasts, the shorter and simpler the better.

ptg7794906 Again, this is in the original MyActivity class made by the SDK when you

cre-ated the project.

1. In the onCreate method, create an intent filter and add the action Intent.

ACTION_AIRPLANE_MODE_CHANGED to it.

2. Add as many actions to this intent filter as you wish. When your receiver is called, you’ll have to sort out which intent actually triggered the Broadcast Receiver’s onReceive method by calling getAction() on the intent.

3. Test the code by holding the power button down; this will pop up a dialog with several options.

4. Enable Airplane mode. If you’ve done everything right so far, you should see a small message pop up along the bottom of the screen with your alert message in it.

This is going to be the primary way in which your applications will listen for information on the status of the system. Everything from the status of the battery to the status of the Wi-Fi radio is at your fingertips with this tool. You can find out more about what activities you can monitor, with what permissions, by looking in the Android SDK documentation.

REMEMBER TO STOP LISTENING

For every runtime registration that you create, you must also unregister it. If you would like to receive the events only when your activity is visible, onPause is the best place to turn off the receiver. If you’d like to listen for as long as your activity is running, even if it’s not visible, you’ll want to unregister in onDestroy. Wherever you decide to stop listening, simply call unregisterReceiver (a method implemented by your superclass) and pass in the BroadcastReceiver you created earlier, like this:

@Override

ptg7794906 CREATING SELF-CONTAINED BROADCAST RECEIVERS

A broadcast receiver doesn’t have to exist inside an activity. You can register a receiver if you want to know about a system event but might not need to start your full application when it occurs.

BroadcastReceivers can be registered on their own under the <receiver> tag.

In practice, I use these as a way to receive information about the system that may not require showing something to the user. Starting an activity only to shut it down if it’s not needed is much more resource expensive than grabbing the broadcast intent with a receiver and then starting up an activity only when needed.

HANDLING COLLIDING ACTIVITIES

You may be thinking to yourself “Self, what happens when more than one activ-ity is registered for the same intent?” This is a very interesting question, one that Android resolves simply by asking the user.

If two activities listen for the same intent in their manifests, and an application attempts to start an activity with that intent, the system will pop up a menu giving users a list of possible applications to choose from (Figure 2.2).

You’ve probably seen similar behavior hundreds of times on your desktop com-puter, such as when opening a file and being given a choice about which application you’d like to open it with.

FIGURE 2.2 Do you want to open that YouTube link in the browser or the app?

ptg7794906 This notion of many activities registering for the same intent can have delightful

side effects. In Android, any application can register to share media with a given MIME time by using the android.intent.action.SEND action.

Figure 2.3 is what the Share tab on my phone looks like when I press it in the image gallery.

It is this ability to register for similar intents that allows seamless interaction as each application registering this intent is given an entry on the Share menu. Click-ing an entry in this list will start the registered activity and pass along as an extra the location at which the image can be accessed. What is an extra? Good question.