Module 0261: Android Activities

Activity is the name of a class that represents the concept of an activity. Essentially, an activity (the underlying concept of the class) has the following attributes:

Roughly, an activity is a screen of an app, and an app can have any number of activities. Activities are important in Android development because it represents a container for View (and its subclass) objects. As a container, it has a well deﬁned life cycle.

3 The lifecycle

It is important to know how to interpret this picture. The colored ovals represent “states” that an activity can be in, whereas the gray rectangles represent states and also points at which code can be written to specify speciﬁc actions. Unboxed text along the arrows are “events” that trigger a transition.

If there is no text on an arrow, it means the transition is automatic and does not require an “event”.

Through the lifecycle of an activity, many on... methods can be @Overriden to specify app speciﬁc code. Note that the Android document reminds developers that the overriden method of the super class should be called in the case many of these methods.

The life cycle diagram from the Android Developers site is actually quite confusing and the text descriptions of the on... methods are not much better. Here is an attempt to reexplain.

3.1 Creation

The trigger to create an activity is an event that causes the Android OS to call new to allocate an object of Activity class or subclass thereof.

Upon creation, there are potentially two places to insert custom code. First, the constructor of the class can be used to perform internal initialization, but should not do any work with user interaction elements. This is because when the object is allocated, the activity is not done initialized.

onCreate presents the ﬁrst point where user interaction elements can be manipulated. This can include the registration of event listeners and/or resuming the UI elements to some default or saved states. At this point, the activity is not visible.

3.2 Visible

Any transition into visible state triggers onStart. At this point, the activity is visible, but not interactive. From the visible state, an activity automatically transitions to active state.

3.3 Active

Any transition into active state triggers onResume. At this point, the activity is visible and interactive.

To exit active state, something has to appear on the activity itself. As soon as something appears on top of an activity, it transitions to paused state.

3.4 Paused

Any transition into paused state triggers onPause. At this point, the activity is still visible but not interactive any more.

From paused state, an activity can transition to active state if the activity is only partially obscured and whatever is in front disappears.

From paused state, an activity can also transition to stopped state if the activity becomes completely obscured.

From paused state, an activity can also be deallocated and ceases to exist because the associated process is killed by the OS. This does not trigger onStop nor onDestroy.

Because the transition to the paused state can lead to the activity getting deallocated without any further notice, this is usually a good time to synchronize with any persistent storage because the process can be killed after this point.

3.5 Stopped

Any transition into stopped state triggers onStop. At this point, the activity is no longer visible.

From stopped state, an activity can transition to ﬁnal state via onDestroy. The ﬁnal state is the state right prior to the activity getting deallocated.

From stopped state, an activity can also be deallocated because the associated process is killed by the OS. In this case, onDestroy is not triggered.

4 Starting another activity

This is done by the method startActivity (and its variant). Regardless of which variant, the method requires at least on parameter of the class Intent.

An Intent object speciﬁes the activity to be started either implicitly or explicitly. We will only discuss the explicit method here because the example is starting another activity of the same app.

The following is the code to start a second activity represented by the class SecondActivity in the same app (therefore the same package):

package edu.losrios.w1234567.twoscreens;

import android.content.Intent;
import android.support.annotation.IdRes;
import android.support.annotation.Nullable;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        findViewById(R.id.buttonClickMe).setOnClickListener(new View.OnClickListener() {
            public void onClick(View x) {
                Intent i = new Intent(x.getContext(), SecondActivity.class);
                startActivity(i);
        }
        });
    }

}

When the button is clicked, an Intent object is created. The ﬁrst parameter to the constructor supplies the context, which is the main activity. However, x.getcontext() is speciﬁed here because this is done inside an event listener, and parameter x of the event listener is the View object that is receiving the event. The context of the View object, in return, is the activity.

The second parameter is a little more interesting. It speciﬁes the SecondActivity class itself. This is a speciﬁcation of what activity should be started when the Intent object is used in startActivity.

Note that startActivity returns right away and not until the user presses the “back” button on the second screen.