Implicit vs explicit animations: AnimatedContainer or AnimationController?

What's really being asked

This question probes whether you understand the architectural split between Flutter's declarative implicit animation widgets and its imperative explicit animation APIs. A senior candidate should know that implicit widgets hide the AnimationController lifecycle while explicit controllers expose it, and you should be able to pick the right tool based on complexity and interaction needs rather than defaulting to the most powerful option.

The full answer

First, define implicit animations as widgets like AnimatedContainer, AnimatedOpacity, and AnimatedPositioned that automatically tween to new property values whenever the widget rebuilds with different parameters. They manage their own internal AnimationController, curve, and duration, so you only declare the target state. Second, define explicit animations as those driven by an AnimationController that you instantiate, start, stop, and dispose manually, giving you precise control over duration, reverse playback, and animation status listeners. Third, explain the decision boundary: choose AnimatedContainer when you have a simple property change triggered by state, such as color, size, padding, or border radius transitions, because it removes boilerplate and avoids lifecycle bugs. Choose AnimationController when you need interactive control, chained or staggered sequences, physics-based motion, or when the animation must run outside of a simple rebuild cycle. Fourth, mention that implicit animations can be customized with duration and curve parameters, and that you can interrupt them mid-flight by changing the target value again, which is a common misconception.

The mistakes people make

A major red flag is claiming that AnimationController is always the correct choice because it is more powerful; this signals unfamiliarity with Flutter's declarative philosophy and leads to unnecessary StatefulWidget boilerplate. Another mistake is saying that AnimatedContainer requires you to manage an AnimationController; it does not, because it is an implicitly animated widget. Candidates sometimes also argue that implicit animations cannot be interrupted or curved, which is false since both duration and curve are constructor parameters. Finally, suggesting explicit controllers for every UI transition shows poor judgment about code simplicity and maintainability.

What usually comes next

The interviewer may ask how you would stagger multiple property changes, which pushes toward explicit controllers or TweenSequence. They might ask about performance differences between many implicit widgets versus a single explicit controller, where the answer is that a single controller is usually more efficient for complex coordinated motion. Another follow-up is how to interrupt an implicit animation and start a new one from the current intermediate value, which requires switching to an explicit controller or using a package. They could also ask about disposing implicit widgets, testing the knowledge that you do not dispose their internal controllers because the widget owns them.

A concrete example

Imagine a settings card that expands when tapped. If you only need to animate height and background color, AnimatedContainer is ideal because you change the height variable in setState and the widget handles the tween. If you need the card to expand while simultaneously rotating an icon 180 degrees, bouncing at the end, and allowing the user to pause the motion with a long-press, you need an AnimationController with multiple Tweens and a GestureDetector because implicit widgets cannot synchronize complex multi-step interactive choreography.