Launching Android Apps

Getting Help

In our last article we discussed the benefits of leveraging the services of other applications before attempting to duplicate existing functionality in our own applications.

Built-in applications such as Maps, Email, Phone (yes that is an application too), SMS, Media Player, Camera and others are all at our disposal and may be called upon to bring sought-after functionality to our applications.

We have looked at some of these previously — most recently the Photo Booth application which demonstrated taking a picture within an Android Application.

There are two excellent reasons to use existing services available to us in Android, or any mobile environment for that matter.

First, we cannot possibly be experts on every facet of mobile apps programming, nor do we have endless budgets and limitless resources — using other people’s code where proper just makes sense today.

Secondly, we need to offer consistency to the user. You know the lack of consistency when you see it — an application or piece of a user interface that just looks out of place. We need to avoid causing confusion for our users and as a side benefit we reduce the amount of training, support and documentation necessary on our part. The more seamless and intuitive an application appears with respect to the over all user experience on a given platform, the more your application seems “built-in”. In most cases, this is exactly what we want our user’s experience to be.

Market Opportunity

In addition to the built-in applications, we can leverage third party applications and libraries also. This is an opportunity for both the application developer looking to leverage existing functionality to augment their application as well as an opportunity for the developer looking to provide functionality to other developer’s applications.

This idea had a successful implementation in the early mobile days of Palm OS. One application can launch another application, passing with it various bits of information governing the requested operation.

Let’s look at an example. Let’s say you have written the latest super list management software. Your users are asking you for the ability to create a hard-copy of the list. You know, print it out. On paper.

You have three options:

1. Ignore the requests and maybe they go away!
2. Become an expert in all things printing including communications, print drivers, image processing, etc.
3. Use a third party provider of printing functionality. This choice may be broken up further into a couple of different deployment models:
   • SDK based where you compile in the functionality
   • Separate application is installed which handles the printing requests

Assuming we don’t want our users to go away and we also don’t want to become experts in all things printing, we choose option 3, to leverage a third party developer’s toolset. We don’t want to force all of our users to “pay” for this functionality so we make it optional. The application adds a menu for printing and we only print if the third party application is available. The third party printing tool may be then licensed separately and only the users who care about it need to pay for it.

The question now is “how” to make this happen from a technical perspective?

Starting other applications

This article demonstrates launching other applications to perform some operation that our application does not directly implement. We look at how this is done with Android and then enumerate some of the more popular examples from the Android SDK.

Regardless of what you are trying to accomplish on the Android platform you run into the Intent class sooner than later.

An instance of the Intent class represents a statement of “need” or “interest” that an application is expressing.

For example, an application can broadcast an Intent which is asking for help — something like: “Please handle this piece of data for me”. Or, “I need contacts”, please present a list of contacts for me to choose from.

Looking back to our Photo Booth example, we initiate the camera capture process by creating an Intent as shown in the following code snippet.

Intent action = new Intent("android.media.action.IMAGE_CAPTURE");

This Intent indicates that we want to capture an image with the camera.

We have two options for submitting this request: startActivity or startActivityForResult.

We use startActivity when we don’t care about keeping control within our application. An example of this might be where we want to leave our application and proceed with another operation altogether such as reading a map or making a phone call.

startActivity(action);

The startActivityForResult method is used when we prefer to maintain control of the situation. This method asks another Activity to perform an operation but then return control back to our application, hence the “ForResult” in the name. When using this method we need to provide more code to make things work.

    class someclass {
        final int TAKE_PICTURE = 1;
        private void somemethod() {
            Intent action = new Intent("android.media.action.IMAGE_CAPTURE");
            startActivityForResult(action,TAKE_PICTURE);
        }

        protected void onActivityResult(int requestCode,int resultCode,Intent data) {
        	if (requestCode == TAKE_PICTURE) {
        		if (resultCode == RESULT_OK) {
        			Bitmap b = (Bitmap) data.getExtras().get("data");
        			someImageView.setImageBitmap(app.b);
        		}
        	}
        }
    }

Walking through this code, we see that the “somemethod” method initializes an instance of an Intent. It then requests that some other Activity within the Android platform be started with a call to startActivityForResult, passing along the Intent instance with with an integer identifier. Android attempts to dispatch this event, which in this case is handled by the built-in camera application. When the picture taking process is completed, the camera application packages up the image into new Intent instance and responds back to the caller in an asynchronous fashion.

When control returns to the calling application, the method named onActivityResult is invoked along with three parameters: a requestCode, a resultCode and an Intent which contains any relevant data associated with the Activity.

Because a single application might make many such requests, and for different reasons, the requestCode parameter is used to help organize the results. Assuming the resultCode is “OK”, the application can now process the results, which in this case involves handling an image.

The image is extracted from the Intent and shown visually to the user by setting the bitmap image property in an ImageView.

Much of Android programming is “rinse and repeat” on this basic model of setting up data and passing it along to another “Activity” to carry out the operation. This Activity may be a built-in application, a third-party application, or even another Actvity within the same application. To call another Activity within the same application the Intent is constructed in a slightly different manner:

    Intent action = new Intent(getContext(),OtherActivity.clsss);
    startActivity(action);
    //or
    startActivityForResult(action,1);

Advertising

The Intent identifies a desired action. When an application implements an action that it is capable of processing it must advertise this capability within its AndroidManifest.xml file. This manifest file contains all manner of configuration and environment information about the application. The piece that we are interested in here is something known as the “intent-filter”.

<activity android:name=".SomeThirdPartyApp" android:label="@string/app_name">
	<intent-filter>
		<action android:name="com.somethirdparty.SOME_ACTION" />
	</intent-filter>
 </actvity>

In order to launch this application a calling application would use code along these lines.

Intent action = new Intent("com.msi.somethirdparty.SOME_ACTION");
startActivity(action);

That’s all there is to it. Optionally, the Intent instance may contain information to be acted upon as either data or a reference to data such as a file name or unique record id in a database, etc.

Some popular ACTIONs

The Android platform includes a number of commonly used operations that your application might want to leverage. We’ll conclude with a list of some of the more popular ACTIONs and their respective intent-filter names.

• ACTION_VIEW — android.intent.action.VIEW — used to view a piece of data such as a contact record
• ACTION_DELETE — android.intent.action.DELETE — delete a specific piece of data, which is passed along with the Intent
• ACTION_PICK — android.intent.action.PICK — pick from a list of available entries, based on the type of data requested such as phone number
• ACTION_DIAL — android.intent.action.DIAL — bring up the phone application, ready to dial a passed along number

For a complete list of available Intent actions for built-in applications, please see the Android Intent documentation.

In an upcoming article we will have a look at providing access from one application to another on the iPhone/iPad platform.