Android Application Development Cookbook: Over 100 recipes to help you solve the most common problems faced by Android Developers today, Second Edition

Android Studio is the new tool used to develop Android applications, replacing the now-deprecated Eclipse ADT solution. Android Studio will be used for all the recipes shown in this book, so if you have not already installed it, visit the Android Studio website (the link has been provided earlier) to install the IDE and the SDK bundle.

For this first example, we'll guide you through creating a new project. Android Studio provides a Quick Start wizard, which makes the process extremely easy. Follow these steps to get started:

After finishing the wizard, Android Studio will create the project files. For this recipe, the two files that we will examine are MainActivity.java (which corresponds to the activity name mentioned in Step 6) and AndroidManifest.xml.

If you take a look at the MainActivity.java file, you will realize that it's pretty basic. This is because we chose the Blank Activity option (in Step 4). Now look at the AndroidManifest.xml file. This is where we actually declare the activity. Within the <application> element is the <activity> element:

<activity
    android:name=".MainActivity"
    android:label="@string/app_name">
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>

        <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
</activity>

Declaring an activity is a simple matter of declaring the <activity> element and specifying the name of the activity class with the android:name attribute. By adding the <activity> element to the Android Manifest, we are specifying our intention to include this component within our application. Any activities (or any other component for that matter) that are not declared in the manifest will not be included in the application. Attempting to access or utilize an undeclared component will result in an exception being thrown at runtime.

In the preceding code, there is another attribute—android:label. This attribute indicates the title shown on the screen as well as the icon label if this is the Launcher activity.

To keep things simple, we are going to use an intent object to start one of Android's built-in applications rather than create a new one. This only requires a very basic application, so start a new Android project with Android Studio and call it ActivityStarter.

Again, to keep the example simple so that we can focus on the task at hand, we will create a function to show an intent in action and call this function from a button on our activity.

Once your new project is created in Android Studio, follow these steps:

Though simple, this app demonstrates much of the power behind the Android OS. The intent object is just a message object. Intents can be used to communicate across your application's components (such as services and broadcast receivers) as well as with other applications on the device (as we did in this recipe).

In this recipe, we created an intent object by specifying ACTION_VIEW as what we want to do (our intention). You may have noticed that when you typed Intent and then the period, Android Studio provided a pop-up list of possibilities (this is the autocomplete feature), like this:

ACTION_VIEW, along with a URL in the data, indicates that the intention is to view the website, so the default browser is launched (different data could launch different apps). In this example, our intent is just to view the URL, so we call the intent with just the startActivity() method. There are other ways to call the intent depending on our needs. In the Returning a result from an activity recipe, we will use the startActivityForResult() method.

It's very common for Android users to download their favorite apps for web browsing, taking photos, text messaging, and so on. Using intents, you can let your app utilize your user's favorite apps instead of trying to reinvent all of this functionality.

To start an activity from a menu selection, refer to the Handling menu selections recipe in Chapter 4, Menus.

We'll create a new project in Android Studio, just as we did in the previous recipes, and call this one ActivitySwitcher. Android Studio will create the first activity, ActivityMain, and automatically declare it in the manifest.

The real work of this exercise is in the onClickSwitchActivity() method from Step 3. This is where we declare the second activity for the intent using SecondActivity.class. We went one step further by adding the close button to the second activity to show a common real-world situation—launching a new activity, then closing it, and returning to the original calling activity. This behavior is accomplished in the onClickClose() function. All it does is call finish(), but that tells the system that we're done with the activity. Finish doesn't actually return us to the calling activity or any specific activity for that matter; it just closes the current activity and relies on the back stack. If we want a specific activity, we can again use the intent object (we just change the class name while creating the intent).

This activity switching does not make a very exciting application. Our activity does nothing but demonstrate how to switch from one activity to another, which of course will form a fundamental aspect of almost any application that we develop.

If we had manually created the activities, we would need to add them to the manifest. By using these steps, Android Studio has already taken care of the XML. To see what Android Studio did, open the AndroidManifest.xml file and look at the <application> element:

<activity
    android:name=".MainActivity"
    android:label="@string/app_name">
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.LAUNCHER/>
    </intent-filter>
</activity>
<activity
    android:name=".SecondActivity"
    android:label="@string/title_activity_second">
</activity>

One thing to note in the preceding autogenerated code is that the second activity does not have the <intent-filter> element. The main activity is generally the entry point when starting the application. That's why MAIN and LAUNCHER are defined—so that the system will know which activity to launch when the application starts.

This recipe will pick up from where the previous one ended. We will call this project SendData.

Since this recipe is building on the previous recipe, most of the work is already done. We'll add an EditText element to the main activity so that we have something to send to SecondActivity. We'll use the (autogenerated) TextView view to display the message. Here are the complete steps:

As expected, the intent object is doing all the work. We created an intent just as in the previous recipe and then added some extra data. Did you notice the putExtra() method call? In our example, we used the already defined Intent.EXTRA_TEXT as the identifier, but we didn't have to. We can use any key we want (you've seen this concept before if you're familiar with name/value pairs).

