Who draws the UI? Part 1.

Flutter draws its own UI with a bundled engine (Impeller/Skia) instead of wrapping native widgets via a bridge. No native-UI bridge → consistent, fully-controllable UI across platforms.

Tree + composition.

The entire UI — structure, layout, styling, the app itself — is a tree of widgets you build by composing small, single-purpose widgets (padding, centering, color are each their own widget you wrap around children).

Dart + an engine.

You write Dart; the engine (C++) rasterizes pixels via Impeller (modern) or Skia, talking nearly directly to the GPU.

It ships its own widgets.

Because it doesn't depend on the platform's system widgets (which change between OS versions) — it ships its widget set with your app and draws everything itself.

Framework / engine / embedder.

Framework (Dart: widgets, rendering, animation, gestures), Engine (C++: Impeller/Skia, Dart runtime, text, I/O), Embedder (platform-specific: surface + input/lifecycle). Each is replaceable.

JIT vs AOT.

Dev uses JIT (Dart VM) → enables hot reload. Release uses AOT → native machine code, fast startup, no interpreter.

Declarative.

The UI is a pure function of state: you describe the UI for the current state in build, and when state changes Flutter recomputes the UI. Declarative, not imperative mutation.

runApp → MaterialApp → Scaffold → Center.

import 'package:flutter/material.dart';
void main() => runApp(const MaterialApp(
  home: Scaffold(body: Center(child: Text('Hi'))),
));

Wrap, don't configure.

Center(child: Padding(padding: const EdgeInsets.all(16), child: Text('Hi')));

Native look vs consistency.

Trade-off: widgets don't automatically adopt each OS's exact native look/conventions (Flutter favors identical everywhere). Mitigated by shipping Material and Cupertino design systems + full customization.

No native widgets to talk to.

Because Flutter doesn't use native UI components, there's nothing to serialize/marshal across a bridge for rendering — it composites the whole scene itself and pushes it to the GPU. (Platform channels exist for non-UI native calls, but the UI hot path has no bridge.)

Replaceable bottom layers.

The framework sits on a swappable engine + embedder. Porting to a new platform means providing an embedder (surface, input, lifecycle) and engine backend; the Dart framework code stays the same. (On web, Dart compiles to JS/WASM with a web renderer.)

Blueprint / bridge / worker. Part 2.

Widget = immutable description (recreated constantly). Element = persistent bridge holding State + position, decides update vs replace. RenderObject = layout/paint/hit-test.

The cheap one.

The Widget tree — immutable blueprints recreated on every rebuild.

Holds State.

The Element tree (and the RenderObjects). It persists and is mutated in place, which is why rebuilds are cheap.

Not on the widget.

On the Element, which is persistent. Widgets are recreated and discarded each rebuild, but the Element (and its State) is kept alive — so the data survives.

Type + key.

It compares the new widget with the old: same runtimeType and key → reuse the Element (update RenderObject in place). Different → replace the Element/RenderObject (State lost).

Same type?

(a) Reuse (same Text type, text updates). (b) Replace (Text→Icon, different type).

Structural vs render widgets.

No. Only render widgets (Padding, Center, Text, Opacity…) do. StatelessWidget/StatefulWidget just build others, so the RenderObject tree is shorter than the widget tree.

It's an Element.

BuildContext is the Element — the widget's position in the live tree. That's why it can look up ancestors (Theme.of, Navigator.of).

Matching by position.

Element matching is by position + type. Reordering same-typed widgets keeps the Elements (and their State) in place while the widgets swap, so State sticks to the position, not the logical item.

Give identity.

Add a stable Key: Tile(key: ValueKey(item.id), ...). The key lets Element matching follow logical identity across reordering.

Disposable vs cached.

Widgets (cheap descriptions) are thrown away and recreated, but the expensive Elements/RenderObjects are reused and mutated in place — so rebuilding thousands of widgets just updates existing machinery.

Same type, moving.

Only when widgets of the same type change position in a list/collection (and you need to preserve their identity/State). For static, non-moving trees, keys usually aren't needed.

Matched by slot.

The Elements stay in their slots and are simply handed the other's widget config (they're the same type), so nothing visibly breaks for stateless Text — but if they held State, the State would stay with the position, not the content. Keys fix that.

Memory. Part 3.

