Resources
Where to go after these notes, and what to study to move from being able to build screens to being able to own an application.
Contents
- Official documentation
- Dart
- Reading the framework source
- Sample applications
- Video
- Community writing
- Packages worth studying
- Keeping up with releases
- From mid-level to senior
Official documentation
| Resource | Use |
|---|---|
| docs.flutter.dev | The manual. Start here for anything you have not done before |
| api.flutter.dev | API reference. The class docs are unusually good — read them, not just the signatures |
| Cookbook | Short, task-shaped recipes |
| Codelabs | Guided, longer exercises |
| pub.dev | Packages, with scores, platform support, and — most usefully — source links |
When evaluating a package on pub.dev, look past the score at the last publish date, the open issue count, the platform support table, and the example directory. An unmaintained package with a high score is still unmaintained.
Dart
- dart.dev/language — the language tour.
- Effective Dart — style, documentation, usage, and design guidelines. The design section is the one most people never read and most benefit from.
- dart.dev/libraries — the core library tour,
including
dart:asyncanddart:isolate.
Reading the framework source
Flutter's framework is written in Dart and is unusually readable. When behaviour surprises you, the answer is generally one jump-to-definition away. High-value files:
| File | What it teaches |
|---|---|
widgets/framework.dart | Widget, Element, State, BuildOwner — the core of Rendering pipeline |
rendering/object.dart | RenderObject, layout and paint protocols, PipelineOwner |
rendering/box.dart | BoxConstraints and the box layout model |
widgets/scroll_position.dart and the sliver files | How scrolling actually works |
animation/animation_controller.dart | Tickers, simulations, and the animation contract |
material/ any widget you use daily | How a real composite widget is assembled |
A productive habit: pick one widget you use constantly, read its source top to bottom, and note what it does that you did not know.
Sample applications
- flutter/samples — official samples, including architecture examples and platform integration.
- flutter/flutter — the framework itself;
its
examples/directory and its tests are a reference for idiomatic code. - Reading a well-structured open-source app end to end teaches more about architecture than any article. Look for one with tests and a stated architecture, not one with the most stars.
Video
- The Flutter YouTube channel — Widget of the Week for breadth, Decoding Flutter for the reasoning behind APIs.
- Conference talks from Google I/O and FlutterCon. Engine and rendering talks age well; state-management talks age quickly.
Community writing
Quality varies wildly, and Flutter tutorials rot faster than most because the API surface moves. Two filters before trusting an article: check its date, and check whether its code compiles against the version you use.
Consistently reliable sources include Code with Andrea, the Very Good Ventures
blog, and the official Flutter and Dart posts on Medium. For questions, the
Flutter Discord and r/FlutterDev are more current than Stack Overflow, where
many highly ranked Flutter answers predate null safety.
Packages worth studying
Not just using — reading:
| Package | Worth reading for |
|---|---|
provider | A small, complete abstraction over InheritedWidget |
bloc | Clean separation of events, states, and side effects; excellent docs |
riverpod | Provider composition and lifetime management without the tree |
go_router | A real Navigator 2.0 implementation you can follow |
dio | Interceptor and adapter design |
freezed | What code generation can do for immutability and unions |
Keeping up with releases
- Release notes for what changed.
- Breaking changes — read this before every upgrade, not after something breaks.
flutter upgradeon a branch, then runflutter analyzeand the full test suite before merging.- Deprecations are announced well ahead of removal. Clearing them as they appear is far cheaper than a migration sprint later.
This is also the answer to any version-specific claim in these notes: check it against the release notes for the version you actually ship.
From mid-level to senior
The gap is rarely more widget knowledge. It is these:
- Understand the frame. Being able to say why a frame was slow, and whether it was the UI or raster thread, from the evidence — see DevTools and performance.
- Design for change. Layer boundaries that let you replace the backend, the state management, or a renderer without touching every file. See Project structure.
- Test what matters. Recognising which tests will still be valuable in a year — see Testing.
- Own the release. Signing, flavours, symbols, staged rollout, crash triage. See Build and release.
- Read the source rather than searching for a workaround.
- Say no to complexity. Choosing the smaller solution, and being able to explain the trade you made.
- Write it down. The engineer whose decisions are documented is the one whose decisions survive.
A practical exercise that covers most of the above: take an existing screen in your app, profile it, fix the top two problems, write tests that lock in the behaviour, and document what you changed and why.
Back to the plan.