Navigation & App Structure
From one screen to a whole app
Section titled “From one screen to a whole app”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.
What this module covers
Section titled “What this module covers”| Lesson | What you’ll learn |
|---|---|
| Navigator & routes | The route stack, push/pop, named routes, passing and returning data |
| Declarative routing | go_router, URL sync, deep linking, nested routes, auth redirects |
| App scaffolding | MaterialApp, Scaffold, theming, and responsive/adaptive layout |
| Platform channels | MethodChannel, EventChannel, and the bridge to native code |
The shape of a Flutter app
Section titled “The shape of a Flutter app”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)"]
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.