Stateless renders from immutable inputs and can't change itself. Stateful has a State object that holds changing data and can rebuild via setState.

Immutable widget + durable data.

The widget must stay immutable (recreated each rebuild), so a separate State object holds the mutable data and persists on the Element.

bool + setState.

class _S extends State<Toggle> {
  bool on = false;
  @override
  Widget build(c) => TextButton(
    onPressed: () => setState(() => on = !on),
    child: Text(on ? 'ON' : 'OFF'));
}

Mutate + schedule.

(1) Runs your callback where you mutate state, (2) marks the Element dirty to schedule a rebuild on the next frame.

Outside the callback.

Mutating state outside the setState callback — the variable changes but no rebuild is scheduled, so the UI silently goes stale.

Set up vs tear down.

initState (once, on creation): set up controllers, subscriptions, initial fetch. dispose (once, on removal): tear those down. They pair to avoid leaks.

Cancel where?

@override
void dispose() { _sub.cancel(); super.dispose(); }

Anything subscribed/created in initState must be cleaned up in dispose.

New config from parent.

When the parent rebuilds and gives this State a new widget configuration. Use it to react to changed input props (if (widget.id != oldWidget.id) refetch();).

No State, no setState.

A StatelessWidget has no State/setState, so mutating n never schedules a rebuild; and the widget is recreated (resetting n). It must be a StatefulWidget.

Simpler is better.

Default to Stateless — simpler, cheaper, easier to reason about. Use Stateful only when you have local changing data or a lifecycle (controller/subscription) to manage.

Widget may be gone.

After an await, the widget may have been disposed (user navigated away). Calling setState on a disposed State throws. Guard with if (!mounted) return;.

One source of truth.

Lift the state up to a common ancestor (or a state-management solution) and pass it down to Stateless children — single source of truth, no drift.

Controller lifecycle.

Stateful — create an AnimationController in initState (with a TickerProvider via SingleTickerProviderStateMixin) and dispose it in dispose. The animation rebuilds the subtree each frame.

Describe, don't do. Part 4.

Return a widget subtree describing the UI for the current state (UI = f(state)). It must be fast and side-effect-free.

Just blueprints.

No — it constructs immutable widget blueprints; Elements reconcile and RenderObjects paint.

setState, ancestor, inherited.

setState; an ancestor rebuilding; an InheritedWidget it depends on changing (Theme/MediaQuery/Provider). Also: first mount, new parent config, animation frames, hot reload.

Create once.

late final _f = api.get(); // or assign in initState
Widget build(c) => FutureBuilder(future: _f, builder: ...);

Creating the future inside build re-fires on every rebuild.

Called constantly.

It can run 60+ times a second (animations, ancestor rebuilds, inherited changes). Side effects (I/O, setState, timers) would fire repeatedly, causing duplicate work and bugs.

Skipped on rebuild.

A const widget is created once and reused/skipped on rebuild instead of being reconstructed — free performance for unchanging subtrees.

Per frame.

~60 — once per frame. Hence build must be cheap.

Not the whole app.

Only the calling widget and its descendants — targeted, not app-wide.

Push down + const.

(1) Push state down — extract the changing bit into its own widget and setState there (rebuild a small subtree). (2) Mark unchanging subtrees const. (Also: lazy ListView.builder.)

Registers a dependency.

.of(context) registers the widget as a dependent of that InheritedWidget. When the Theme changes, Flutter rebuilds all dependents automatically.

Lifecycle.

In initState (store the Future), then reuse it via FutureBuilder in build. build describes; initState/handlers do work.

Lazy.

ListView.builder is lazy — it builds only the items currently visible (plus a small buffer), not all 10,000, keeping each frame cheap. A plain ListView with all children builds them all upfront.

Direction. Part 5.

Row lays children out horizontally; Column vertically. Same flex concept, rotated 90°.

Vertical.

The vertical axis. So mainAxisAlignment moves children up/down; crossAxisAlignment moves them left/right.

spaceBetween / Spacer.

Row(mainAxisAlignment: MainAxisAlignment.spaceBetween,
    children: const [Text('Back'), Text('Next')]);

Fill perpendicular.

Forces children to fill the cross axis (e.g. full width in a Column).

Take leftover.

Forces the child to fill all remaining main-axis space (ignoring its natural size). Multiple Expanded split space by flex ratio.

