Table of Contents

About

The Activity lifecycle is implemented by callback methods.

A good way to test the lifecycle implementation (ie the application's ability to restore its state) is to simply rotate the device so that the screen orientation changes.

Android Activity Lifecyle Activity Lifecycle 2

States

State Only for Fragment Callback Function Visible by the user 1) Foreground (Focus) Alive 2)
Attached Yes onAttach No No ?
Created - onCreate No No ?
View Created Yes onCreateView No No ?
Activity Created Yes onActivityCreated No No ?
Visible onStart Yes No ?
Resumed (or Running, Active) - onResume Yes (Foreground) Yes Yes
Paused - onPause Yes (Partially) No Yes
Stopped - onStop No (Background) No Yes
View Destroyed Yes onDestroyView No (Background) No No ?
Destroyed - onDestroy No (Background) No No ?
Detached Yes onDetach No (Background) No No ?
Restart - onRestart No No ?

An application can be killed by the system in extremely low memory situations. It can drop it from memory either by:

  • asking it to finish (calling its finish() method),
  • or simply killing its process.

You should prepare for app death as early as onPause (ie closing resources such as connection or sockets). The function onSaveInstanceState is called before an activity may be killed. It gives a chance to save the current state and to restore it via the function onRestoreInstanceState.

Skeleton

The following skeleton activity includes each of the fundamental lifecycle methods:

public class ExampleActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // The activity is being created.
        //    * Setup of "global" state (such as defining layout, loading layout file, ...)
        //    * Background Thread
    }
    @Override
    protected void onStart() {
        super.onStart();
        // The activity is about to become visible.
        // The system might call onStart() and onStop() multiple times during the entire lifetime of the activity, 
        // as the activity alternates between being visible and hidden to the user.
        //      * register a BroadcastReceiver to monitor changes that impact your UI, 
    }
    @Override
    protected void onResume() {
        super.onResume();
        // The activity has become visible (it is now "resumed").
        // The foreground lifetime of an activity happens between the call to onResume() and the call to onPause(). 
       // Because this state can transition often, the code in these two methods should be fairly lightweight in order to avoid slow transitions that make the user wait.
    }
    @Override
    protected void onPause() {
        super.onPause();
        // Another activity is taking focus (this activity is about to be "paused").
        //  For example, onPause() is called when the device goes to sleep or when a dialog appears. 
        // The activity is still visible !
        //
        // You should prepare for app death (ie closing resources such as connection or sockets)
        // Example also available for the onStop steps:
        //    * Sensor Listener
        //    * Location Updates
        //    * Dynamic Broadcast Receivers
        //    * Game Physics engine

    }
    @Override
    protected void onStop() {
        super.onStop();
        // The activity is no longer visible (it is now "stopped")
        //      * unregister a broadcast receiver
        // Must be considered as an exit handler (all resources must be released). See onPause
        // Background app  shouldn't consume resources
        
    }
    @Override
    protected void onDestroy() {
        super.onDestroy();
        // The activity is about to be destroyed.
        //     * Release all remaining resources such as a background thread
    }
}

List

Active

  • Active: foreground and in focus
  • Visible: start of an extern activity, visible on background

Android Lifecycle Active

Documentation / Reference

1)
The user can see the activity on-screen and interact with it
2)
the Activity object is retained in memory, it maintains all state and member information, but is not attached to the window manager