Crash Course Overview
Read time: ~12-15 min
Teach: The top ~10% of Flutter Fundamentals stitched into one tour. See: Each pillar of the course — what Flutter is, the Dart bridge, widgets-as-tree, layout primitives, stateful interactivity, app-wide state, and the architecture that ties it all together — illustrated with the same diagrams used in the full modules. Feel: Confident you understand the shape of every Flutter app you'll build, and ready to dive into the modules with a map already in your head.
Where this fits: Read this first if you want a fast tour, or read it last as a refresher before the capstone. It is not a substitute for the modules — there are no exercises here, no hot-reload moments, no flutter doctor to argue with. It is a map.
What Flutter is
Flutter is Google's open-source UI toolkit that lets you build beautiful, natively compiled applications for mobile, web, and desktop — all from a single codebase. It's not a toy. It's powering apps at Google, BMW, Alibaba, and thousands of other companies.
That single sentence is the whole pitch. One codebase, every platform, native compilation. The tradeoff is that Flutter doesn't borrow native widgets the way React Native does — it draws every pixel itself with its own rendering engine. Identical UI on every platform, total control over every detail.
Dart is the door
I know what you're thinking: "I came here to build Flutter apps, not learn another language." I hear you. But Flutter IS Dart. Every widget you write, every callback, every bit of state management — it's all Dart code. The developers who struggle with Flutter almost always struggle because their Dart is shaky. The developers who fly through it are the ones who invested a week upfront learning the language properly. So give yourself the next three modules. By Module 04, when we finally touch widgets, you'll feel the difference.
If you know Java, JavaScript, Kotlin, or C#, Dart will feel familiar within an hour. The big things to internalize early: var/final/const, named parameters (Flutter uses them everywhere), null safety, and async/await for futures.
Everything is a widget
If you've ever written HTML, you already understand nesting. A <div> inside a <div> inside a <body>. Same idea here — except instead of HTML tags, you have Dart objects called widgets. And instead of CSS for styling, you configure widgets with parameters.
That nested structure is called the widget tree. The whole UI of any Flutter app — from a hello-world counter to a shipped production app — is one giant tree of widgets, with MaterialApp at the root and your individual buttons and texts as the leaves. Mastering Flutter is mostly mastering how to compose, parameterize, and re-shape this tree.
Stateless widgets are recipes
Here's a mental model that helps: a StatelessWidget is like a recipe. You give it ingredients (parameters), and it always produces the same dish (UI). Same ingredients, same result, every time. It doesn't remember what it made yesterday. It doesn't change its mind mid-cook. Pure, predictable, reliable.
Most of the widgets you write will be stateless. They take some final inputs in their constructor and return a widget tree from build(). The five-line ritual is muscle memory: extend StatelessWidget, declare final fields, write a const constructor with super.key, override build, return a tree. Once it's automatic, you stop noticing it — and every const constructor unlocks real performance gains in the rebuild cycle.
MaterialApp and Scaffold — the foundation
Think of MaterialApp as the building and Scaffold as a room. The building provides electricity, plumbing, and an address (theme, navigation, context). Each room has walls, a door, and maybe some furniture (app bar, body, FAB). You'll have one MaterialApp and many Scaffold screens.
Every Flutter app starts with a MaterialApp (or CupertinoApp for iOS-style). Inside it, each screen is a Scaffold — the standard frame that gives you an app bar, a body slot, an optional floating action button, and so on. Learn this duo first; everything else hangs off it.
Layout is just nested widgets
If you only learn two layout widgets today, make them Row and Column. These are the workhorses of Flutter layout. Almost every screen you'll ever build starts with a Column of things stacked top to bottom, and inside that column, Rows of things arranged left to right. Sound simple? That's the whole idea.
There's no separate stylesheet or XML layout file in Flutter. Layout is widgets nesting inside widgets. Column stacks children vertically, Row arranges them horizontally, and Expanded / Flexible decide how leftover space gets shared. That's the entire mental model — every complex screen is just these primitives nested deeper.
If Row and Column are the bread and butter, Container is the Swiss Army knife. Need padding? Container. Need a background color? Container. Need rounded corners? Container. Need a fixed size? Container. It does a lot of things, and knowing when to use it -- and when NOT to use it -- is a skill you'll develop over time.
When you need one thing — just padding, just sizing, just a colored box — reach for the specific widget (Padding, SizedBox, ColoredBox). Reach for Container only when you need several of those at once.
Stateful widgets and setState
Stateless widgets are static — once they're on screen, they don't change. But real apps have counters that increment, toggles that flip, timers that tick. That's what StatefulWidget is for. It pairs an immutable widget class with a mutable State object. You hold your changing data in the State class, mutate it inside setState(() { ... }), and Flutter re-runs build to refresh the UI.
The contract is simple: change your state inside the setState callback, Flutter calls build again afterward. Default to StatelessWidget. Convert to StatefulWidget only when something on screen genuinely needs to change in response to a tap, a timer, or an external event.
Hot reload — the superpower
Hot reload doesn't restart your app. It injects your updated code into the running Dart VM and rebuilds the widget tree. Your app's state — scroll position, text in fields, navigation stack — all stays exactly where it was. It's like changing the tires on a car while it's still driving.
This is the feedback loop that makes Flutter feel different from every other UI framework. Save a file, hit r, see the change in under a second with state preserved. It changes how you experiment, how you tweak design, and how confidently you refactor.
App-wide state with Provider
You have been passing data between widgets through constructors. Parent builds child, passes data down. Child needs to tell parent something? Callback function, passed down. It works. Until it doesn't. Imagine a shopping cart. The cart icon in the AppBar needs the item count. The product list needs to add items. The cart screen needs to display items and update quantities. The checkout screen needs the total. That cart data has to flow through every widget between those screens, even widgets that do not care about the cart at all. This is called prop drilling, and it is the problem that state management solves.
setState handles state that lives in one widget. When several widgets across the tree need the same state — user session, shopping cart, theme, settings — you reach for Provider. The model is a plain Dart class that extends ChangeNotifier and calls notifyListeners() whenever its data changes. No annotations, no code generation, just a class that yells when something changes.
The setState-versus-Provider decision confuses people more than it should. Here's the one-line rule: if only THIS widget cares about the value, setState. If multiple widgets care, Provider. A text field's current text? Only the field cares until the user submits — setState is fine. The current user's authentication status? Half the app needs that — Provider. When you're tempted to pass a callback three widgets down so a child can tell a grandparent "the user logged out," you've reached Provider territory. Lift that state up and out.
The whole pattern: extend ChangeNotifier, wrap your widget tree in ChangeNotifierProvider (or MultiProvider for several models), and any descendant widget can watch for rebuilds or read for one-shot calls. No constructor chains, no callback pyramids.
Architecture — what real apps look like
Think of it like building a house. Models are the blueprints -- they describe what a room looks like. Services are the plumbing and electrical -- they move things around behind the walls. Providers are the thermostat -- they track the current state and tell the house when something changes. Widgets are the furniture -- individual pieces you can move between rooms. Screens are the rooms themselves -- complete spaces assembled from furniture. You would not stuff the blueprints, the pipes, the thermostat, the couch, and the room layout into one giant pile. Same principle.
Beyond the widget tree, real Flutter apps separate concerns into layers — pure Dart models, services that handle data, providers that hold app state, custom widgets, and screens that compose them. This is what the capstone module ties together, and it's the difference between a toy app and code you'd be proud to show in an interview.
Where to next
This is it. The final boss. Everything you have learned over the past eighteen modules comes together right here: Dart classes, widgets, state management, navigation, theming, testing -- all of it. You are going to build a complete Task Manager application from scratch, and more importantly, you are going to build it the right way. Not everything crammed into one file. Not spaghetti code that works but makes you cringe when you look at it a week later. A properly structured app with clear layers, clean separation of concerns, and code you would be proud to show in a job interview.
The arc of the course is right there: three modules of Dart, then widgets and layout, then interactivity with setState, then navigation and theming, then app-wide state, then I/O and animations, then testing, and finally architecture in the capstone. If you read this overview first, every module from here on adds detail to a structure you already understand. Don't worry if every detail isn't crisp yet — by the end of week one you'll build the counter app from memory, and the rest of the course is pattern-matching against the map you just toured.
Now open Module 00 and let's get the tools installed.