Best Practices

This final lesson doesn't introduce anything new — it pulls together the habits, from every earlier lesson in this track, that separate Flutter code that merely "works" from an app that stays fast, maintainable, and pleasant to build on a year from now. Treat it as a checklist to revisit on real projects, not just a one-time read.

1. Prefer StatelessWidget and const Wherever Output Never Changes

As covered in Widgets: Stateless vs Stateful and Performance Tips, a widget whose output depends only on its constructor parameters should be a StatelessWidget with a const constructor — letting Flutter skip rebuilding it entirely when nothing about it has changed.

class SectionHeader extends StatelessWidget {
  final String title;
  const SectionHeader({super.key, required this.title});
  @override
  Widget build(BuildContext context) => Text(title, style: const TextStyle(fontSize: 20));
}

• Default to StatelessWidget; reach for StatefulWidget only when a widget genuinely owns mutable state.
• Add const to every constructor call where the values are all compile-time constants.

2. Keep Widget Classes Small and Focused

A single giant build() method, deeply nested with dozens of widgets, is hard to read and hard to change safely. Extract logical pieces into their own small, private widget classes instead of one sprawling tree — a habit that's easy to skip early on and genuinely painful to unwind later.

// Instead of one 200-line build() method, extract pieces:
Widget build(BuildContext context) {
  return Scaffold(
    appBar: _ProfileAppBar(),
    body: _ProfileBody(user: user),
  );
}

• A build() method that reads like a short outline is a good sign; one that scrolls for pages is a warning sign.
• Small widget classes are also easier to give individual widget tests, covered in Testing.

3. Choose State Management to Match Your App's Size

As covered across State Management: setState, State Management: Provider, and State Management: Riverpod & Bloc, there isn't one universally "correct" state management approach — the right one depends on scale.

• setState — simple, local, single-widget state. Don't reach for more than this until you actually need to.
• Provider / Riverpod — state that needs to be shared across several widgets or screens.
• Bloc — large, testable, team-scale apps where a strict, predictable structure pays off.

4. Always Validate Forms Before Submitting

As covered in Forms & Input Handling, never submit form data without validating it first, and always give the user a clear, specific inline error rather than a generic failure.

TextFormField(
  validator: (value) {
    if (value == null || value.isEmpty) {
      return 'Email is required';
    }
    return null;
  },
)

• Validate on submit, and ideally as the user types for immediate feedback.
• Error text should say what's wrong and how to fix it, not just "Invalid input."

5. Use ListView.builder for Any List That Could Grow Large

As covered in Lists & ListView, any list whose length isn't a small, fixed number should use lazy building rather than constructing every item up front.

• Default to ListView.builder unless you're certain the list will always be tiny.
• Revisit any plain ListView the moment its content becomes user-generated or unbounded.

6. Handle Loading, Error, and Empty States Explicitly

As covered with FutureBuilder in HTTP Requests & APIs, never assume the happy path — every async data fetch has at least three real outcomes, and each deserves its own UI.

FutureBuilder<List<Post>>(
  future: fetchPosts(),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) return const CircularProgressIndicator();
    if (snapshot.hasError) return Text('Something went wrong');
    if (!snapshot.hasData || snapshot.data!.isEmpty) return const Text('No posts yet');
    return PostList(posts: snapshot.data!);
  },
)

• Loading, error, and empty are each a distinct, deliberate UI state — never left to default to a blank screen.

7. Write at Least Widget Tests for Your Critical Screens

As covered in Testing, you don't need full coverage everywhere to get real value — but the screens that would genuinely hurt if they silently broke (checkout, login, the core flow of your app) deserve at least a widget test each.

• Start with the flows that would be a real incident if broken, not exhaustive coverage everywhere.
• A widget test that simulates a real tap and checks the result is a strong, fast safety net.

8. Back Up Your Android Signing Keystore Securely

As emphasized in Building & Releasing, losing your keystore means permanently losing the ability to update your published app under its existing Play Store listing.

• Store the keystore file and its passwords in at least two independent, durable places.
• Never commit a keystore or its passwords to a public repository.

9. Profile Before Optimizing

As covered in Performance Tips, use DevTools' Performance view to find where frame time is actually going before changing any code in the name of "performance."

• A change made without measuring first is a guess — sometimes it even makes things worse.

10. Lean on pub.dev, But Check What You Depend On

Flutter's package ecosystem, first introduced in Packages & pubspec.yaml, already solves most common problems — cameras, GPS, HTTP, local storage, image caching. Reinventing these yourself rarely pays off. Before adding a package, though, glance at its pub.dev score, its last publish date, and its open issues — a package that hasn't been touched in years, or has no maintainer response to open bugs, is a real risk to depend on long-term.

• Prefer an existing, well-maintained package over hand-rolled equivalents.
• Check maintenance activity and popularity before adding a new dependency, not just whether it does the job today.