flex.

Row(children: [
  Expanded(flex: 2, child: Container(color: Colors.red, height: 40)),
  Expanded(flex: 1, child: Container(color: Colors.blue, height: 40)),
]);

tight vs loose.

Expanded = Flexible(fit: tight) — must fill its share. Flexible (loose) takes only as much as needed, capped at its share.

Flexible gap.

A flexible empty space — shorthand for Expanded(child: SizedBox()). Pushes siblings apart.

Confine the text.

Row(children: [
  const Icon(Icons.person),
  Expanded(child: Text(longName, overflow: TextOverflow.ellipsis)),
  const Icon(Icons.star),
]);

Not enough main-axis space.

A Row/Column's children wanted more main-axis space than available; Flutter overflows instead of shrinking. Fix with Expanded/Flexible, scrolling, or Wrap.

No leftover space.

It needs leftover main-axis space to distribute. With MainAxisSize.min the flex wraps its children exactly, leaving no space — so alignment has no visible effect.

Fill or wrap.

Whether the Row/Column takes the full available main-axis extent (max, default) or shrinks to wrap its children (min).

Multiple lines.

When children should flow onto multiple lines when they run out of width (chips/tags), instead of overflowing. Wrap wraps to the next line; Row doesn't.

Layers. Part 6.

Layers children on top of each other (later children paint over earlier). For overlaps — badges, text over images, overlays.

Stack + Positioned.

Stack(children: [
  const CircleAvatar(radius: 30),
  Positioned(right: 0, top: 0, child: Container(width: 12, height: 12,
    decoration: const BoxDecoration(color: Colors.red, shape: BoxShape.circle))),
]);

Parent-specific.

Only as a direct child of a Stack. It's a parent-data widget meaningful only inside a Stack.

The famous sentence.

"Constraints go down. Sizes go up. Parent sets position." Constraints flow down; each child picks a size within them and reports up; the parent positions it.

min==max?

Tight: min==max — parent forces an exact size (child has no choice). Loose: min 0 — child may be any size up to max.

Tight constraints.

The body passes tight (full-screen) constraints, and a tightly-constrained widget can't choose its size — so width: 100 is overridden.

Loosen.

Center(child: Container(width: 100, height: 100, color: Colors.red));

Center passes loose constraints down, letting the Container be 100×100.

Parent decides.

No — the parent sets position. To move a widget, wrap it in Align/Center/Padding/Positioned or use a flex alignment.

LayoutBuilder.

LayoutBuilder(builder: (c, cons) =>
  cons.maxWidth < 600 ? const OneCol() : const TwoCol());

Single pass.

Layout is one pass: constraints flow down once, sizes flow up once — each RenderObject is visited essentially once, no backtracking or multiple passes.

Only adds.

ConstrainedBox can only add (tighten) constraints, not loosen incoming ones. Under tight parent constraints it passes them through, so its own min/max have no effect — wrap in Center to loosen first.

Widget's own rule.

An unconstrained, childless Container chooses to be as big as possible; given a child (with loose constraints) it sizes to the child. It's a design choice of the Container widget — the answer is always "what constraints come in, and what this widget does with them."

Builder.

LayoutBuilder — its builder receives the BoxConstraints so you can branch on available space.

State preserved? Part 7.

Hot reload injects code + rebuilds the tree preserving state (no main/initState re-run). Hot restart resets state and re-runs main/initState.

No.

No — existing State objects are preserved, so initState (which runs only on creation) does not re-run. Only build re-runs.

build re-runs.

Hot reload — build re-runs, change appears instantly.

Elements live.

Hot reload keeps the running app's objects — the persistent Element tree and its State — alive, swapping in new code and rebuilding. State lives on the durable Element, so it survives.

Recreate State.

Hot restart — it recreates the State and re-runs initState. Reload preserves State and skips initState.

Lazy once.

Static/global fields are lazily initialized once; reload doesn't re-init them. Make it const or a getter (or hot restart).

Native.

Native code (Kotlin/Java/Swift/Obj-C), new plugins, or new assets/dependencies — they need the native layer/bundle recompiled.

reload/restart/full/restart.

(a) hot reload; (b) hot restart; (c) full restart; (d) hot restart (type shape changed).

AOT.

