Android Activity Lifecycle from a React Perspective

Mark Foley
2 min readFeb 15, 2021

Six basic callbacks provide the means to navigate the lifecycle of an Android activity: onCreate(), onStart(), onResume(), onPause(), onStop(), and onDestroy(). Though unique to Android development via its Activity class, these various callbacks can be understood from an outside perspective as paralleling lifecycle concepts in React and even certain events in HTML.

From the official docs.

First up is onCreate() which can be understood as like a constructor for your Activity. This is familiar to React as the constructor in the lifecycle of React class components, though in the world of modern React with hooks there is no easy analogue as class components are dropped in favor of exclusively functional components.

Next we have onStart(), perhaps analogous to the componentDidMount() of the React class component lifecycle. In either case this is invoked not on creation but when the activity/component enters the state where it can be interacted with by the user. In React with hooks this is accomplished with the useEffect hook instead.

Third in the lifecycle is onResume(). I find this more similar to an HTML onfocus event than to anything in the React lifecycle. This is invoked when the activity is the dominant presence on the device in that it is able to receive input, the concept known as focus.

An activity still visible on the screen but in a state currently unable to receive input will invoke the onPause() callback. This is similar to losing focus on an HTML element. In the optical sense, the opposite of “focus” is “blur” so the inverse of the HTML onfocus event is of course called onblur. Because why wouldn’t it be.

Skipping ahead, onDestroy() parallels componentWillUnmount() from the React class component lifecycle as I understand it. Why onDestroy() and not onStop()? Truthfully componentWillUnmount() has parallels with both but because it completely drops the React state of the component from memory I see this as more directly comparable to onDestroy(), at least in theory.

I say “in theory” because in practical implementation you will usually find many componentWillUnmount() behaviors must be put in onStop() simply because onDestroy() is not reliably called at the end of life of an activity — when the device calls for the termination of the process there is not always a chance to properly execute onDestroy(). For that reason, vital shutdown processes such as persisting data to the database should be performed during onStop() instead.

I look forward to delving deeper into the parallels and revisiting this topic as I deepen my familiarity with the activity lifecycle.

--

--