Flutter Architecture

Flutter Architecture is a community skill for structuring Flutter applications with scalable architecture patterns, covering state management, dependency injection, repository patterns, testing strategies, and modular project organization.

What Is This?

Overview

Flutter Architecture provides patterns for organizing Flutter projects that scale beyond small applications. It covers state management approaches using Riverpod, Bloc, and Provider for separating UI from business logic, repository pattern for abstracting data sources behind consistent interfaces, dependency injection with service locators and provider-based injection for testable components, feature-based project structure that groups related screens, models, and logic by domain, and testing strategies with unit tests for logic, widget tests for UI, and integration tests for flows. The skill enables Flutter developers to build applications with clear separation of concerns that remain maintainable as the codebase grows.

Who Should Use This

This skill serves Flutter developers structuring applications for long-term maintainability, teams establishing architectural patterns for shared codebases, and engineers implementing testable business logic separated from UI concerns.

Why Use It?

Problems It Solves

Mixing business logic with widget code creates tightly coupled components that are difficult to test and reuse. Direct database or API calls in widgets make switching data sources expensive. Flat project structures become unnavigable as feature count grows. Untestable architectures lead to regressions that are caught late in development.

Core Highlights

State management layer separates reactive UI updates from business rules. Repository interfaces abstract data sources for flexible backend swapping. Dependency injection enables mock substitution in tests. Feature modules encapsulate related code for independent development.

How to Use It?

Basic Usage

import 'package:flutter_riverpod/
  flutter_riverpod.dart';

// Domain model
class Task {
  final String id;
  final String title;
  final bool completed;

  const Task({
    required this.id,
    required this.title,
    this.completed = false,
  });

  Task copyWith({bool? completed}) =>
    Task(
      id: id,
      title: title,
      completed:
        completed ?? this.completed,
    );
}

// Repository interface
abstract class TaskRepository {
  Future<List<Task>> getTasks();
  Future<void> addTask(String title);
  Future<void> toggleTask(
    String id);
}

// Provider
final taskRepoProvider =
  Provider<TaskRepository>(
    (ref) => ApiTaskRepository());

final tasksProvider =
  FutureProvider<List<Task>>(
    (ref) => ref.read(
      taskRepoProvider).getTasks());

Real-World Examples

import 'package:flutter_riverpod/
  flutter_riverpod.dart';

// Notifier with business logic
class TaskNotifier
    extends AsyncNotifier<List<Task>> {
  @override
  Future<List<Task>> build() =>
    ref.read(taskRepoProvider)
      .getTasks();

  Future<void> add(
      String title) async {
    final repo = ref.read(
      taskRepoProvider);
    await repo.addTask(title);
    ref.invalidateSelf();
  }

  Future<void> toggle(
      String id) async {
    final repo = ref.read(
      taskRepoProvider);
    await repo.toggleTask(id);
    state = AsyncData(
      state.value!.map((t) =>
        t.id == id
          ? t.copyWith(
              completed: !t.completed)
          : t
      ).toList());
  }
}

final taskNotifierProvider =
  AsyncNotifierProvider<
    TaskNotifier, List<Task>>(
      TaskNotifier.new);

// API implementation
class ApiTaskRepository
    implements TaskRepository {
  @override
  Future<List<Task>> getTasks() async {
    final response = await dio.get(
      '/api/tasks');
    return (response.data as List)
      .map((j) => Task(
        id: j['id'],
        title: j['title'],
        completed: j['completed'],
      )).toList();
  }

  @override
  Future<void> addTask(
      String title) async {
    await dio.post('/api/tasks',
      data: {'title': title});
  }

  @override
  Future<void> toggleTask(
      String id) async {
    await dio.patch(
      '/api/tasks/$id/toggle');
  }
}

Advanced Tips

Use feature-based directory structure where each feature folder contains its own models, repository, state, and widgets. Create mock implementations of repository interfaces for widget and integration testing without network dependencies. Use Riverpod overrides in tests to inject mock providers.

When to Use It?

Use Cases

Build a task management app with offline support using repository pattern to switch between local and remote data sources. Create a multi-feature application with independent modules for auth, settings, and content. Implement a testable architecture where business logic is verified with unit tests independent of UI.

Related Topics

Flutter state management, clean architecture, dependency injection, repository pattern, and software testing.

Important Notes

Requirements

Flutter SDK with a state management package such as Riverpod or Bloc installed. Dart with null safety enabled for type-safe code. Testing framework with flutter_test for widget and unit tests.

Usage Recommendations

Do: define repository interfaces before implementations to enable mock injection during testing. Keep widget code focused on rendering and delegate logic to notifiers or blocs. Use AsyncNotifier or similar async state holders for data loading.

Don't: access repositories directly from widgets without going through a state management layer. Create circular dependencies between feature modules that prevent independent development. Skip writing tests for business logic just because the UI appears to work correctly.

Limitations

Architectural patterns add boilerplate code that may feel excessive for small applications. State management libraries have different learning curves and API styles. Over-engineering the architecture for simple features increases development time without proportional benefit.