Explain the lifecycle of a State object

What's really being asked

This question probes whether you understand the framework contract between a StatefulWidget and its State object, not just the method names. Seniors are expected to know why each hook exists, what resources belong in each phase, and the exact ordering guarantees Flutter provides. It also checks if you appreciate the difference between widget configuration changes and internal state changes.

The full answer

A strong answer walks through the lifecycle in strict order. First, the framework creates the State object via StatefulWidget.createState and mounts it to a BuildContext. Next comes initState for one-time setup like listeners or controllers. Then didChangeDependencies fires for InheritedWidget initialization. After that, build can run many times. When the parent rebuilds with a new widget of the same runtimeType and key, didUpdateWidget fires with the previous widget so you can diff properties. If the subtree is removed, deactivate runs, and the framework may reinsert it within the same frame. If not reinserted, dispose runs to release resources, after which mounted is false. A senior candidate also notes that setState is not a lifecycle method but a request to rebuild, and that didUpdateWidget is always followed by build, so calling setState inside it is redundant.

The mistakes people make

Candidates often say didUpdateWidget runs before initState or confuse it with didChangeDependencies. Another red flag is treating setState as a lifecycle hook rather than a signal. Some engineers forget that deactivate allows reinsertion and put all cleanup in deactivate instead of dispose, which leaks resources if the widget moves. Others claim the State object can be remounted after dispose, which is impossible.

What usually comes next

An interviewer might ask where to subscribe to a Stream, and the correct answer is initState with cancellation in dispose. They might ask why didChangeDependencies exists separately from initState, which tests your knowledge of InheritedWidget and context-dependent setup. Another follow-up is what happens to animations when a widget is moved in the tree, which touches deactivate and the fact that resources should stay alive until dispose.

A concrete example

Suppose you have a custom progress indicator that takes a color from its parent. In initState, you create an AnimationController. In didUpdateWidget, you compare oldWidget.color with widget.color. If they differ, you update the animation curve or restart the tween. You do not recreate the controller here because the widget configuration changed, not the widget identity. When the route is popped, dispose stops the controller.