Skip to content

Navigation & App Structure

A widget tree draws one screen. A real app has many screens, a back button, deep links, a theme, and — eventually — a need to talk to the platform underneath. This module is about the structure that holds all of that together.

The through-line is a single shift in thinking: navigation started imperative (push this screen, pop that one) and moved to declarative (the route stack is a function of app state). Understanding why that shift happened explains most of modern Flutter routing.

LessonWhat you’ll learn
Navigator & routesThe route stack, push/pop, named routes, passing and returning data
Declarative routinggo_router, URL sync, deep linking, nested routes, auth redirects
App scaffoldingMaterialApp, Scaffold, theming, and responsive/adaptive layout
Platform channelsMethodChannel, EventChannel, and the bridge to native code
flowchart TB
  app["MaterialApp
(theme, routing config)"] --> router["Router / Navigator
(the route stack)"]
  router --> scaffold["Scaffold
(appBar, body, nav)"]
  scaffold --> screen["your screen widgets"]
  screen -. platform channel .-> native["native code
(iOS / Android)"]
The layers that structure an app

At the top sits MaterialApp, which wires up the theme and the routing configuration. Below it, the router manages a stack of routes. Each route renders a Scaffold — the standard frame with an app bar, body, and navigation slots. And when Dart alone is not enough, a platform channel reaches down to native code.

What is the core shift in modern Flutter navigation?
What does `MaterialApp` sit at the top of an app to provide?
The screen you currently see is best thought of as: