CHAPTER 7: Making Apps Interactive: Intents, Event Handling, and Menus 225EditGalaxy.java. The difference is that your code is calling, or in the case of using an explicit Intent
object, launching, a .class compiled version of your Activity subclass from within your compiled
package (.APK or Android PacKage) infrastructure.
You will typically want to use an explicit Intent object to start a component within your own
application. This is because you inherently know the class name of your Activity subclass or Service
subclass which you want to launch, and so you can utilize, or “hard code,” that component name in
your Java code. For example, you would start your new Activity subclass in response to a MenuItem
selection, as we are about to do in the next section, or you could also start a Service subclass, in
order to start processing in the background, as we are going to do in Chapter 13 when we cover
Services.
Implicit Intent objects do not name their target application component, but instead declare a general
“action” to perform. This implicit Intent approach allows any application component, even from
another Android app outside of your own Android app, to “handle” the Intent. The reason that
Android also has Intent Filters and the IntentFilter class is for the processing, action determination,
and handling of these implicit Intent objects.
For example, if you wanted to show your app’s user a location on a map, you could use an implicit
Intent object to ask, or “request,” that another mapping-capable Android application show your
application user that specific location on the map that your application is referencing. Implicit Intents
allow Android apps to work together!
When you create an implicit Intent object, the Android operating system will find the appropriate
application component (Activity, Service, Broadcast Receiver) to start up by comparing the contents
of your implicit Intent object to the
for other apps on the device.
If the implicit Intent object matches up with one of those IntentFilter definitions, the Android
operating system starts that component, and delivers your implicit Intent object to it. If multiple
IntentFilter definitions are found to be compatible on the same Android device, the Android operating
system will display a pop-up dialog, so the user can pick which app to use. It is important to note
that every user installs different apps, and thus different users’ Android devices will invariably exhibit
different combinations of installed Android applications, which will result in different popup dialog
selection choices.
An IntentFilter object is an Intent processing definition construct which is defined using your
Android application Manifest XML file. This
of implicit Intent objects that your Android application’s components would like to be able to receive,
and to be able to process. This is quite powerful (and quite complex as well), as it allows developers
to create Android applications which do things (perform tasks) for other Android apps, which opens
up an entirely new genre of Android applications that Android developers can create.
As an example, by declaring an IntentFilter object for an Activity subclass, as you have already seen
done by Eclipse for your MainActivity class in your AndroidManifest.xml, you make it possible for
other applications, in this case it would be the Android OS application launching screen, to directly
start your MainActivity.class Activity subclass using a specific Intent object containing the MAIN
action and the LAUNCHER category.
If you do not declare any
of your Activity subclasses, then these Activity subclasses will be “invisible” to outside Android
applications, and will only be able to be started using an explicit Intent object. A great example of