Release builds are AOT-compiled to native machine code, which can't accept new source at runtime. Hot reload relies on the dev JIT VM that can load new code into the running program.

Type shape.

They change the structure/shape of a type, which the running VM can't reconcile by swapping code in place — so the app must restart to rebuild type information.

Not re-executed.

If the modified code isn't re-executed as part of rebuilding the widget tree (e.g. it only runs in main/initState/a one-time branch), its effects won't show. Hot restart to be sure.

Stale setup.

A controller/data initialized once in initState keeps its old value across reloads, so your new setup code never runs and you don't notice a mistake — until a hot restart runs initState honestly and reveals it.

LIFO. Part 8.

A stack of routes (screens). push adds on top; pop removes the top.

push + MaterialPageRoute.

Navigator.push(context,
  MaterialPageRoute<void>(builder: (_) => const SecondScreen()));

Transition.

It wraps the destination widget and gives a platform-appropriate transition animation; its builder returns the screen.

pop.

Navigator.pop(context);

Constructor.

Through the destination widget's constructor — typed, compiler-checked Dart, no casting.

push returns a Future.

final v = await Navigator.push<int>(context,
  MaterialPageRoute<int>(builder: (_) => const Picker()));
if (!mounted) return;
if (v != null) setState(() => _n = v);
// Picker: Navigator.pop(context, 7);

settings.arguments.

Via pushNamed(context, '/x', arguments: data) and reading ModalRoute.of(context)!.settings.arguments — but it's untyped (Object? you cast), less safe than constructor args.

Map in MaterialApp.

MaterialApp(routes: {
  '/': (_) => const Home(),
  '/profile': (_) => const Profile(),
});
// Navigator.pushNamed(context, '/profile');

Don't also set home:.

Stack vs replace.

push stacks a new route on top (back returns to current). pushReplacement replaces the current route (back skips it) — e.g. splash → home.

Clear the stack.

Navigator.pushAndRemoveUntil(context, homeRoute, (route) => false) — pushes home and removes all routes below, erasing the auth flow from history.

Walk up to Navigator.

context is the Element; push walks up to the nearest Navigator (provided by MaterialApp). A context above MaterialApp can't find one → "No Navigator" error. Use a descendant context (or a Builder).

Dynamic routes.

A central hook to build routes dynamically — parse parameters/IDs, guard access, handle unknown routes and deep links, and apply custom transitions — instead of (or alongside) a static routes table.

class Counter extends StatefulWidget {
  const Counter({super.key});
  @override
  State<Counter> createState() => _CounterState();
}
class _CounterState extends State<Counter> {
  int _n = 0;
  @override
  Widget build(BuildContext context) => Scaffold(
    body: Center(child: Text('$_n', style: const TextStyle(fontSize: 48))),
    floatingActionButton: FloatingActionButton(
      onPressed: () => setState(() => _n++),
      child: const Icon(Icons.add)),
  );
}

State on the Element (Part 3); setState mutates + rebuilds (Part 4).

Row(children: [
  const CircleAvatar(child: Icon(Icons.person)),
  const SizedBox(width: 12),
  Expanded(child: Column(
    mainAxisSize: MainAxisSize.min,
    crossAxisAlignment: CrossAxisAlignment.start,
    children: const [
      Text('Vivek', style: TextStyle(fontWeight: FontWeight.bold)),
      Text('Tap to view', overflow: TextOverflow.ellipsis),
    ])),
  const Icon(Icons.chevron_right),
]);

Expanded confines the text block so it never overflows (Part 5).

Stack(clipBehavior: Clip.none, children: [
  const Icon(Icons.notifications, size: 40),
  Positioned(right: 0, top: 0, child: Container(
    padding: const EdgeInsets.all(4),
    decoration: const BoxDecoration(color: Colors.red, shape: BoxShape.circle),
    child: const Text('5', style: TextStyle(color: Colors.white, fontSize: 10)))),
]);

Positioned (direct Stack child) pins the badge (Part 6).

// Home:
ElevatedButton(
  onPressed: () => Navigator.push(context,
    MaterialPageRoute<void>(builder: (_) => const Detail())),
  child: const Text('Open'));
// Detail: Scaffold(appBar: AppBar(title: Text('Detail'))) // auto back

The AppBar's auto back button pops (Part 8).