The key point about using name/value pairs is that you have to use the same name to get the data back out. That's why we used the same key identifier when we read the extra data with getStringExtra().

The second activity was launched with the intent that we created, so it's simply a matter of getting the intent and checking for the data sent along with it. We do this in onCreate():

textView.setText(getIntent().getStringExtra(Intent.EXTRA_TEXT));

We aren't limited to just sending String data. The intent object is very flexible and already supports basic data types. Go back to Android Studio and click on the putExtra method. Then hit Ctrl and the Spacebar. Android Studio will bring up the autocomplete list so that you can see the different data types that you can store.

Returning a result from an activity is not very different from the way we just called the activity in the previous recipes. You can either use the project from the previous recipe, or start a new project and call it GettingResults. Either way, once you have a project with two activities and the code needed to call the second activity, you're ready to begin.

There are only a few changes needed to get the results:

As you can see, getting the results back is relatively straightforward. We just call the intent with startActivityForResult, so it knows that we want a result. We set up the onActivityResult() callback handler to receive the results. Finally, we make sure that the second activity returns a result with setResult() before closing the activity. In this example, we are just setting a result with a static value. We just display what we receive to demonstrate the concept.

It's good practice to check the result code to make sure that the user didn't cancel the action. It's technically an integer, but the system uses it as a boolean value. Check for either RESULT_OK or RESULT_CANCEL and proceed accordingly. In our example, the second activity doesn't have a cancel button, so why bother to check? What if the user hits the back button? The system will set the result code to RESULT_CANCEL and the intent to null, which will cause our code to throw an exception.

We made use of the Toast object, which is a convenient pop-up message that can be used to unobtrusively notify the user. It also functions as a handy method for debugging as it doesn't need a special layout or screen space.

Besides the result code, onActivityResults() also includes a Request Code. Are you wondering where that came from? It is simply the integer value that was passed with the startActivityForResult() call, which takes this form:

startActivityForResult(Intent intent, int requestCode);

We didn't check the request code because we knew we had only one result to handle—but in trivial applications with several activities, this value can be used to identify where the request originated.

Create a new project in Android Studio and name it StateSaver. We need only a single activity, so the autogenerated main activity is sufficient. However, we will need a few widgets, including EditText, Button, and TextView. Their layout (in activity_main.xml) will look like this:

<EditText
    android:id="@+id/editText"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_alignParentTop="true"
    android:layout_alignParentStart="true"/>

<Button
    android:id="@+id/button"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_centerInParent="true"
    android:text="Count"
    android:onClick="onClickCounter"/>

<TextView
    android:id="@+id/textViewCounter"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_below="@id/button"/>

Perform the following set of steps:

All activities go through multiple states during their lifetime. By setting up callbacks to handle the events, we can have our code save important information before the activity is destroyed.

Step 3 is where the actual saving and restoring occurs. The system sends a Bundle (a data object that also uses name/value pairs) to the methods. We use the onSaveInstanceState() callback to save the data and pull it out in the onRestoreInstanceState() callback.

But wait! Did you try typing text in the EditText view before rotating the device? If so, you'd have noticed that the text was also restored, but we don't have any code to handle that view. By default, the system will automatically save the state, provided it has a unique ID (not all views automatically have their state saved, such as the TextView, but we can manually save it if we want).

The onRestoreInstanceState() callback is not the only place where the state can be restored. Look at the signature of onCreate():

onCreate(Bundle savedInstanceState)

Both methods receive the same Bundle instance named savedInstanceState. You could move the restore code to the onCreate() method and it would work the same. But one catch is that the savedInstanceState bundle will be null if there is no data, such as during the initial creation of the activity. If you want to move the code from the onRestoreInstanceState() callback, just check to make sure that the data is not null, as follows:

if (savedInstanceState!=null) {
    mCounter = savedInstanceState.getInt(KEY_COUNTER);
}

You can either use the project from the previous recipe or start a new project and call it PersistentData (in a real-world application, you'll likely be doing both anyway). In the previous recipe, we saved mCounter in the session state. In this recipe, we'll add a new method to handle onPause() and save mCounter to SharedPreferences. We'll restore the value in onCreate().

We have only two changes to make, and both are in MainActivity.java:

As you can see, this is very similar to saving state data, because it also uses name/value pairs. Here, we just stored an int, but we can just as easily store one of the other primitive data types. Each data type has equivalent getters and setters, for example, SharedPreferences.getBoolean() or SharedPreferences.setString().

Saving our data requires the services of SharedPreferences.Editor. This is evoked with edit() and accepts remove() and clear() procedures as well as setters such as putInt(). Note that we must conclude any storing that we do here with the commit() statement.

There is a slightly more sophisticated variant of the getPreferences() accessor: getSharedPreferences(). It can be used to store multiple preference sets.

getSharedPreferences(String name, int mode)

Create a new project in Android Studio with a Blank Activity, and call it ActivityLifecycle. We will use the (autogenerated) TextView method to display the state information.

To see the application move through the various stages, we will create methods for all the stages:

Our activity can exist in one of these three states: active, paused, or stopped. There is also a fourth state, destroyed, but we can safely ignore it: