Activities in android apps

Activities are described by subclasses of the android.app.Activity class, which is an indirect subclass of the abstract android.content.Context class.

NOTE: Context is an abstract class whose methods let apps access global information about their environments (such as their resources and filesystems), and allow apps to perform contextual operations, such as launching activities and services, broadcasting intents, and opening private files.

Activity subclasses override various Activity lifecycle callback methods that Android calls during the life of an activity. For example, the SimpleActivity class extends Activity and also overrides the void onCreate(Bundle bundle) and void onDestroy() lifecycle callback methods.

import android.app.Activity;

import android.os.Bundle;

public class SimpleActivity extends Activity

{

@Override

public void onCreate(Bundle savedInstanceState)

{

super.onCreate(savedInstanceState); // Always call superclass method first.

System.out.println("onCreate(Bundle) called");

}

@Override

public void onDestroy()

{

super.onDestroy(); // Always call superclass method first.

System.out.println("onDestroy() called");

}

}

The overriding onCreate(Bundle) and onDestroy() methods invoke their superclass counterparts, a pattern that must be followed when overriding the void onStart(), void onRestart(), void onResume(), void onPause(), and void onStop() lifecycle callback methods.

1. onCreate(Bundle) is called when the activity is first created. This method is used to create the activity’s user interface, create background threads as needed, and perform other global initialization. onCreate() is passed an android.os.Bundle object containing the activity’s previous state, if that state was captured; otherwise, the null reference is passed. Android always calls the onStart() method after calling onCreate(Bundle).

2. onStart() is called just before the activity becomes visible to the user. Android calls the onResume() method after calling onStart() when the activity comes to the foreground, and calls the onStop() method after onStart() when the activity becomes hidden.

3. onRestart() is called after the activity has been stopped, just prior to it being started again. Android always calls onStart() after calling onRestart().

4. onResume() is called just before the activity starts interacting with the user. At this point, the activity has the focus and user input is directed to the activity. Android always calls the onPause() method after calling onResume(), but only when the activity must be paused.

5. onPause() is called when Android is about to resume another activity. This method is typically used to persist unsaved changes, stop animations that might be consuming processor cycles, and so on. It should perform its job quickly, because the next activity won’t be resumed until it returns. Android calls onResume() after calling onPause() when the activity starts interacting with the user, and calls onStop() when the activity becomes invisible to the user.

6. onStop() is called when the activity is no longer visible to the user. This may happen because the activity is being destroyed, or because another activity (either an existing one or a new one) has been resumed and is covering the activity. Android calls onRestart() after calling onStop(), when the activity is coming back to interact with the user, and calls the onDestroy() method when the activity is going away.

7. onDestroy() is called before the activity is destroyed, unless memory is tight and Android is forced to kill the activity’s process. In this scenario, onDestroy() is never called. If onDestroy() is called, it will be the final call that the activity ever receives.

NOTE: Android can kill the process hosting the activity at any time after onPause(), onStop(), or onDestroy() returns. An activity is in a killable state from the time onPause() returns until the time onResume() is called. The activity won’t again be killable until onPause() returns.

These seven methods define an activity’s entire lifecycle and describe the following three nested loops:

- The entire lifetime of an activity is defined as everything from the first call to onCreate(Bundle) through to a single final call to onDestroy(). An activity performs all of its initial setup of “global” state in

onCreate(Bundle), and releases all remaining resources in onDestroy(). For example, if the activity has a thread running in the background to download data from the network, it might create that thread in onCreate(Bundle) and stop the thread in onDestroy().

- The visible lifetime of an activity is defined as everything from a call to onStart() through to a corresponding call to onStop(). During this time, the user can see the activity onscreen, although it might not be in the foreground interacting with the user. Between these two methods, the activity can maintain resources that are needed to show itself to the user. For example, it can register a broadcast receiver in onStart() to monitor for changes that impact its user interface, and unregister this object in onStop() when the user can no longer see what the activity is displaying. The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible to and being hidden from the user.

- The foreground lifetime of an activity is defined as everything from a call to onResume() through to a corresponding call to onPause(). During this time, the activity is in front of all other activities onscreen and is interacting with the user. An activity can frequently transition between the resumed and paused states; for example, onPause() is called when the device goes to sleep or when a new activity is started, and onResume() is called when an activity result or a new intent is delivered. The code in these two methods should be fairly lightweight.

NOTE: Each lifecycle callback method is a hook that an activity can override to perform appropriate work. All activities must implement onCreate(Bundle) to carry out the initial setup when the activity object is first instantiated. Many activities also implement onPause() to commit data changes and otherwise prepare to stop interacting with the user.

 The lifecycle of an activity reveals that there’s no guarantee of onDestroy() being called. Because onDestroy() might not be called, you should not count on using this method as a place for saving data. For example, if an activity is editing a content provider’s data, those edits should typically be committed in onPause(). In contrast, onDestroy() is usually implemented to free resources (such as threads) that are associated with an activity so that a destroyed activity doesn’t leave such things around while the rest of its app is still running. More specifically, the activity is started by creating an Intent object describing an explicit or implicit intent, and by passing this object to Context’s void startActivity(Intent intent) method (launch a new activity; no result is returned when it finishes). Alternatively, the activity could be started by calling Activity’s void startActivityForResult(Intent intent, int requestCode) method. The specified int result is returned to Activity’s void onActivityResult(int requestCode, int resultCode, Intent data) callback method as an argument.

NOTE: The responding activity can look at the initial intent that caused it to be launched by calling Activity’s Intent getIntent() method. Android calls the activity’s void onNewIntent(Intent intent) method (also located in the Activity class) to pass any subsequent intents to the activity. Suppose that you’ve created an app named SimpleActivity, and that this app consists of SimpleActivity. Now suppose that you want to launch SimpleActivity2 from SimpleActivity’s onCreate(Bundle) method. The following code fragment shows you how to start SimpleActivity2:

Intent intent = new Intent(SimpleActivity.this, SimpleActivity2.class);

SimpleActivity.this.startActivity(intent);

The first line creates an Intent object that describes an explicit intent. It initializes this object by passing the current SimpleActivity instance’s reference and SimpleActivity2’s Class instance to the Intent(Context packageContext, Class cls) constructor. The second line passes this Intent object to startActivity(Intent), which is responsible for launching the activity described by SimpleActivity2.class. If startActivity(Intent) was unable to find the specified activity (which shouldn’t happen), it would throw an android.content.ActivityNotFoundException instance. Activities must be declared in the app’s AndroidManifest.xml file or they cannot be started (because they are invisible to Android).