A humble approach to Flutter app architecture
summary
Argues that app navigation complexity comes from centralizing everything and shows a concrete local‑first alternative: a stateful flow widget that uses a private enum steps list, per‑page callbacks for onNext/onBack/onCancel, and a small custom transition stack widget implemented in a few hundred lines to restore animations. Claims this reduces merge conflicts, hides screens from global APIs, keeps state local across pages, and that the demo works end‑to‑end including back, cancel, and animated transitions.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:03Centralization inevitability
- 2:05Centralization benefits
- 3:52Centralization pain points
- 5:39Centralized navigation limits
- 7:03Local-first navigation
- 9:34Flutter Navigator struggles
- 10:37Flow pattern for navigation
- 12:44Handling back/cancel in flows
- 14:53Transitions without global Navigator
- 16:56Summary
- 17:59Closing
related talks
22mArchitecture First: Foundations for Long Term Success
44mState Management in Flutter
45mArchitectural Thinking on Flutter State Management
29mBasic Strategies for State Propagation and Access Control in Flutter Widget Trees
51mFlutter: How Widgets Work
46mHow to Cook Flutter Properly
34mBuild reactive mobile apps with Flutter
40mHow to manage application states using inherited widgets