Flutter Development Patterns
Tech-stack skill for Flutter mobile application development. Covers clean architecture, coding standards, state management, and code review checks.
Supporting Files
Architecture Overview
Flutter apps following this workflow use clean architecture with four layers:
| Layer | Directory | Responsibility |
|---|
| UI | lib/screens/, lib/components/ | Screens and reusable widgets |
| Business Logic | lib/services/, lib/providers/ | Services and state management |
| Data | lib/data/models/ | Data structures and repositories |
| Utilities | lib/utils/, lib/theme/ | Helpers, theming, logging |
State Management
- Primary: Riverpod (
flutter_riverpod) for reactive state
- UI State: Freezed for immutable state classes
- Legacy: Provider (maintain but do not add new usage)
- Hooks: Flutter Hooks for widget-level state
Key Principles
- Reuse before create -- check existing components before building new ones
- Flat widget trees -- break deep nesting into smaller components
- Const constructors -- reduce unnecessary rebuilds
- Type safety -- always declare types, avoid
dynamic
- Short functions -- under 20 lines, single purpose
- Early returns -- avoid deep nesting with guard clauses
- No magic numbers -- define constants
- Compile after every change -- ensure each iteration builds
Navigation Patterns
- Main screens: Drawer + bottom navigation bar
- Detail screens: Back button + bottom navigation bar
- Screen wrapper: Use a BaseScreen widget for consistent layout
- Route definitions: Centralized in a router file using
generateRoute()
Common Tasks
| Task | Approach |
|---|
| Add a screen | Wrap in BaseScreen, register route, add to navigation |
| Add a service | Create in services directory, follow singleton pattern, use Logger |
| Add localization | Edit ARB files, run flutter gen-l10n, access via AppLocalizations.of(context)! |
| Add a form | Use shared form components, 12px field spacing, consistent validation |
| Add a provider | Use Riverpod, prefer autoDispose, use select() for granular rebuilds |
Before Committing
- Run
flutter analyze (fail on errors)
- Verify code compiles
- Update relevant documentation
- Follow naming conventions (PascalCase classes, camelCase methods, snake_case files)
