Welcome to Part 10 of the Flutter Interview Questions series! This is where it gets REAL. These are the "what happens if..." questions that separate good Flutter devs from great ones. Two ListViews in a ScrollView? setState after dispose? Controller in build()? This part covers all the gotchas that interviewers love to throw at candidates — and that real-world codebases suffer from every day. This is part 10 of a 14-part series, so bookmark it and keep it handy for your next interview prep session.
What's in this part?
- Widget tree and layout crash scenarios (nested scrollables, unbounded constraints, Expanded in ScrollView)
- MediaQuery rebuild traps and IntrinsicHeight performance costs
- GlobalKey conflicts and Scaffold nesting issues
- State lifecycle gotchas (setState after dispose, setState in build, async gaps)
- Provider pitfalls, ChangeNotifier leaks, and context validity
- Widget reconciliation, keys, const optimization, and AnimatedSwitcher behavior
- Navigation lifecycle (push/pop, pushReplacement, pushAndRemoveUntil)
- RepaintBoundary and rendering pipeline details
SECTION 1: WIDGET TREE & LAYOUT GOTCHAS
Q1. What happens if you put two ListView widgets inside a SingleChildScrollView? Why does it crash? How to fix it?
What the interviewer is REALLY testing:
Whether you understand Flutter's layout protocol -- specifically how scrollable widgets negotiate unbounded constraints, and whether you grasp the concept of "slivers" vs "box" protocol.
Answer:
It crashes with an unbounded height error. Here is why:
SingleChildScrollView gives its child unbounded constraints along the scroll axis (infinite maxHeight). Each ListView also tries to be lazily sized -- it asks for infinite height from its parent so it can scroll internally. When a widget that wants infinite height is placed inside a parent offering infinite height, Flutter cannot resolve the layout. The layout algorithm has no finite dimension to anchor against.
The deeper issue: you now have competing scroll physics. Which widget should respond to the user's drag gesture? The outer SingleChildScrollView or the inner ListView?
Fixes (in order of preference):
// FIX 1 (BEST): Use a single CustomScrollView with slivers
CustomScrollView(
slivers: [
SliverList(delegate: SliverChildBuilderDelegate(
(context, index) => ListTile(title: Text('List A: $index')),
childCount: 20,
)),
SliverList(delegate: SliverChildBuilderDelegate(
(context, index) => ListTile(title: Text('List B: $index')),
childCount: 20,
)),
],
)
// FIX 2: Use shrinkWrap + NeverScrollableScrollPhysics
SingleChildScrollView(
child: Column(
children: [
ListView.builder(
shrinkWrap: true, // forces finite height
physics: const NeverScrollableScrollPhysics(), // disables inner scroll
itemCount: 20,
itemBuilder: (ctx, i) => ListTile(title: Text('A: $i')),
),
ListView.builder(
shrinkWrap: true,
physics: const NeverScrollableScrollPhysics(),
itemCount: 20,
itemBuilder: (ctx, i) => ListTile(title: Text('B: $i')),
),
],
),
)
Why Fix 2 is inferior: shrinkWrap: true forces the ListView to lay out ALL its children up front to measure its own height. You lose lazy rendering entirely. With 10,000 items this will be catastrophically slow. The sliver approach (Fix 1) preserves lazy rendering.
Q2. What happens if you put a Column inside a Column without constraints?
What the interviewer is REALLY testing:
Understanding of how flex layout propagation works -- specifically that a Column passes unbounded height to its children in the cross-axis, and how the main axis constraint flows.
Answer:
It depends on the outer Column's constraints. If the outer Column is inside a widget that provides bounded height (like Scaffold body), the outer Column gets a finite maxHeight. It then lays out its children. The inner Column, as a non-flex child, receives the same maxHeight as a constraint (not infinite). So it works fine.
The problem appears when the inner Column contains Expanded or Flexible children:
// This WORKS (both Columns have bounded height from Scaffold)
Scaffold(
body: Column(
children: [
Column(
children: [
Text('Hello'),
Text('World'),
],
),
],
),
)
// This CRASHES
Scaffold(
body: Column(
children: [
Column(
children: [
Expanded(child: Container()), // ERROR: unbounded height
],
),
],
),
)
The crash in the second example happens because the outer Column lays out non-flex children first by passing them constraints with maxHeight: infinity along the main axis. The inner Column receives unbounded height. Expanded then tries to take "remaining space" from infinity minus the other children's sizes -- which is still infinity. You cannot expand into infinite space.
Fix: Wrap the inner Column in Expanded so it receives a finite height from the outer Column's flex distribution:
Column(
children: [
Expanded( // now the inner Column gets bounded height
child: Column(
children: [
Expanded(child: Container(color: Colors.red)),
],
),
),
],
)
Q3. What happens if you use Expanded inside a SingleChildScrollView?
What the interviewer is REALLY testing:
Whether you truly understand that Expanded requires a finite main-axis constraint from its parent flex widget, and that scrollable parents provide infinite constraints.
Answer:
You get a runtime error: "RenderFlex children have non-zero flex but incoming height constraints are unbounded."
SingleChildScrollView tells its child: "you can be as tall as you want" (maxHeight = infinity). If that child is a Column containing an Expanded, the Column tries to distribute remaining space among flex children. Remaining space = infinity - (sum of non-flex children heights) = infinity. Expanded cannot take a finite share of infinite space.
// CRASHES
SingleChildScrollView(
child: Column(
children: [
Text('Header'),
Expanded(child: Container()), // Cannot expand into infinite space
],
),
)
// FIX 1: Use SizedBox or ConstrainedBox with a concrete height
SingleChildScrollView(
child: Column(
children: [
Text('Header'),
SizedBox(
height: 400,
child: Container(),
),
],
),
)
// FIX 2: If you want the Column to fill at least the screen
LayoutBuilder(
builder: (context, constraints) {
return SingleChildScrollView(
child: ConstrainedBox(
constraints: BoxConstraints(minHeight: constraints.maxHeight),
child: IntrinsicHeight( // CAUTION: O(n) layout cost
child: Column(
children: [
Text('Header'),
Expanded(child: Container()),
Text('Footer'),
],
),
),
),
);
},
)
The fundamental rule: Expanded (and Flexible) only work inside a flex parent that has a bounded main-axis constraint.
Q4. Why does wrapping a TextField in an Expanded inside a Row work, but without Expanded it crashes?
What the interviewer is REALLY testing:
Understanding of how Row assigns cross-axis vs main-axis constraints, and how TextField (via InputDecorator and EditableText) determines its width.
Answer:
A TextField internally uses InputDecorator, which tries to be as wide as possible -- it defaults to BoxConstraints.expand() on the horizontal axis. Inside a Row, children are given unbounded width (maxWidth = infinity) unless they are wrapped in Expanded or Flexible. A TextField receiving unbounded width tries to be infinitely wide, which is impossible and throws:
"BoxConstraints forces an infinite width."
// CRASHES
Row(
children: [
Icon(Icons.search),
TextField(), // wants infinite width, Row offers infinite width
],
)
// WORKS
Row(
children: [
Icon(Icons.search),
Expanded(
child: TextField(), // Expanded gives it: (Row width - Icon width)
),
],
)
Expanded works because the Row first lays out non-flex children (the Icon), then distributes remaining space to flex children. The TextField receives a finite width equal to the Row's width minus the Icon's width.
Alternative fixes include wrapping in SizedBox(width: 200, ...) or Flexible instead of Expanded. The key insight is that any widget that defaults to infinite size needs a bounded constraint from its parent.
Q5. What happens if you nest a ListView inside a Column? Why does it throw an unbounded height error?
What the interviewer is REALLY testing:
The exact mechanics of constraint propagation in the flex layout algorithm -- specifically the two-pass layout of Column.
Answer:
Column uses a two-pass layout:
-
Pass 1: Lay out non-flex children with
maxHeight = incoming maxHeight(or infinity if the Column itself is unconstrained, but typically it is constrained). - Pass 2: Distribute remaining space to Expanded/Flexible children.
Wait -- the Column IS typically constrained (e.g., from a Scaffold). So why does it fail?
The critical detail: in Pass 1, the Column passes constraints with minHeight: 0 and maxHeight: incoming maxHeight to non-flex children. But a ListView has no inherent height -- it determines its viewport based on the constraints it receives. Given maxHeight of, say, 800, a ListView should work. And indeed, this sometimes works:
// This actually WORKS if the Column has bounded height!
Scaffold(
body: Column(
children: [
Text('Header'),
Expanded(child: ListView(...)), // fine -- Expanded gives bounded height
],
),
)
// This ALSO works (Column gets bounded height from Scaffold)
Scaffold(
body: Column(
children: [
SizedBox(height: 400, child: ListView(...)), // fine -- explicit height
],
),
)
// This CRASHES -- ListView without Expanded in a Column
Scaffold(
body: Column(
children: [
Text('Header'),
ListView(...), // unbounded height error
],
),
)
The crash occurs because Column passes maxHeight: infinity to non-flex children during Pass 1 when it needs to measure them before distributing space. The Column says "tell me how tall you want to be (up to infinity)" and ListView says "I want to be infinite." That is undefined.
The fix is always: wrap the ListView in Expanded or give it an explicit height via SizedBox or ConstrainedBox.
Q6. What if you put a GridView inside a ListView?
What the interviewer is REALLY testing:
Whether you know the difference between the box protocol and the sliver protocol, and whether the candidate can debug nested scrollable issues.
Answer:
Same core problem as Q5. A ListView (which is a BoxScrollView containing slivers) gives its children unbounded height along the scroll axis. A GridView is also a scrollable that wants to determine its own size based on its parent's constraints. When it receives infinite height, it crashes.
// CRASHES
ListView(
children: [
GridView.count(
crossAxisCount: 2,
children: List.generate(20, (i) => Card(child: Text('$i'))),
),
],
)
// FIX 1: shrinkWrap + NeverScrollableScrollPhysics (simple but O(n))
ListView(
children: [
Text('Some header'),
GridView.count(
crossAxisCount: 2,
shrinkWrap: true,
physics: const NeverScrollableScrollPhysics(),
children: List.generate(20, (i) => Card(child: Text('$i'))),
),
Text('Some footer'),
],
)
// FIX 2 (BEST): Use CustomScrollView with slivers
CustomScrollView(
slivers: [
const SliverToBoxAdapter(child: Text('Some header')),
SliverGrid.count(
crossAxisCount: 2,
children: List.generate(20, (i) => Card(child: Text('$i'))),
),
const SliverToBoxAdapter(child: Text('Some footer')),
],
)
The sliver approach is superior because every child remains lazy -- only visible items are built and laid out. With shrinkWrap, the entire GridView is laid out at once, defeating the purpose of having a lazy scrollable.
Q7. What happens when you use MediaQuery.of(context) inside build() and the keyboard opens?
What the interviewer is REALLY testing:
Understanding of InheritedWidget dependency tracking and how system-level events cascade into widget rebuilds. This is a performance trap that catches even experienced devs.
Answer:
When the keyboard opens, the system reports a new viewInsets.bottom value. The MediaQuery InheritedWidget at the top of the tree updates. Every widget that called MediaQuery.of(context) in its build() method is marked dirty and rebuilds. Even if that widget only used MediaQuery.of(context).size.width and the width did not change.
This means typing in a TextField can cause dozens or hundreds of unnecessary rebuilds across your entire app.
// BAD: rebuilds whenever ANY MediaQuery property changes (keyboard, orientation, etc.)
class MyWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
final screenWidth = MediaQuery.of(context).size.width;
return SizedBox(width: screenWidth * 0.8, child: Text('Hello'));
}
}
// GOOD (Flutter 3.10+): Only rebuilds when size actually changes
class MyWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
final size = MediaQuery.sizeOf(context);
return SizedBox(width: size.width * 0.8, child: Text('Hello'));
}
}
// ALSO GOOD: Specific queries
class MyWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
final padding = MediaQuery.paddingOf(context);
final viewInsets = MediaQuery.viewInsetsOf(context);
// Each only triggers rebuild when its specific property changes
return Padding(padding: EdgeInsets.only(bottom: viewInsets.bottom));
}
}
The static methods MediaQuery.sizeOf(context), MediaQuery.paddingOf(context), MediaQuery.viewInsetsOf(context), etc., use aspect-based dependency tracking internally. They register the widget as depending only on the specific aspect of MediaQuery, not the entire object.
Q8. Why does a Container with no child have different behavior than with a child?
What the interviewer is REALLY testing:
Whether you understand that Container is a convenience widget that delegates to different render objects based on its configuration, and how sizing behavior changes.
Answer:
Container is not a single render object. It is a composition of Align, Padding, DecoratedBox, ConstrainedBox, Transform, etc. Its sizing behavior follows two rules:
- With a child: Container tries to shrink-wrap to its child's size (subject to constraints from the parent and any explicit width/height).
- Without a child: Container tries to be as large as possible (fills all available space).
// FILLS the entire parent
Container(color: Colors.red) // as big as the parent allows
// SHRINKS to the child's size
Container(
color: Colors.red,
child: Text('Hello'), // only as big as the Text widget
)
// Explicit size overrides both behaviors
Container(
width: 100,
height: 100,
color: Colors.red, // exactly 100x100 regardless of child
)
This happens because, internally, when there is no child and no explicit size, Container creates no ConstrainedBox or Align -- so the parent's constraints pass through directly, and the RenderBox defaults to taking the max size. With a child, an Align widget is inserted (default alignment: Alignment.topLeft), which shrink-wraps around the child.
This trips people up constantly:
// "Why is my Container ignoring my color when it has no size and no child?"
// Answer: it IS filling the space, but if it's inside an unbounded parent,
// it may have zero size. Check constraints.
// Debugging trick:
Container(
color: Colors.red,
child: const SizedBox.shrink(), // now it SHRINKS to zero
)
// vs
Container(
color: Colors.red, // FILLS parent
)
Q9. What happens if two widgets have the same GlobalKey?
What the interviewer is REALLY testing:
Understanding of the GlobalKey contract, the element tree, and how Flutter uses keys to track widget identity across frames.
Answer:
Flutter immediately throws an error at the framework level:
"Multiple widgets used the same GlobalKey."
This is a hard invariant. A GlobalKey is a unique identifier that must map to exactly one Element in the entire tree at any given time. Flutter maintains a global registry (Map<GlobalKey, Element>) and checks for duplicates during the build phase.
final key = GlobalKey();
// CRASHES at runtime
Column(
children: [
Container(key: key, color: Colors.red),
Container(key: key, color: Colors.blue), // DUPLICATE!
],
)
Why is this a hard error and not just a warning?
GlobalKeys are used to:
- Move a widget's state and render object between different parts of the tree without losing state (reparenting).
- Access a widget's state from outside via
key.currentState. - Access the render object via
key.currentContext?.findRenderObject().
If two elements shared a GlobalKey, the framework could not determine which one to reparent, which state to return, or which render object to reference. The result would be silent, catastrophic data corruption.
Tricky edge case: This error can appear unexpectedly in transitions/animations where a widget appears to be in two routes simultaneously (old route animating out, new route animating in). The fix is to ensure the widget only exists in one route at a time, or use ValueKey / ObjectKey instead.
Q10. What happens if you call setState() in dispose()?
What the interviewer is REALLY testing:
Whether you understand the widget lifecycle state machine and what "mounted" means at the framework level.
Answer:
You get a runtime error (in debug mode):
"setState() called after dispose(): _MyWidgetState#xxxxx(lifecycle state: defunct, not mounted)"
After dispose() is called, the State object is marked as defunct and mounted becomes false. The setState method checks mounted before proceeding and throws if the widget is unmounted.
In release mode, the assertion is stripped out, so it fails silently -- the closure runs, _dirty is set to true, but the element is already removed from the tree so no rebuild occurs. The real danger is not the crash but what happens in practice: memory leaks and use-after-free bugs.
class _MyWidgetState extends State<MyWidget> {
Timer? _timer;
@override
void initState() {
super.initState();
_timer = Timer.periodic(const Duration(seconds: 1), (_) {
setState(() {}); // This will explode after dispose!
});
}
@override
void dispose() {
_timer?.cancel(); // ALWAYS cancel timers, subscriptions, controllers
super.dispose();
}
@override
Widget build(BuildContext context) => Text('Hello');
}
The defensive pattern for async operations:
Future<void> _loadData() async {
final data = await api.fetchData();
if (!mounted) return; // Guard check before setState
setState(() {
_data = data;
});
}
Q11. What happens if you call setState() inside build()?
What the interviewer is REALLY testing:
Understanding of the build-phase lock in the Flutter framework and the pipeline scheduling mechanism.
Answer:
Flutter throws an assertion error in debug mode:
"setState() or markNeedsBuild() called during build."
During the build phase, the framework is walking the element tree and calling build() on dirty elements. Calling setState marks the current element as dirty again while it is already being built. This would create an infinite loop: build -> setState -> build -> setState -> ...
// CRASHES
@override
Widget build(BuildContext context) {
setState(() { _counter++; }); // Calling setState during build!
return Text('$_counter');
}
The framework detects this and throws. However, there is a subtle distinction: calling setState from a child widget's build that marks a different element dirty can sometimes appear to work but leads to unpredictable ordering and framework-level assertions.
What you should do instead:
// If you need to trigger state change after build:
@override
void initState() {
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_) {
setState(() { _counter++; });
});
}
// Or use the value directly without setState:
@override
Widget build(BuildContext context) {
final computedValue = _computeSomething(); // Just compute, don't setState
return Text('$computedValue');
}
Q12. What happens if you return different widget types from build() conditionally -- does Flutter recreate or update?
What the interviewer is REALLY testing:
The core widget-element reconciliation algorithm and the concept of "same position, same type" matching.
Answer:
This is at the heart of Flutter's rendering pipeline. When build() returns a new widget tree, Flutter compares it with the previous tree at each position using two checks:
- Same runtimeType?
- Same key? (if keys are present)
If both match, Flutter updates the existing Element with the new Widget's configuration (calls updateRenderObject, etc.). If either differs, Flutter unmounts the old Element and mounts a new one, destroying all state.
@override
Widget build(BuildContext context) {
if (_isLoggedIn) {
return HomePage(); // runtimeType = HomePage
} else {
return LoginPage(); // runtimeType = LoginPage
}
}
// When _isLoggedIn flips: old Element is DESTROYED, new one is CREATED.
// All state in the old widget subtree is lost.
The tricky case:
@override
Widget build(BuildContext context) {
return Container(
color: _isActive ? Colors.red : Colors.blue,
child: _isActive
? Text('Active') // same type, same position
: Text('Inactive'), // Flutter UPDATES, does NOT recreate
);
}
// The Text Element is REUSED. Its state (if it were stateful) survives.
// Flutter just updates the data property from 'Active' to 'Inactive'.
The dangerous case (same type, different semantics):
// BUG: Switching between two TextFields of the same type
Column(
children: [
if (_showEmail)
TextField(controller: _emailController)
else
TextField(controller: _passwordController),
],
)
// Flutter sees "TextField at position 0" both times. It UPDATES instead of
// recreating. The old controller might bleed into the new one.
// FIX: Add keys
if (_showEmail)
TextField(key: const ValueKey('email'), controller: _emailController)
else
TextField(key: const ValueKey('password'), controller: _passwordController),
Q13. Why does adding a Key to a widget sometimes fix list reordering bugs?
What the interviewer is REALLY testing:
Deep understanding of the Element tree diff algorithm -- specifically the linear reconciliation for children in multi-child widgets.
Answer:
Flutter's child reconciliation for MultiChildRenderObjectWidget (Row, Column, Stack, ListView, etc.) walks the old and new child lists linearly. Without keys, it matches by position: old child 0 vs new child 0, old child 1 vs new child 1, etc.
When you reorder a list, the items at each position change. Flutter sees the same type at each position and updates the Element instead of moving it. For StatelessWidgets this looks correct (the UI updates). But for StatefulWidgets, the State object stays at the same position while the Widget swapped. The State now belongs to the wrong Widget.
// BUG: State does not follow the item when reordered
ListView(
children: _items.map((item) => MyStatefulTile(title: item.title)).toList(),
)
// If _items reorder: position 0's State keeps its checkbox state,
// but the title changes. The checkbox "sticks" to the position, not the item.
// FIX: Keys make Flutter match by identity, not position
ListView(
children: _items.map((item) =>
MyStatefulTile(key: ValueKey(item.id), title: item.title)
).toList(),
)
// Now Flutter matches old and new children by key.
// It MOVES the Element (with its State) to the new position.
The algorithm with keys works as follows:
- Build a map of
Key -> Elementfrom the old children. - For each new child, look up its key in the map.
- If found, reuse that Element (move it). If not found, create a new one.
- Any old Elements with keys not present in the new list are disposed.
Without keys, this map is never built. Flutter falls back to linear position matching.
Q14. What happens when you use const constructor vs non-const -- how does it actually affect rebuilds?
What the interviewer is REALLY testing:
Understanding of Dart's compile-time constant canonicalization and how the Flutter framework's Widget.operator== interacts with the rebuild pipeline.
Answer:
const in Dart means the object is created at compile time and canonicalized: every const Text('Hello') in your entire program is the same instance in memory (identical object reference).
Flutter exploits this in two ways:
1. Widget identity skip in Element.updateChild:
When a parent rebuilds and provides a new child widget, the framework calls Widget.canUpdate(oldWidget, newWidget) to decide whether to update the existing Element. But BEFORE that, it checks object identity: if identical(oldWidget, newWidget) is true, the child is skipped entirely -- no update(), no build(), nothing. The subtree is completely untouched.
// Parent rebuilds because of its own setState.
// The const child is the SAME INSTANCE as last frame.
// Flutter skips the entire subtree.
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Count: $_counter'), // rebuilds every time
const MyExpensiveWidget(), // NEVER rebuilds (same instance)
MyExpensiveWidget(), // DOES rebuild (new instance every build)
],
);
}
2. Reduced GC pressure:
Non-const widgets are allocated on every build() call and immediately become garbage. const widgets are allocated once and live forever. In a list with 1000 items, this difference is significant.
Common misconception: "const prevents rebuilds" is imprecise. Const prevents rebuilds because the identity check passes. If you cache a widget instance yourself (non-const), you get the same optimization:
class _MyState extends State<MyWidget> {
// Cached instance -- same identity on every build
final _child = Container(color: Colors.red, width: 100, height: 100);
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('$_counter'),
_child, // identical to previous frame, subtree skipped
],
);
}
}
Q15. What happens if you put an IntrinsicHeight widget everywhere -- performance impact?
What the interviewer is REALLY testing:
Whether you understand the O(n) vs O(n^2) layout cost and the "speculative layout" mechanism.
Answer:
IntrinsicHeight is one of the most expensive widgets in Flutter. It forces a two-pass layout: first it calls getIntrinsicHeight() on its child to determine the ideal height, then it performs the real layout with that height as a constraint.
The getIntrinsicHeight() call is itself recursive -- it must walk the entire subtree to compute the intrinsic height, doing a speculative layout of every descendant. This means:
- Normal layout: O(n) where n is the number of descendants
-
IntrinsicHeightlayout: O(n) for the intrinsic pass + O(n) for the real pass = O(2n)
But if you nest IntrinsicHeight widgets:
// CATASTROPHIC: O(2^depth * n) layout cost
IntrinsicHeight( // pass 1: calls getIntrinsicHeight on child
child: Row(
children: [
IntrinsicHeight( // pass 1 of parent triggers pass 1 of this
child: Column( // which triggers intrinsic queries on these
children: [
IntrinsicHeight( // and again...
child: /* deep subtree */
),
],
),
),
],
),
)
Each nested IntrinsicHeight doubles the layout cost because the outer intrinsic pass triggers the inner intrinsic pass. With 3 levels of nesting, you get 8x the layout cost. With 10 levels, 1024x.
When IntrinsicHeight is legitimate:
- Making children in a Row the same height as the tallest child (cross-axis alignment).
- It is a "last resort" widget for when you cannot determine dimensions any other way.
Alternatives:
- Use
CrossAxisAlignment.stretchon Row/Column (free, no extra pass) - Use
Tablewidget for grid-like equal-height layouts - Use
CustomMultiChildLayoutfor manual control - Compute heights yourself and pass explicit constraints
Q16. What happens if you put a Scaffold inside a Scaffold?
What the interviewer is REALLY testing:
Whether you understand that Scaffold relies on inherited data (MediaQuery, Scaffold.of) and how nesting interacts with system insets like safe areas and the keyboard.
Answer:
It technically works but creates subtle, hard-to-debug issues:
Double safe area insets: The outer Scaffold already consumes system padding (status bar, notch). The inner Scaffold consumes it again, creating excessive padding.
Floating Action Button / Snackbar conflicts:
ScaffoldMessenger.of(context)andScaffold.of(context)find the nearest ancestor Scaffold. If you show a SnackBar, it appears in the inner Scaffold, potentially hidden or clipped.Drawer and AppBar duplication: Two app bars, two drawers -- the gesture detectors conflict.
// Common mistake in nested navigation
Scaffold(
appBar: AppBar(title: Text('Main')),
body: Navigator(
onGenerateRoute: (_) => MaterialPageRoute(
builder: (_) => Scaffold( // Inner Scaffold
appBar: AppBar(title: Text('Detail')),
body: Text('Hello'),
),
),
),
)
// Result: Two AppBars stacked. Inner Scaffold re-applies safe area insets.
// The viewInsets for keyboard are consumed twice.
Fix: Use SafeArea and AppBar independently rather than wrapping everything in Scaffold. Or remove the outer Scaffold's AppBar when the inner route is active. Or use Scaffold with resizeToAvoidBottomInset: false on the inner one to prevent double-inset consumption.
Q17. What happens when you use setState() in a StatefulWidget that is a child of a StreamBuilder or FutureBuilder?
What the interviewer is REALLY testing:
Understanding of how parent rebuilds affect child state, and the interaction between inherited state management and local state.
Answer:
When the StreamBuilder/FutureBuilder's stream emits a new value, it calls setState internally, which rebuilds itself and its entire subtree. If your StatefulWidget is in that subtree, its build() method is called again. However, its State object survives (because the Element is reused -- same type, same position).
The problem arises when you call setState in the child AND the parent rebuilds simultaneously:
StreamBuilder<int>(
stream: myStream,
builder: (context, snapshot) {
return MyStatefulChild(data: snapshot.data ?? 0);
},
)
class _MyStatefulChildState extends State<MyStatefulChild> {
late int _localCount;
@override
void initState() {
super.initState();
_localCount = widget.data; // Only runs once!
}
void _increment() {
setState(() { _localCount++; }); // local change
}
@override
Widget build(BuildContext context) {
return Text('$_localCount'); // STALE: ignores widget.data updates!
}
}
The bug: initState runs once. When the stream emits new data, the parent rebuilds and passes new widget.data, but _localCount was only initialized in initState. The widget ignores the new data.
Fix: Use didUpdateWidget to sync:
@override
void didUpdateWidget(MyStatefulChild oldWidget) {
super.didUpdateWidget(oldWidget);
if (oldWidget.data != widget.data) {
_localCount = widget.data; // Sync with new parent data
}
}
Q18. What happens if you use a ScrollController on multiple scroll views simultaneously?
What the interviewer is REALLY testing:
Understanding of the listener/attachment model and that ScrollController can only be attached to one ScrollPosition at a time (by default).
Answer:
A ScrollController can actually be attached to multiple ScrollPosition objects (this is how TabBarView works internally). But reading controller.offset when multiple positions are attached throws because the getter only works with a single attachment:
final controller = ScrollController();
// Attached to two ListViews
Column(
children: [
Expanded(child: ListView(controller: controller, children: [...])),
Expanded(child: ListView(controller: controller, children: [...])),
],
)
// controller.offset -> CRASHES: "ScrollController attached to multiple scroll views"
// controller.positions -> returns both ScrollPosition objects (works)
The offset getter is a convenience that calls position.pixels, and position asserts that positions.length == 1.
If you need to synchronize two scroll views, use a ScrollController per view and synchronize them via listeners:
final _controller1 = ScrollController();
final _controller2 = ScrollController();
@override
void initState() {
super.initState();
_controller1.addListener(() {
if (_controller2.hasClients) {
_controller2.jumpTo(_controller1.offset);
}
});
}
Or use the linked_scroll_controller package for bidirectional sync.
SECTION 2: STATE & LIFECYCLE TRAPS
Q1. What happens if you initialize a TextEditingController in build() instead of initState()?
What the interviewer is REALLY testing:
Whether you understand object lifecycle in the context of widget rebuilds, and the consequences of creating controllers on every frame.
Answer:
A new TextEditingController is created on every single rebuild. This causes:
The text field resets. Every keystroke triggers a rebuild (since TextField calls setState internally). Each rebuild creates a new controller, which has an empty initial value. The user types "H" -> rebuild -> new controller with "" -> field appears empty. In practice, Flutter's framework partially mitigates this because the TextField's State holds its own reference, but the behavior is undefined and buggy.
Memory leak. Each controller allocates native resources (ChangeNotifier listeners). Since
dispose()is never called on the old controllers, they accumulate.Lost selection/cursor position. The cursor jumps to position 0 on every rebuild.
// BAD: new controller on every build
class _MyState extends State<MyWidget> {
@override
Widget build(BuildContext context) {
final controller = TextEditingController(); // WRONG!
return TextField(controller: controller);
}
}
// CORRECT: create once, dispose once
class _MyState extends State<MyWidget> {
late final TextEditingController _controller;
@override
void initState() {
super.initState();
_controller = TextEditingController(text: 'initial');
}
@override
void dispose() {
_controller.dispose();
super.dispose();
}
@override
Widget build(BuildContext context) {
return TextField(controller: _controller);
}
}
General rule: Any object with a dispose() method (controllers, animation controllers, focus nodes, scroll controllers) must be created in initState (or later) and disposed in dispose(). Never in build().
Q2. Why does your widget rebuild when you navigate back to it? How to prevent?
What the interviewer is REALLY testing:
Understanding of how Navigator manages routes, when routes rebuild, and the difference between widget rebuild and state recreation.
Answer:
When you Navigator.push a new route and then pop back, the previous route's widget rebuilds because:
- The route transition animation causes the overlay to rebuild.
- The
Navigatoritself is a StatefulWidget that callssetStatewhen routes change. - The previous route was always in the tree (it was behind the new route) and its
buildgets called as part of the parent's rebuild.
Importantly, the State is NOT recreated -- initState does NOT fire again. Only build() is called.
Why this is usually fine: Flutter's rendering pipeline is designed for frequent rebuilds. build() should be cheap and pure.
When it IS a problem and how to fix it:
// Problem: Expensive computation in build
@override
Widget build(BuildContext context) {
final data = expensiveComputation(); // runs on every rebuild
return ListView.builder(...);
}
// Fix 1: Cache the computation in state
late final _data = expensiveComputation();
// Fix 2: Use AutomaticKeepAliveClientMixin (for TabBarView/PageView)
class _MyState extends State<MyWidget>
with AutomaticKeepAliveClientMixin {
@override
bool get wantKeepAlive => true;
@override
Widget build(BuildContext context) {
super.build(context); // required
return ExpensiveWidget();
}
}
// Fix 3: Prevent unnecessary rebuilds with const or cached widgets
// Fix 4: Use RepaintBoundary to prevent repaint propagation
The real fix for data refetching: store data in a state management solution (Provider, Riverpod, Bloc) outside the widget tree. The widget's build reads from the cache; it does not re-fetch.
Q3. What happens if you don't dispose a StreamSubscription? What about AnimationController?
What the interviewer is REALLY testing:
Understanding of memory leaks, the Dart garbage collector's limitations with cyclic references through closures, and the specific consequences for each resource type.
Answer:
StreamSubscription not disposed:
The subscription keeps a reference to the callback closure, which captures this (the State object). The State object keeps references to controllers, build context, etc. None of these can be garbage collected.
Worse: the stream keeps emitting, and the callback fires. If the callback calls setState, you get the "setState called after dispose" error. If it modifies data structures, you get use-after-free bugs.
// LEAK: subscription outlives the widget
class _MyState extends State<MyWidget> {
StreamSubscription? _sub;
@override
void initState() {
super.initState();
_sub = FirebaseFirestore.instance
.collection('users')
.snapshots()
.listen((snapshot) {
setState(() { _users = snapshot.docs; }); // fires after dispose!
});
}
@override
void dispose() {
_sub?.cancel(); // CRITICAL: cancel the subscription
super.dispose();
}
}
AnimationController not disposed:
AnimationController requires a TickerProvider (usually SingleTickerProviderStateMixin). The ticker registers with the SchedulerBinding to receive vsync callbacks every frame. If not disposed:
- The ticker keeps firing 60/120 times per second.
- The animation controller's listeners keep running.
- The
SchedulerBindingholds a reference to the ticker, preventing GC of the entire State. - You see the warning: "A Ticker was created but was never disposed."
class _MyState extends State<MyWidget>
with SingleTickerProviderStateMixin {
late final AnimationController _animController;
@override
void initState() {
super.initState();
_animController = AnimationController(
vsync: this,
duration: const Duration(seconds: 1),
);
}
@override
void dispose() {
_animController.dispose(); // stops the ticker, removes listeners
super.dispose();
}
}
Memory leak severity ranking:
- AnimationController: HIGH (60 callbacks/second, visible jank)
- StreamSubscription (Firestore/WebSocket): HIGH (network + setState crashes)
- ScrollController/TextEditingController: MEDIUM (ChangeNotifier listeners)
- FocusNode: LOW-MEDIUM (focus system reference)
Q4. What's the difference between didChangeDependencies and initState -- when would didChangeDependencies fire but initState won't?
What the interviewer is REALLY testing:
Understanding of InheritedWidget dependency registration and the exact lifecycle sequence.
Answer:
initState() fires exactly once when the State is first inserted into the tree.
didChangeDependencies() fires immediately after initState AND every time an InheritedWidget that this State depends on changes.
The dependency is registered when you call SomeInheritedWidget.of(context) (which calls context.dependOnInheritedWidgetOfExactType<T>()). After that, any time that InheritedWidget updates, didChangeDependencies is called on this State.
class _MyState extends State<MyWidget> {
late ThemeData _theme;
@override
void initState() {
super.initState();
// CANNOT call Theme.of(context) here!
// The Element is not yet fully mounted in the tree.
// InheritedWidget lookup requires walking up the tree, which is not
// ready during initState.
}
@override
void didChangeDependencies() {
super.didChangeDependencies();
_theme = Theme.of(context); // SAFE here
// This fires:
// 1. Right after initState (first time)
// 2. Every time ThemeData changes (e.g., switching dark mode)
}
@override
Widget build(BuildContext context) {
return Container(color: _theme.primaryColor);
}
}
When didChangeDependencies fires but initState does NOT:
- User switches dark mode ->
ThemeInheritedWidget updates ->didChangeDependenciesfires - Locale changes ->
LocalizationsInheritedWidget updates ->didChangeDependenciesfires -
MediaQuerychanges (keyboard, rotation) ->didChangeDependenciesfires - Parent
Providervalue changes ->didChangeDependenciesfires
In all these cases, the widget was already in the tree, so initState was long past.
Key detail: You can safely call context.dependOnInheritedWidgetOfExactType in didChangeDependencies because the element is fully mounted. In initState, it is not.
Q5. What happens if you call setState after an async gap and the widget is unmounted?
What the interviewer is REALLY testing:
Understanding of the widget lifecycle timing, async/await interaction with the element tree, and defensive programming patterns.
Answer:
After an await, the microtask resumes on the next event loop iteration. By that time, the widget may have been removed from the tree (user navigated away, parent rebuilt without this child, etc.). Calling setState on an unmounted State throws in debug mode:
"setState() called after dispose()"
In release mode, the assertion is stripped. The setState call does nothing visible (the element is not in the tree so no rebuild happens), but the callback still executes, potentially causing side effects on stale data.
// DANGEROUS
Future<void> _loadData() async {
final response = await http.get(Uri.parse('https://api.example.com/data'));
// DANGER ZONE: widget may have been disposed during the await
setState(() {
_data = jsonDecode(response.body);
});
}
// SAFE: guard with mounted check
Future<void> _loadData() async {
final response = await http.get(Uri.parse('https://api.example.com/data'));
if (!mounted) return; // Widget is gone, bail out
setState(() {
_data = jsonDecode(response.body);
});
}
In Flutter 3.7+, the Dart linter warns about this with use_build_context_synchronously. This also applies to using context after an await:
Future<void> _navigate() async {
await Future.delayed(const Duration(seconds: 2));
// BAD: context may be invalid
Navigator.of(context).pushNamed('/home');
// GOOD:
if (!mounted) return;
Navigator.of(context).pushNamed('/home');
}
Even better pattern -- use a Completer or cancel the operation:
class _MyState extends State<MyWidget> {
CancelableOperation<Response>? _operation;
void _loadData() {
_operation = CancelableOperation.fromFuture(
http.get(Uri.parse('https://api.example.com/data')),
);
_operation!.value.then((response) {
if (!mounted) return;
setState(() { _data = jsonDecode(response.body); });
});
}
@override
void dispose() {
_operation?.cancel(); // prevent the callback from ever firing
super.dispose();
}
}
Q6. Why does Provider.of(context) in initState cause an error?
What the interviewer is REALLY testing:
The exact timing of InheritedWidget dependency registration and whether the candidate understands the difference between dependOnInheritedWidgetOfExactType and getElementForInheritedWidgetOfExactType.
Answer:
Provider.of<T>(context) internally calls context.dependOnInheritedWidgetOfExactType<T>(), which registers a dependency. The framework does not allow dependency registration during initState because the Element is in the process of being mounted -- it is not yet in a stable state for the dependency tracking mechanism.
The error message is: "dependOnInheritedWidgetOfExactType<...>() was called before _MyWidgetState.initState() completed."
// CRASHES
@override
void initState() {
super.initState();
final user = Provider.of<User>(context); // ERROR!
}
// FIX 1: Use didChangeDependencies
@override
void didChangeDependencies() {
super.didChangeDependencies();
final user = Provider.of<User>(context); // WORKS
}
// FIX 2: Use listen: false (reads without registering dependency)
@override
void initState() {
super.initState();
final user = Provider.of<User>(context, listen: false); // WORKS!
// OR equivalently:
final user = context.read<User>(); // WORKS (read = of with listen:false)
}
// FIX 3: Post-frame callback
@override
void initState() {
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_) {
final user = Provider.of<User>(context); // WORKS (frame is complete)
});
}
The key distinction:
-
context.read<T>()/Provider.of<T>(context, listen: false)usesgetElementForInheritedWidgetOfExactType, which does NOT register a dependency. It is a one-time read. Safe ininitState. -
context.watch<T>()/Provider.of<T>(context)usesdependOnInheritedWidgetOfExactType, which registers a dependency. NOT safe ininitState.
Q7. What happens if you have a StatefulWidget but store state in a global variable -- what goes wrong?
What the interviewer is REALLY testing:
Understanding of widget identity, multiple instances, testing isolation, and the Flutter lifecycle contract.
Answer:
It "works" in the simplest case but breaks in at least five ways:
1. Multiple instances share state incorrectly:
int _counter = 0; // global
class CounterWidget extends StatefulWidget { ... }
class _CounterState extends State<CounterWidget> {
void _increment() => setState(() => _counter++);
@override
Widget build(BuildContext context) => Text('$_counter');
}
// Two instances on screen: both show the same counter.
// Tapping one does NOT rebuild the other (its setState was not called).
// They are now out of sync.
2. State survives widget disposal:
When the widget is removed from the tree and re-added, the global variable retains its old value. initState does not reset it. You get stale state.
3. Hot reload breaks:
Global variables survive hot reload. Your "fresh" UI shows old state.
4. Testing is impossible:
Tests run sequentially and share global state. Test B sees Test A's leftover data. Tests become order-dependent and flaky.
5. No reactive updates:
Global variables are not observable. There is no mechanism to notify the widget when the global changes from an external source (another widget, a timer, a stream). You must manually call setState on every widget that uses it.
What to use instead:
-
Statefields for widget-local state -
InheritedWidget/Providerfor tree-scoped state -
Riverpodfor app-wide state with proper lifecycle -
Bloc/Cubitfor business logic state
Q8. What happens if two Providers of the same type exist in the widget tree?
What the interviewer is REALLY testing:
Understanding of InheritedWidget shadowing and the lookup algorithm.
Answer:
The nearest ancestor wins. Provider.of<T>(context) walks up the Element tree and returns the first InheritedWidget of type T it finds. The outer Provider is shadowed -- it is completely invisible to descendants of the inner Provider.
Provider<String>(
create: (_) => 'OUTER',
child: Column(
children: [
Builder(builder: (context) {
// context.read<String>() == 'OUTER'
return Text(context.read<String>());
}),
Provider<String>(
create: (_) => 'INNER',
child: Builder(builder: (context) {
// context.read<String>() == 'INNER' (outer is shadowed)
return Text(context.read<String>());
}),
),
],
),
)
This is intentional and useful for overriding configuration:
// App-wide theme
Provider<AppConfig>(
create: (_) => AppConfig(apiUrl: 'https://api.prod.com'),
child: MaterialApp(
home: Builder(builder: (context) {
// For a specific subtree, override the config
return Provider<AppConfig>(
create: (_) => AppConfig(apiUrl: 'https://api.staging.com'),
child: StagingDashboard(), // sees staging URL
);
}),
),
)
The gotcha: If a widget depends on the OUTER provider and a parent inserts an INNER provider above it (e.g., during a refactor), the widget silently switches to reading from the inner one. No error, no warning. This can be extremely confusing to debug.
How to access the outer one from inside the inner scope: You cannot directly. You would need to save a reference before entering the inner scope or use a differently-typed wrapper.
Q9. Why does setState(() {}) with an empty callback still trigger a rebuild?
What the interviewer is REALLY testing:
Understanding of what setState actually does at the framework level -- it is NOT about the callback.
Answer:
The callback parameter to setState is a convenience for grouping mutation with the rebuild signal. The actual work of setState is:
// Simplified from the Flutter framework source
void setState(VoidCallback fn) {
assert(/* lifecycle checks */);
fn(); // execute the callback (can be empty)
_element!.markNeedsBuild(); // THIS is what triggers the rebuild
}
markNeedsBuild() is the operative call. It marks the Element as dirty and schedules a new frame. The callback is just a place to put your state mutation for readability. An empty callback still calls markNeedsBuild().
// These are ALL equivalent:
setState(() { _counter++; });
setState(() {});
_counter++;
_counter++;
setState(() {});
// They all result in: mutation happens + element marked dirty + rebuild scheduled
Why does this exist? The framework could have just exposed markNeedsBuild() directly. The callback pattern exists for two reasons:
-
Readability: Grouping mutation inside
setStatemakes it clear which changes triggered the rebuild. -
Debug assertions: The framework verifies the callback is synchronous (returns void, not Future). This prevents bugs where someone writes
setState(() async { ... })expecting the rebuild to wait for the Future (it would not).
// WRONG: async callback -- setState returns immediately, rebuild happens
// before the Future completes
setState(() async {
_data = await fetchData(); // rebuild already happened with old _data!
});
// CORRECT:
final data = await fetchData();
if (!mounted) return;
setState(() {
_data = data;
});
Q10. What happens when parent rebuilds but child is const -- does the child rebuild?
What the interviewer is REALLY testing:
The identical() check optimization in the Element tree update algorithm (covered briefly in Section 1 Q14, now testing in the state/lifecycle context).
Answer:
No. A const child widget is the same Dart object instance across rebuilds (compile-time canonicalization). When the parent rebuilds and returns its new widget tree, the framework compares each child with identical(oldWidget, newWidget). For const widgets, this returns true, and the framework short-circuits -- it does not call build() on the child, does not update the child's Element, and does not descend into the subtree at all.
class Parent extends StatefulWidget {
const Parent({super.key});
@override
State<Parent> createState() => _ParentState();
}
class _ParentState extends State<Parent> {
int _counter = 0;
@override
Widget build(BuildContext context) {
print('Parent build');
return Column(
children: [
ElevatedButton(
onPressed: () => setState(() => _counter++),
child: Text('Count: $_counter'),
),
const ChildWidget(), // NEVER rebuilds
ChildWidget(), // Rebuilds every time parent does
],
);
}
}
class ChildWidget extends StatelessWidget {
const ChildWidget({super.key});
@override
Widget build(BuildContext context) {
print('Child build'); // only prints for the non-const instance
return const Text('I am a child');
}
}
Output when button is pressed:
Parent build
Child build // only the non-const ChildWidget
Critical nuance: This only works if the widget class has a const constructor AND the instantiation site uses const. Having a const constructor alone is not enough -- you must actually invoke it with const:
// Has const constructor but NOT instantiated as const:
ChildWidget() // new instance every build, NOT optimized
// Must explicitly use const:
const ChildWidget() // same instance, IS optimized
Q11. What if initState throws an exception?
What the interviewer is REALLY testing:
Understanding of framework error handling, the ErrorWidget, and whether the Element tree can recover.
Answer:
If initState() throws, the framework catches the exception and replaces the widget subtree with an ErrorWidget (the red/yellow error screen in debug mode). The Element is left in a broken state.
@override
void initState() {
super.initState();
throw Exception('Something went wrong!');
}
// Result: Red screen with error details in debug mode.
// Grey screen with minimal info in release mode.
The lifecycle implications:
-
build()is never called (initState did not complete). -
dispose()IS called when the Element is eventually removed -- but the State is in an inconsistent state because initState did not finish. If dispose tries to access fields that were supposed to be initialized in initState, you get a secondary error.
class _MyState extends State<MyWidget> {
late final AnimationController _controller;
@override
void initState() {
super.initState();
// This line runs:
_controller = AnimationController(vsync: this, duration: Duration(seconds: 1));
// This line throws:
throw Exception('Oops');
// _data is never initialized
}
@override
void dispose() {
_controller.dispose(); // This DOES run -- _controller was initialized before the throw
// If we tried to access _data here, we'd get a LateInitializationError
super.dispose();
}
}
Best practice: Wrap risky initState logic in try-catch and set an error state:
@override
void initState() {
super.initState();
try {
_riskySetup();
} catch (e) {
_error = e; // Display error in build() instead of crashing
}
}
@override
Widget build(BuildContext context) {
if (_error != null) return Text('Error: $_error');
return NormalWidget();
}
Global error handling: Use FlutterError.onError and ErrorWidget.builder to customize error display:
ErrorWidget.builder = (FlutterErrorDetails details) {
return Center(child: Text('Something went wrong'));
};
Q12. What happens if you read context.watch inside a callback instead of build?
What the interviewer is REALLY testing:
Understanding of Provider's watch/read distinction and when dependency registration is valid.
Answer:
context.watch<T>() is designed to be called inside build(). It registers the widget as a dependent of the Provider so it rebuilds when the value changes. Calling it inside a callback (onPressed, onTap, Future.then, etc.) is wrong for two reasons:
1. It registers an unnecessary dependency. The widget will rebuild whenever the Provider changes, even if the widget only needs the value in the callback, not in the UI.
2. Provider explicitly throws in newer versions if you call watch outside of build:
// BAD: watch inside a callback
ElevatedButton(
onPressed: () {
// This registers a dependency AND reads the value
// The widget now rebuilds every time UserModel changes
// even though the button UI doesn't depend on it
final user = context.watch<UserModel>(); // WRONG
api.doSomething(user.id);
},
child: Text('Submit'),
)
// CORRECT: read inside a callback
ElevatedButton(
onPressed: () {
final user = context.read<UserModel>(); // one-time read, no dependency
api.doSomething(user.id);
},
child: Text('Submit'),
)
// CORRECT: watch inside build for reactive UI
@override
Widget build(BuildContext context) {
final user = context.watch<UserModel>(); // rebuilds when user changes
return ElevatedButton(
onPressed: () {
api.doSomething(user.id); // uses the value captured from build
},
child: Text('Hello, ${user.name}'),
);
}
The rule of thumb:
-
watch= reactive, use inbuild()only -
read= one-time read, use in callbacks, initState (with listen: false), dispose
Q13. What happens if you use Future.delayed in initState and widget gets disposed before it completes?
What the interviewer is REALLY testing:
The async lifecycle gap problem and whether the candidate knows how to handle "fire and forget" futures safely.
Answer:
The Future.delayed completes regardless of the widget's lifecycle -- it is a Dart Timer under the hood, and Dart Futures are not tied to any Flutter concept. When the callback fires after the widget is disposed:
@override
void initState() {
super.initState();
Future.delayed(const Duration(seconds: 5), () {
// Widget may be disposed by now!
setState(() { // CRASH in debug: "setState called after dispose"
_showBanner = true;
});
});
}
The three levels of fix:
// Level 1: Guard with mounted (minimum viable fix)
@override
void initState() {
super.initState();
Future.delayed(const Duration(seconds: 5), () {
if (!mounted) return; // bail out if widget is gone
setState(() { _showBanner = true; });
});
}
// Level 2: Use a Timer and cancel it (prevents the callback entirely)
class _MyState extends State<MyWidget> {
Timer? _timer;
@override
void initState() {
super.initState();
_timer = Timer(const Duration(seconds: 5), () {
setState(() { _showBanner = true; });
});
}
@override
void dispose() {
_timer?.cancel(); // callback will never fire
super.dispose();
}
}
// Level 3: Use a CancelableOperation for complex async chains
class _MyState extends State<MyWidget> {
CancelableOperation<void>? _operation;
@override
void initState() {
super.initState();
_operation = CancelableOperation.fromFuture(
Future.delayed(const Duration(seconds: 5)),
);
_operation!.value.then((_) {
if (!mounted) return;
setState(() { _showBanner = true; });
});
}
@override
void dispose() {
_operation?.cancel();
super.dispose();
}
}
Level 2 is the best for simple delays because it actually cancels the underlying Timer, freeing the resource. A Future cannot be "cancelled" in Dart -- the mounted check just ignores the result.
Q14. Explain the exact sequence of lifecycle methods when you push and pop a route.
What the interviewer is REALLY testing:
Precise understanding of the Navigator's interaction with the widget lifecycle, route awareness, and when state is preserved vs destroyed.
Answer:
Assume we have Page A and push Page B, then pop back to Page A.
PUSH (A -> B):
1. Navigator.push() called
2. Page B's StatefulWidget is created
3. Page B: createState()
4. Page B: initState()
5. Page B: didChangeDependencies()
6. Page B: build()
// Page A is NOT disposed. It remains in the tree (behind Page B).
// Page A: deactivate() is NOT called.
// Page A's State and Element are fully alive.
// If Page A uses RouteAware:
7. Page A: didPushNext() (a new route was pushed on top of me)
POP (B -> A):
1. Navigator.pop() called
2. Pop animation begins
// Page A was never gone, so:
3. Page A: build() (may rebuild due to Navigator's setState)
// Page A: initState does NOT fire (State was never disposed)
// If Page A uses RouteAware:
4. Page A: didPopNext() (the route on top of me was popped)
// After animation completes:
5. Page B: deactivate()
6. Page B: dispose()
// Page B's State is gone forever
Implementation with RouteAware:
class _PageAState extends State<PageA> with RouteAware {
@override
void didChangeDependencies() {
super.didChangeDependencies();
final route = ModalRoute.of(context);
if (route != null) {
routeObserver.subscribe(this, route);
}
}
@override
void dispose() {
routeObserver.unsubscribe(this);
super.dispose();
}
@override
void didPushNext() {
print('A new route was pushed on top of Page A');
// Good place to pause video, stop timers, etc.
}
@override
void didPopNext() {
print('The route on top of Page A was popped, Page A is now visible');
// Good place to refresh data, resume video, etc.
}
@override
Widget build(BuildContext context) => Text('Page A');
}
// In MaterialApp:
final RouteObserver<ModalRoute<void>> routeObserver =
RouteObserver<ModalRoute<void>>();
MaterialApp(
navigatorObservers: [routeObserver],
home: PageA(),
)
Key insight for interviewers: Page A is NOT removed from the tree when Page B is pushed. It stays mounted. Its build() may fire but initState will never fire again. This is why didPopNext exists -- to detect "I am visible again."
Q15. Why does addPostFrameCallback exist and when would you need it?
What the interviewer is REALLY testing:
Understanding of Flutter's frame pipeline (Build -> Layout -> Paint -> Composite) and when certain operations are only valid after the current frame is complete.
Answer:
WidgetsBinding.instance.addPostFrameCallback schedules a callback to run after the current frame has been built, laid out, and painted. It runs once (not every frame, unlike addPersistentFrameCallback).
Why it exists: During build(), initState(), and didChangeDependencies(), the widget tree is in an incomplete state. Certain operations require the tree to be fully built and laid out:
Use case 1: Reading layout information (RenderObject size/position)
@override
void initState() {
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_) {
// Now the RenderObject exists and has been laid out
final box = context.findRenderObject() as RenderBox;
final size = box.size; // SAFE: layout is complete
final position = box.localToGlobal(Offset.zero); // SAFE
print('Widget is ${size.width} x ${size.height} at $position');
});
}
If you tried to read size in initState or build, the RenderObject either does not exist yet or has not been laid out.
Use case 2: Scrolling to a position after build
@override
void initState() {
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_) {
// The ListView has been built and laid out, we can now scroll
_scrollController.jumpTo(_scrollController.position.maxScrollExtent);
});
}
Use case 3: Showing a dialog/overlay after first build
@override
void initState() {
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_) {
// Cannot show a dialog during build -- needs a completed frame
if (_shouldShowOnboarding) {
showDialog(
context: context,
builder: (_) => OnboardingDialog(),
);
}
});
}
Use case 4: Triggering setState after build completes (avoiding build-during-build)
@override
void initState() {
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_) {
// Safe to call setState here -- we're between frames
setState(() { _initialized = true; });
});
}
Frame pipeline order:
1. Animations tick (SchedulerBinding.handleBeginFrame)
2. Build phase (dirty elements rebuild)
3. Layout phase (RenderObjects compute size/position)
4. Compositing bits update
5. Paint phase (RenderObjects paint)
6. Compositing (scene sent to GPU)
7. POST-FRAME CALLBACKS fire here <---
8. Idle (microtasks, Futures, etc.)
Q16. What happens if you use a GlobalKey to access State from a completely different part of the widget tree?
What the interviewer is REALLY testing:
Whether the candidate knows that GlobalKey-based state access is an anti-pattern and understands the alternatives.
Answer:
It works -- that is the problem. GlobalKey<MyWidgetState> gives you key.currentState, which returns the State object directly. You can call methods on it from anywhere:
final _scaffoldKey = GlobalKey<ScaffoldState>();
// Somewhere far away in the tree:
_scaffoldKey.currentState?.openDrawer();
Why this is dangerous:
Tight coupling. The caller must know the exact State type and its public API. Refactoring the State breaks distant code with no compile-time safety.
Timing issues.
currentStateis null if the widget has not been built yet or has been disposed. No compile-time guarantee that the state exists.Performance. GlobalKeys are expensive. They prevent some optimizations in the Element tree because the framework must track them globally.
Breaks unidirectional data flow. State is being accessed sideways instead of flowing down through the tree. This makes the app's behavior harder to reason about.
// ANTI-PATTERN:
class ParentWidget extends StatelessWidget {
final _childKey = GlobalKey<_ChildState>();
void doSomething() {
_childKey.currentState?.refresh(); // reaching into child's state
}
@override
Widget build(BuildContext context) {
return ChildWidget(key: _childKey);
}
}
// BETTER: Use callbacks or state management
class ParentWidget extends StatefulWidget { ... }
class _ParentState extends State<ParentWidget> {
int _refreshCount = 0;
@override
Widget build(BuildContext context) {
return ChildWidget(
refreshCount: _refreshCount,
onComplete: () => setState(() => _refreshCount++),
);
}
}
The one legitimate use: GlobalKey is correct for Form validation (_formKey.currentState!.validate()) because FormState is specifically designed for this pattern and the Form widget documents it.
Q17. What is the difference between a StatefulWidget being "deactivated" vs "disposed"?
What the interviewer is REALLY testing:
Knowledge of the Element lifecycle, reparenting, and the rare but real scenario where deactivate fires without dispose.
Answer:
deactivate() is called when the Element is removed from the tree. dispose() is called when the Element will never be reinserted. The gap between them is where reparenting lives.
initState -> (active) -> deactivate -> (inactive) -> dispose -> (defunct)
| ^
| |
+-- reactivate --+ (if reparented in same frame)
Reparenting happens with GlobalKey:
final key = GlobalKey();
// Frame 1: widget is at position A
Column(
children: [
SizedBox(key: key, child: Text('Hello')),
Text('World'),
],
)
// Frame 2: widget moves to position B
Column(
children: [
Text('World'),
SizedBox(key: key, child: Text('Hello')), // MOVED, not recreated
],
)
In Frame 2, the framework:
- Calls
deactivate()on the SizedBox element (removes from old position) - Finds the same GlobalKey in the new tree
- Reinserts the element at the new position (calls
activate()) - Does NOT call
dispose()-- the State, RenderObject, and all children survive
When deactivate fires without dispose (within the same frame):
- Widget reparented via GlobalKey
- Widget moves between sliver positions in a CustomScrollView
When deactivate is followed by dispose (the common case):
- Widget is removed from the tree and not reinserted by the end of the frame
Practical implication for deactivate: Clean up anything that depends on the widget's position in the tree (InheritedWidget subscriptions are automatically cleaned up). But do NOT dispose controllers here -- the widget might be reinserted.
@override
void deactivate() {
// Remove from any InheritedWidget subscriptions manually if needed
// Do NOT dispose controllers or cancel subscriptions here
super.deactivate();
}
@override
void dispose() {
// THIS is where you dispose everything
_controller.dispose();
_subscription.cancel();
super.dispose();
}
Q18. What happens if you listen to a ChangeNotifier in initState but never remove the listener?
What the interviewer is REALLY testing:
Understanding of the observer pattern leak and the difference between ChangeNotifier.addListener and Provider's automatic subscription.
Answer:
Classic memory leak. The ChangeNotifier holds a strong reference to the callback, which captures the State object's context. Even after the widget is disposed, the ChangeNotifier keeps the reference, preventing garbage collection. When the ChangeNotifier fires, the callback runs against a defunct State.
// LEAK
class _MyState extends State<MyWidget> {
@override
void initState() {
super.initState();
myChangeNotifier.addListener(_onChanged); // registers listener
}
void _onChanged() {
setState(() {}); // will crash if widget is disposed
}
@override
void dispose() {
// FORGOT: myChangeNotifier.removeListener(_onChanged);
super.dispose();
}
@override
Widget build(BuildContext context) => Text('${myChangeNotifier.value}');
}
The subtle bug with anonymous closures:
@override
void initState() {
super.initState();
// CANNOT remove this listener -- no reference to the closure!
myChangeNotifier.addListener(() {
setState(() {});
});
}
@override
void dispose() {
// myChangeNotifier.removeListener(???); // no way to reference the same closure
super.dispose();
}
Anonymous closures cannot be removed because removeListener requires the exact same function reference. Always use a named method.
This is exactly why Provider/Riverpod exist: They manage the listener lifecycle automatically. context.watch<T>() registers AND unregisters the dependency as part of the framework's InheritedWidget mechanism. No manual cleanup needed.
Q19. Why does a StatefulWidget's State survive parent rebuilds, and when does it NOT survive?
What the interviewer is REALLY testing:
The canUpdate check and the Element reuse algorithm at a deep level.
Answer:
When a parent rebuilds, it returns a new widget tree. For each position in the tree, Flutter compares the old widget with the new widget using Widget.canUpdate():
static bool canUpdate(Widget oldWidget, Widget newWidget) {
return oldWidget.runtimeType == newWidget.runtimeType
&& oldWidget.key == newWidget.key;
}
If canUpdate returns true, the existing Element (and its State) is reused. The framework calls didUpdateWidget(oldWidget) on the State.
If canUpdate returns false, the old Element is unmounted (deactivate + dispose) and a new Element is created (createState + initState).
State SURVIVES when:
// Parent rebuilds, child is same type, same key (or both null)
@override
Widget build(BuildContext context) {
return MyStatefulChild(data: _currentData); // same type, no key
// State survives across parent rebuilds
}
State is DESTROYED when:
// 1. Type changes
return _isAdvanced ? AdvancedEditor() : SimpleEditor();
// Switching between these destroys state
// 2. Key changes
return MyWidget(key: ValueKey(_selectedId));
// When _selectedId changes, old State is disposed, new one created
// 3. Position changes (in a list without keys)
// If items are reordered, States may be mismatched (see Q13 in Section 1)
The dangerous scenario -- same type, different intent:
// BUG: Both are TextField, so State is REUSED
return _isEmail
? TextField(decoration: InputDecoration(label: Text('Email')))
: TextField(decoration: InputDecoration(label: Text('Phone')));
// The State survives the switch! Old text value bleeds into new field.
// FIX: Force recreation with a key
return _isEmail
? TextField(key: const ValueKey('email'), ...)
: TextField(key: const ValueKey('phone'), ...);
Q20. What happens if you call Navigator.of(context) where context is of the Navigator widget itself?
What the interviewer is REALLY testing:
Understanding of InheritedWidget lookup direction (upward only) and common context-related bugs.
Answer:
It crashes with: "Navigator operation requested with a context that does not include a Navigator."
Navigator.of(context) looks for a Navigator ancestor of the given context. If the context belongs to the widget that creates the Navigator (like MaterialApp), there is no Navigator above it -- the Navigator is at or below this context, not above.
// CRASH: context is from MyApp, which is ABOVE the Navigator
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: ElevatedButton(
onPressed: () {
// This context is MyApp's context, which is ABOVE MaterialApp's Navigator
Navigator.of(context).push(...); // CRASH!
},
child: Text('Go'),
),
);
}
}
// FIX: Use a context that is BELOW the Navigator
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: HomePage(), // HomePage's context is below the Navigator
);
}
}
class HomePage extends StatelessWidget {
@override
Widget build(BuildContext context) {
return ElevatedButton(
onPressed: () {
Navigator.of(context).push(...); // WORKS: context is below Navigator
},
child: Text('Go'),
);
}
}
// Alternative fix: Use Builder to get a context below Navigator
MaterialApp(
home: Builder(
builder: (context) {
// This context is below MaterialApp's Navigator
return ElevatedButton(
onPressed: () => Navigator.of(context).push(...), // WORKS
child: Text('Go'),
);
},
),
)
This same pattern applies to Scaffold.of(context), Theme.of(context), and all InheritedWidget lookups. The context must be a descendant of the widget you are looking for, not the widget itself or an ancestor.
Q21. What happens if you have a long-running isolate task and the widget that spawned it gets disposed?
What the interviewer is REALLY testing:
Understanding of Dart isolates, their independence from Flutter's widget lifecycle, and proper cleanup.
Answer:
The isolate keeps running. Isolates are independent execution units -- they have no awareness of the Flutter widget tree. Even after the widget is disposed, the isolate continues using CPU and memory.
class _MyState extends State<MyWidget> {
Isolate? _isolate;
ReceivePort? _receivePort;
@override
void initState() {
super.initState();
_startIsolate();
}
Future<void> _startIsolate() async {
_receivePort = ReceivePort();
_isolate = await Isolate.spawn(
_heavyComputation,
_receivePort!.sendPort,
);
_receivePort!.listen((data) {
if (!mounted) return;
setState(() { _result = data; });
});
}
static void _heavyComputation(SendPort sendPort) {
// This runs in a separate isolate -- it has no way to know
// if the widget is disposed. It just keeps running.
final result = /* expensive work */;
sendPort.send(result);
}
@override
void dispose() {
_isolate?.kill(priority: Isolate.immediate); // MUST kill the isolate
_receivePort?.close(); // MUST close the port
super.dispose();
}
}
With compute/Isolate.run (simpler):
class _MyState extends State<MyWidget> {
@override
void initState() {
super.initState();
_loadData();
}
Future<void> _loadData() async {
// Isolate.run returns a Future. The isolate runs to completion
// regardless of widget lifecycle.
final result = await Isolate.run(() => heavyWork());
if (!mounted) return; // guard
setState(() { _result = result; });
}
@override
Widget build(BuildContext context) => Text('$_result');
}
With Isolate.run, you cannot cancel the isolate mid-execution. It runs to completion and the result is simply ignored if the widget is disposed. For long-running isolates that should be cancellable, use Isolate.spawn with explicit kill in dispose.
Q22. When exactly does didUpdateWidget fire and what is the common mistake developers make with it?
What the interviewer is REALLY testing:
Whether the candidate understands the parent-child configuration update flow and the pitfalls of recreating resources in didUpdateWidget.
Answer:
didUpdateWidget fires when the parent rebuilds and provides a new widget of the same type and key to this Element. The old widget is passed as a parameter so you can compare configurations.
Common mistake 1: Not updating controllers when widget configuration changes
class AnimatedBox extends StatefulWidget {
final Duration duration;
const AnimatedBox({required this.duration});
@override
State<AnimatedBox> createState() => _AnimatedBoxState();
}
class _AnimatedBoxState extends State<AnimatedBox>
with SingleTickerProviderStateMixin {
late AnimationController _controller;
@override
void initState() {
super.initState();
_controller = AnimationController(vsync: this, duration: widget.duration);
}
// BUG: If parent changes `duration`, _controller still has old duration!
// MUST override didUpdateWidget:
@override
void didUpdateWidget(AnimatedBox oldWidget) {
super.didUpdateWidget(oldWidget);
if (oldWidget.duration != widget.duration) {
_controller.duration = widget.duration;
}
}
@override
void dispose() {
_controller.dispose();
super.dispose();
}
}
Common mistake 2: Disposing and recreating resources unnecessarily
// BAD: Recreating the controller on every parent rebuild
@override
void didUpdateWidget(MyWidget oldWidget) {
super.didUpdateWidget(oldWidget);
_controller.dispose(); // wasteful!
_controller = AnimationController(vsync: this, duration: widget.duration);
}
// GOOD: Only update what changed
@override
void didUpdateWidget(MyWidget oldWidget) {
super.didUpdateWidget(oldWidget);
if (oldWidget.duration != widget.duration) {
_controller.duration = widget.duration; // update in-place
}
}
Common mistake 3: Infinite loop by calling setState in didUpdateWidget unconditionally
// INFINITE LOOP RISK:
@override
void didUpdateWidget(MyWidget oldWidget) {
super.didUpdateWidget(oldWidget);
setState(() {}); // triggers rebuild -> parent may rebuild -> didUpdateWidget again
// Only call setState if actually needed, and guard with a comparison
}
Q23. What happens when you use context.select() in Provider and what makes it different from watch?
What the interviewer is REALLY testing:
Understanding of fine-grained reactivity and how select prevents unnecessary rebuilds by comparing derived values.
Answer:
context.select<T, R>() rebuilds the widget only when the selected value changes, not when any property of T changes. It extracts a specific property and compares it with the previous value using ==.
// WASTEFUL: rebuilds when ANY property of UserModel changes
@override
Widget build(BuildContext context) {
final user = context.watch<UserModel>();
return Text(user.name);
// If user.avatarUrl changes, this widget rebuilds unnecessarily
}
// EFFICIENT: rebuilds ONLY when name changes
@override
Widget build(BuildContext context) {
final name = context.select<UserModel, String>((user) => user.name);
return Text(name);
// user.avatarUrl change? No rebuild.
// user.name change? Rebuild.
}
How it works internally:
- On first build,
selectcalls the selector function, stores the result, and registers a dependency on the Provider. - When the Provider notifies,
selectcalls the selector again on the new value. - It compares the new selected value with the stored value using
==. - If they are equal, the widget is NOT marked dirty (no rebuild).
- If they differ, the widget is marked dirty and rebuilds.
Gotcha: mutable objects and == comparison:
// BUG: List identity changes even if contents are same
final items = context.select<CartModel, List<Item>>((cart) => cart.items);
// If cart rebuilds items list as a new List instance, this ALWAYS rebuilds
// even if the items are identical
// FIX: Select a primitive or use deep equality
final itemCount = context.select<CartModel, int>((cart) => cart.items.length);
// OR use a package like equatable / collection's ListEquality
Q24. What happens when you use both AutomaticKeepAliveClientMixin and const widgets in a TabBarView -- how do they interact?
What the interviewer is REALLY testing:
Understanding of the keep-alive mechanism in lazy viewports and how it interacts with widget caching.
Answer:
AutomaticKeepAliveClientMixin tells the TabBarView's viewport to keep the child's Element alive even when it scrolls off-screen. Without it, tabs that are not visible are disposed and recreated when you swipe back.
const widgets prevent rebuilds within a single Element's lifecycle but do NOT prevent the Element from being disposed when it leaves the viewport.
class _MyTabState extends State<MyTab>
with AutomaticKeepAliveClientMixin {
@override
bool get wantKeepAlive => true;
@override
Widget build(BuildContext context) {
super.build(context); // REQUIRED: must call super.build
return const ExpensiveWidget(); // const prevents rebuilds within this tab
}
}
Interaction:
- Without KeepAlive: Tab scrolls off-screen -> Element disposed -> scrolls back -> new Element created -> initState fires again -> const child is rebuilt (from scratch in new Element)
- With KeepAlive: Tab scrolls off-screen -> Element stays alive (just detached from viewport) -> scrolls back -> Element reattached -> NO rebuild needed -> const child is untouched (identical instance)
The combination is optimal: KeepAlive prevents disposal, and const prevents unnecessary rebuilds if the parent happens to rebuild while the tab is alive.
The cost of KeepAlive: Memory. Every kept-alive tab retains its full widget subtree, State objects, and render objects in memory. For tabs with heavy content (images, lists), this can be significant. Use wantKeepAlive conditionally:
@override
bool get wantKeepAlive => _hasUserInput; // only keep alive if user started editing
Q25. What happens if you create a Provider inside build() of a StatefulWidget?
What the interviewer is REALLY testing:
Whether the candidate knows the difference between "new Provider widget" and "new Provider value" and how Provider optimizes.
Answer:
If you mean creating a new Provider widget instance on every build -- this is fine. Provider's internal implementation uses InheritedWidget, and the Element is reused (same type, same position). Provider specifically handles this by comparing old and new values and only notifying dependents if the value actually changed.
But if you mean creating a new value on every build:
// BUG: new list instance on every build
@override
Widget build(BuildContext context) {
return Provider<List<String>>(
create: (_) => ['a', 'b', 'c'], // create is NOT called on rebuild
child: child,
);
}
// Actually, `create` is only called once. So this is fine.
// The real bug is with Provider.value:
@override
Widget build(BuildContext context) {
return Provider<List<String>>.value(
value: ['a', 'b', 'c'], // NEW list instance every build!
child: child,
);
}
// Provider.value uses the value directly. New instance every build
// means dependents rebuild every time parent rebuilds.
// Provider warns about this in debug mode.
The rule:
-
Provider(create: ...)-- safe in build,createonly runs once -
Provider.value(value: ...)-- the value must be stable (not created in build) -
ChangeNotifierProvider(create: ...)-- safe in build, create runs once -
ChangeNotifierProvider.value(value: ...)-- value must be stable
// WRONG: creates new ChangeNotifier on every build, then passes it as value
@override
Widget build(BuildContext context) {
return ChangeNotifierProvider.value(
value: MyNotifier(), // new instance every build! Provider will warn.
child: child,
);
}
// CORRECT: let Provider manage the lifecycle
@override
Widget build(BuildContext context) {
return ChangeNotifierProvider(
create: (_) => MyNotifier(), // created once, disposed by Provider
child: child,
);
}
Q26. What is the "BuildContext is no longer valid" error and when do you hit it?
What the interviewer is REALLY testing:
Understanding that BuildContext is an Element reference and Elements have lifecycles.
Answer:
BuildContext is literally a typedef for Element. When you store a context and use it later, you are holding a reference to an Element that may have been unmounted from the tree. Using an unmounted Element's context to look up InheritedWidgets, navigate, or show dialogs produces this error.
// DANGEROUS: storing context for later use
class _MyState extends State<MyWidget> {
late BuildContext _storedContext;
@override
Widget build(BuildContext context) {
_storedContext = context; // storing a reference to the Element
return ElevatedButton(
onPressed: _doLater,
child: Text('Go'),
);
}
Future<void> _doLater() async {
await Future.delayed(Duration(seconds: 5));
// Widget may have been disposed during the delay!
Navigator.of(_storedContext).push(...); // POTENTIALLY INVALID CONTEXT
}
}
// SAFE:
Future<void> _doLater() async {
await Future.delayed(Duration(seconds: 5));
if (!mounted) return; // context is valid only if mounted
Navigator.of(context).push(...); // use the State's own context property
}
The subtle case: Builder contexts inside dialogs/bottomsheets
showModalBottomSheet(
context: context,
builder: (sheetContext) {
// sheetContext is different from the outer context!
// It belongs to the BottomSheet's overlay entry Element.
return ElevatedButton(
onPressed: () {
Navigator.of(sheetContext).pop(); // closes the sheet
Navigator.of(context).push(...); // navigates the main navigator
// If the sheet is already closing, sheetContext becomes invalid
},
child: Text('Go'),
);
},
);
Rule of thumb: Never store BuildContext in a field. Always use the State's context property with a mounted check for async operations, or use the context parameter passed to the current build/builder method.
Q27. What is the exact behavior difference between pushReplacement and pushAndRemoveUntil?
What the interviewer is REALLY testing:
Whether the candidate understands the route stack manipulation and lifecycle implications for each navigation method.
Answer:
// pushReplacement: replaces the CURRENT (top) route only
// Stack before: [A, B, C]
Navigator.pushReplacement(context, MaterialPageRoute(builder: (_) => D()));
// Stack after: [A, B, D]
// C is disposed. B remains. A remains.
// pushAndRemoveUntil: pushes new route and removes routes until predicate is true
// Stack before: [A, B, C]
Navigator.pushAndRemoveUntil(
context,
MaterialPageRoute(builder: (_) => D()),
(route) => route.isFirst, // keep removing until we hit the first route
);
// Stack after: [A, D]
// C and B are both disposed. A remains (it matched the predicate).
// Remove ALL routes (common for logout):
Navigator.pushAndRemoveUntil(
context,
MaterialPageRoute(builder: (_) => LoginPage()),
(route) => false, // predicate never true -> remove everything
);
// Stack after: [LoginPage]
Lifecycle implications:
With pushReplacement:
- C: deactivate() -> dispose()
- D: createState() -> initState() -> build()
- B: NOT touched (stays in tree, may call build during transition)
- The transition animation plays between C (exiting) and D (entering)
With pushAndRemoveUntil:
- C and B: deactivate() -> dispose() (removed routes are disposed after animation)
- D: createState() -> initState() -> build()
- A: NOT touched
- The animation only shows C exiting and D entering. B is silently removed.
The gotcha: Routes removed by pushAndRemoveUntil are disposed after the transition animation completes, not immediately. During the animation, those routes still exist in memory. If they have timers or subscriptions, those keep firing during the transition.
Q28. What happens when you override operator== on a Widget subclass?
What the interviewer is REALLY testing:
Understanding of the framework's canUpdate and identical checks, and why overriding == on widgets is discouraged.
Answer:
The Flutter framework uses identical() (reference equality) for the fast-path skip, and Widget.canUpdate() (runtimeType + key comparison) for deciding whether to update or recreate an Element. It does NOT use operator== anywhere in the core reconciliation algorithm.
Overriding operator== on a Widget has no effect on the framework's rebuild decisions. However, it can break things:
class MyWidget extends StatelessWidget {
final String label;
const MyWidget({required this.label});
@override
bool operator ==(Object other) =>
other is MyWidget && other.label == label;
@override
int get hashCode => label.hashCode;
@override
Widget build(BuildContext context) => Text(label);
}
What this does NOT do:
- It does NOT prevent rebuilds when label is the same (the framework uses
identical, not==) - It does NOT cause
didUpdateWidgetto be skipped
What it CAN break:
- Collections: if widgets are stored in Sets or used as Map keys, the custom == can cause unexpected deduplication
- Some third-party libraries might use == on widgets (they should not, but might)
- Adds confusion for maintainers who expect == to affect rendering
What you SHOULD use instead for preventing rebuilds:
-
constconstructors (enablesidenticalcheck) -
shouldRebuildonInheritedWidget -
buildWhenon BlocBuilder -
Selectorin Provider -
React.memo-style wrappers
The Flutter team explicitly states in the Widget class documentation that operator== should not be overridden on widgets.
Q29. How do keys interact with AnimatedSwitcher and why does it sometimes not animate?
What the interviewer is REALLY testing:
Understanding that AnimatedSwitcher relies on canUpdate returning false to detect a "switch," and that same-type widgets without keys are updated, not switched.
Answer:
AnimatedSwitcher works by comparing its new child with the old child. If Widget.canUpdate returns false (different type or different key), it cross-fades between the old and new child. If canUpdate returns true, it just updates the existing child -- no animation.
// NO ANIMATION: same type, no key -> canUpdate returns true
AnimatedSwitcher(
duration: Duration(milliseconds: 300),
child: Text('$_counter'), // same type every time, just different data
)
// Result: Text updates in-place. No fade animation.
// WITH ANIMATION: key changes -> canUpdate returns false
AnimatedSwitcher(
duration: Duration(milliseconds: 300),
child: Text(
'$_counter',
key: ValueKey<int>(_counter), // different key each time
),
)
// Result: old Text fades out, new Text fades in. Beautiful.
Why this is tricky: Developers expect AnimatedSwitcher to detect content changes, but it only detects widget identity changes. Two Text widgets with different strings are "the same widget" to the framework if they have the same runtimeType and key.
// ALSO NO ANIMATION: different types but same key (null)
AnimatedSwitcher(
duration: Duration(milliseconds: 300),
child: _isLoading
? CircularProgressIndicator()
: Text('Done'),
)
// This DOES animate because the types are different!
// CircularProgressIndicator vs Text -> canUpdate returns false.
// BUT: if both branches return same type, add a key
AnimatedSwitcher(
duration: Duration(milliseconds: 300),
child: _isLoading
? Text('Loading...', key: ValueKey('loading'))
: Text('Done', key: ValueKey('done')),
)
Q30. What is the exact difference between a RepaintBoundary and the "isRepaintBoundary" property on RenderObject? When should you add one manually?
What the interviewer is REALLY testing:
Understanding of the compositing and painting pipeline and performance optimization at the render layer.
Answer:
When Flutter paints, it walks the render tree and paints into a PaintingContext's canvas. By default, all render objects in a subtree paint into the same layer. When one render object is dirty (needs repaint), the entire layer is repainted.
A RepaintBoundary creates a new compositing layer for its subtree. When something inside the boundary is dirty, only that layer is repainted. The parent layer is untouched. Conversely, when something outside changes, the boundary's layer is untouched.
// Without RepaintBoundary: clock ticking repaints the entire screen
Stack(
children: [
HeavyStaticBackground(),
AnimatedClock(), // repaints 60fps, dirties the whole layer
],
)
// With RepaintBoundary: clock repaints its own layer only
Stack(
children: [
HeavyStaticBackground(),
RepaintBoundary(
child: AnimatedClock(), // repaints its own layer, background untouched
),
],
)
isRepaintBoundary vs RepaintBoundary widget:
-
isRepaintBoundaryis a property onRenderObjectthat certain render objects set totrueautomatically (e.g.,RenderView,RenderRepaintBoundary,RenderListBody). -
RepaintBoundaryis a widget that creates aRenderRepaintBoundaryrender object, which hasisRepaintBoundary = true.
When to add one manually:
- A small area of the screen animates frequently while the rest is static (clocks, progress indicators, particle effects)
- A complex static subtree that should not be repainted when siblings change
- Individual items in a list with complex rendering
When NOT to add one:
- Everywhere. Each RepaintBoundary adds a compositing layer, which consumes GPU memory and increases the compositing cost. The "compositing bits" update pass also becomes more expensive.
- On widgets that always repaint together with their parent anyway.
- Flutter already adds them in
ListViewitems,Navigatorroutes, etc.
Debugging tool:
// In debug mode, this shows repaint boundaries:
debugRepaintRainbowEnabled = true;
// Each layer gets a rotating color on repaint.
// Rapidly changing colors = frequent repaints.
That concludes the deep-dive interview question set. These questions cover the most common traps, misconceptions, and edge cases that separate developers who have memorized documentation from those who truly understand how Flutter works under the hood.
Top comments (0)