Future<void> _pick() async {
  final c = await Navigator.push<String>(context,
    MaterialPageRoute<String>(builder: (_) => const Picker()));
  if (!mounted) return;
  if (c != null) setState(() => _color = c);
}
// Picker tile: onTap: () => Navigator.pop(context, 'green');

push returns a Future; pop(context, value) completes it (Part 8 + async/await).

LayoutBuilder(builder: (context, c) {
  final cols = c.maxWidth < 600 ? 2 : 4;
  return GridView.count(crossAxisCount: cols, children: tiles);
});

LayoutBuilder exposes incoming constraints (Part 6).

Timer? _t;
int _s = 0;
@override
void initState() {
  super.initState();
  _t = Timer.periodic(const Duration(seconds: 1), (_) {
    if (!mounted) return;
    setState(() => _s++);
  });
}
@override
void dispose() { _t?.cancel(); super.dispose(); }
@override
Widget build(BuildContext context) => Text('$_s');

initState/dispose pair to avoid leaks (Part 3).

If you originally ran with x = 0 in initState and then edited it to 100 and hot reloaded, the label keeps the old value because hot reload preserves State and doesn't re-run initState (Part 7). Hot restart to recreate the State and run initState, showing 100.

// Parent owns the state; children are stateless and receive value + callback.
class _ParentState extends State<Parent> {
  int _count = 0;
  @override
  Widget build(BuildContext c) => Column(children: [
    CountLabel(count: _count),
    IncrementButton(onTap: () => setState(() => _count++)),
  ]);
}

Single source of truth in the parent; children stay Stateless (Part 3).

import 'package:flutter/material.dart';

void main() => runApp(const MaterialApp(home: NotesScreen()));

class NotesScreen extends StatefulWidget {
  const NotesScreen({super.key});
  @override
  State<NotesScreen> createState() => _NotesScreenState();
}

class _NotesScreenState extends State<NotesScreen> {
  final List<String> _notes = ['Welcome', 'Buy milk'];

  Future<void> _addNote() async {
    final title = await Navigator.push<String>(
      context,
      MaterialPageRoute<String>(builder: (_) => const AddNoteScreen()),
    );
    if (!mounted) return;                         // guard after await
    if (title != null && title.isNotEmpty) {
      setState(() => _notes.add(title));          // mutate + rebuild
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Notes')),
      body: ListView.builder(                     // lazy list
        itemCount: _notes.length,
        itemBuilder: (context, i) => ListTile(
          title: Text(_notes[i]),
          trailing: const Icon(Icons.chevron_right),
          onTap: () => Navigator.push(
            context,
            MaterialPageRoute<void>(
              builder: (_) => NoteDetailScreen(title: _notes[i]), // pass via ctor
            ),
          ),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _addNote,
        child: const Icon(Icons.add),
      ),
    );
  }
}

class NoteDetailScreen extends StatelessWidget {       // stateless: just displays
  final String title;
  const NoteDetailScreen({super.key, required this.title});
  @override
  Widget build(BuildContext context) => Scaffold(
    appBar: AppBar(title: Text(title)),
    body: Center(child: Text(title, style: const TextStyle(fontSize: 24))),
  );
}

class AddNoteScreen extends StatefulWidget {
  const AddNoteScreen({super.key});
  @override
  State<AddNoteScreen> createState() => _AddNoteScreenState();
}

class _AddNoteScreenState extends State<AddNoteScreen> {
  final _controller = TextEditingController();        // created in State

  @override
  void dispose() {
    _controller.dispose();                            // cleaned up — no leak
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Add note')),
      body: Padding(
        padding: const EdgeInsets.all(16),
        child: Column(children: [
          TextField(controller: _controller, autofocus: true),
          const SizedBox(height: 12),
          ElevatedButton(
            onPressed: () => Navigator.pop(context, _controller.text), // return result
            child: const Text('Save'),
          ),
        ]),
      ),
    );
  }
}

This one app exercises the whole series: Stateless vs Stateful and the State lifecycle with a disposed TextEditingController (Part 3); setState/build discipline and lazy ListView.builder (Part 4); flex layout with Column/Padding (Part 5); and Navigator push/pop, passing data via constructor, and returning a result through the push Future (Part 8). Build it, run it, and you've proven you understand Flutter's fundamentals.