State Management stellt eine zentrale Herausforderung in der Flutter-Entwicklung dar. Riverpod und BLoC dominieren das Ökosystem und bieten jeweils eine eigenständige Philosophie. Dieser Leitfaden vergleicht beide Lösungen anhand konkreter Implementierungen, um die Auswahl auf Basis der Projektanforderungen zu erleichtern.

Voraussetzungen

Dieser Leitfaden setzt Vertrautheit mit Flutter und den Grundlagen des State Managements voraus. Die Beispiele verwenden Riverpod 3.x und flutter_bloc 9.x, die aktuell stabilen Versionen 2026.

Kernphilosophien beider Ansätze

Riverpod und BLoC lösen dasselbe Problem mit gegensätzlichen Paradigmen. Das Verständnis dieser konzeptionellen Unterschiede ermöglicht die Wahl des richtigen Werkzeugs für jeden Kontext.

Riverpod verfolgt einen deklarativen und reaktiven Ansatz. Provider definieren Datenquellen, die Widgets beobachten. Das Framework verwaltet automatisch Lebenszyklus, Caching und Abhängigkeiten zwischen Providern. Version 3.0 brachte wesentliche Verbesserungen: automatische Wiederholung für fehlgeschlagene Provider, Pause/Resume von Listenern basierend auf Widget-Sichtbarkeit und experimentelle Offline-Persistenz.

BLoC (Business Logic Component) erzwingt eine strikte ereignisorientierte Architektur. Komponenten emittieren Events, der Bloc verarbeitet sie und produziert neue States. Diese explizite Trennung erleichtert die Nachverfolgung des Datenflusses. Version 9.x führte EmittableStateStreamableSource für verbesserte Test-Flexibilität ein.

riverpod_philosophy.dartdart

// Riverpod 3.x: Notifier replaces StateNotifier as the standard pattern
@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;
  
  void increment() => state++;
}

// Usage in a widget
class CounterWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Reactive read: automatic rebuild if value changes
    final count = ref.watch(counterProvider);
    return Text('$count');
  }
}

bloc_philosophy.dartdart

// BLoC 9.x: explicit events/states separation
sealed class CounterEvent {}
final class IncrementPressed extends CounterEvent {}

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    // Each event has its dedicated handler
    on<IncrementPressed>((event, emit) => emit(state + 1));
  }
}

// Usage in a widget
class CounterWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocBuilder<CounterBloc, int>(
      builder: (context, count) => Text('$count'),
    );
  }
}

Die Wahl zwischen diesen Ansätzen hängt von den Vorlieben des Teams und den Projektbeschränkungen ab. Einen Überblick über State Management Optionen einschließlich GetX bietet der vollständige Flutter State Management Vergleich für 2026.

Initiale Konfiguration

Die initiale Konfiguration zeigt ergonomische Unterschiede zwischen beiden Lösungen. Riverpod priorisiert Einfachheit, BLoC bietet mehr Struktur.

Installation von Riverpod

Riverpod benötigt ein einziges Paket und einen Wrapper an der Anwendungswurzel. Codegenerierung mit riverpod_generator ist der empfohlene Ansatz in Version 3.x.

main.dartdart

// Riverpod configuration: single wrapper at root
import 'package:flutter_riverpod/flutter_riverpod.dart';

void main() {
  runApp(
    // ProviderScope wraps the entire application
    const ProviderScope(
      child: MyApp(),
    ),
  );
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: HomeScreen(),
    );
  }
}

Installation von BLoC

BLoC benötigt mehrere Pakete und eine umfangreichere Konfiguration mit BlocProvidern für jeden verwendeten Bloc.

main.dartdart

// BLoC configuration: explicit providers for each Bloc
import 'package:flutter_bloc/flutter_bloc.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    // MultiBlocProvider for multiple Blocs
    return MultiBlocProvider(
      providers: [
        BlocProvider(create: (_) => AuthBloc()),
        BlocProvider(create: (_) => ThemeBloc()),
      ],
      child: MaterialApp(
        home: HomeScreen(),
      ),
    );
  }
}

Die BLoC-Konfiguration erfordert mehr Initialcode, macht Abhängigkeiten aber von Anfang an explizit.

Einfaches State Management: Counter und Toggles

Einfache Fälle illustrieren die alltägliche Ergonomie jeder Lösung. Riverpod glänzt durch Prägnanz, BLoC behält seine ereignisorientierte Struktur bei.

Counter mit Riverpod (Notifier Pattern)

Riverpod 3.x depreciert StateProvider und StateNotifierProvider zugunsten der einheitlichen Notifier API. Das neue Pattern ist übersichtlicher und funktioniert nahtlos mit Codegenerierung.

counter_riverpod.dartdart

// Notifier pattern: the standard in Riverpod 3.x
@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;

  void increment() => state++;
  void decrement() => state--;
  void reset() => state = 0;
}

class CounterScreen extends ConsumerWidget {
  const CounterScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // watch for reactive value
    final count = ref.watch(counterProvider);

    return Scaffold(
      body: Center(child: Text('Count: $count')),
      floatingActionButton: FloatingActionButton(
        // read for actions (no rebuild)
        onPressed: () => ref.read(counterProvider.notifier).increment(),
        child: const Icon(Icons.add),
      ),
    );
  }
}

Counter mit BLoC

counter_bloc.dartdart

// Typed events for each possible action
sealed class CounterEvent {}
final class CounterIncremented extends CounterEvent {}
final class CounterDecremented extends CounterEvent {}
final class CounterReset extends CounterEvent {}

// Bloc with handlers for each event
class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    on<CounterIncremented>((event, emit) => emit(state + 1));
    on<CounterDecremented>((event, emit) => emit(state - 1));
    on<CounterReset>((event, emit) => emit(0));
  }
}

class CounterScreen extends StatelessWidget {
  const CounterScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: BlocBuilder<CounterBloc, int>(
          builder: (context, count) => Text('Count: $count'),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        // Event dispatch to modify state
        onPressed: () => context.read<CounterBloc>().add(CounterIncremented()),
        child: const Icon(Icons.add),
      ),
    );
  }
}

Für einfache Fälle reduziert Riverpod den Boilerplate erheblich. BLoC wird relevant, sobald die Logik komplexer wird oder Event-Nachverfolgbarkeit wichtig ist.

Legacy Provider in Riverpod 3.x

StateProvider und StateNotifierProvider funktionieren weiterhin, erfordern aber den Import aus flutter_riverpod/legacy.dart. Für neuen Code sollte Notifier oder AsyncNotifier verwendet werden.

Asynchrones State Management: API-Aufrufe

Asynchrone Operationen offenbaren die Stärke jeder Lösung. Die Verwaltung von Loading-, Error- und Data-States stellt eine wesentliche Herausforderung dar. Riverpod 3.x führt automatische Wiederholung mit exponentiellem Backoff für fehlgeschlagene Provider ein.

Asynchrone Daten mit Riverpod

async_riverpod.dartdart

// AsyncNotifier: automatic loading/error/data management with retry
@riverpod
class Users extends _$Users {
  @override
  Future<List<User>> build() async {
    // autoDispose releases resources when provider is no longer used
    // Automatic retry on failure (exponential backoff: 200ms to 6.4s)
    final repository = ref.watch(userRepositoryProvider);
    return repository.fetchUsers();
  }

  Future<void> refresh() async {
    state = const AsyncLoading();
    state = await AsyncValue.guard(() => build());
  }
}

class UsersScreen extends ConsumerWidget {
  const UsersScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final usersAsync = ref.watch(usersProvider);

    // when handles all 3 possible states
    return usersAsync.when(
      loading: () => const Center(child: CircularProgressIndicator()),
      error: (error, stack) => Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text('Error: $error'),
            ElevatedButton(
              // invalidate forces reload
              onPressed: () => ref.invalidate(usersProvider),
              child: const Text('Retry'),
            ),
          ],
        ),
      ),
      data: (users) => ListView.builder(
        itemCount: users.length,
        itemBuilder: (context, index) => UserTile(user: users[index]),
      ),
    );
  }
}

Asynchrone Daten mit BLoC

async_bloc.dartdart

// Explicit states for each loading phase
sealed class UsersState {}
final class UsersInitial extends UsersState {}
final class UsersLoading extends UsersState {}
final class UsersLoaded extends UsersState {
  final List<User> users;
  UsersLoaded(this.users);
}
final class UsersError extends UsersState {
  final String message;
  UsersError(this.message);
}

// Events to trigger actions
sealed class UsersEvent {}
final class UsersFetchRequested extends UsersEvent {}
final class UsersRefreshRequested extends UsersEvent {}

class UsersBloc extends Bloc<UsersEvent, UsersState> {
  final UserRepository _repository;

  UsersBloc(this._repository) : super(UsersInitial()) {
    on<UsersFetchRequested>(_onFetchRequested);
    on<UsersRefreshRequested>(_onRefreshRequested);
  }

  Future<void> _onFetchRequested(
    UsersFetchRequested event,
    Emitter<UsersState> emit,
  ) async {
    emit(UsersLoading());
    try {
      final users = await _repository.fetchUsers();
      emit(UsersLoaded(users));
    } catch (e) {
      emit(UsersError(e.toString()));
    }
  }

  Future<void> _onRefreshRequested(
    UsersRefreshRequested event,
    Emitter<UsersState> emit,
  ) async {
    // Keep current state during refresh
    final currentState = state;
    try {
      final users = await _repository.fetchUsers();
      emit(UsersLoaded(users));
    } catch (e) {
      // Restore previous state on error
      if (currentState is UsersLoaded) {
        emit(currentState);
      } else {
        emit(UsersError(e.toString()));
      }
    }
  }
}

users_screen_bloc.dartdart

// Widget with pattern matching on states
class UsersScreen extends StatelessWidget {
  const UsersScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocBuilder<UsersBloc, UsersState>(
      builder: (context, state) {
        return switch (state) {
          UsersInitial() => Center(
              child: ElevatedButton(
                onPressed: () => context.read<UsersBloc>().add(UsersFetchRequested()),
                child: const Text('Load'),
              ),
            ),
          UsersLoading() => const Center(child: CircularProgressIndicator()),
          UsersError(:final message) => Center(
              child: Column(
                mainAxisAlignment: MainAxisAlignment.center,
                children: [
                  Text('Error: $message'),
                  ElevatedButton(
                    onPressed: () => context
                        .read<UsersBloc>()
                        .add(UsersFetchRequested()),
                    child: const Text('Retry'),
                  ),
                ],
              ),
            ),
          UsersLoaded(:final users) => ListView.builder(
              itemCount: users.length,
              itemBuilder: (context, index) => UserTile(user: users[index]),
            ),
        };
      },
    );
  }
}

BLoC bietet granulare Kontrolle über jeden State-Übergang. Riverpod automatisiert mehr über AsyncValue und integrierte Retry-Logik.

Bereit für deine Flutter-Interviews?

Übe mit unseren interaktiven Simulatoren, Flashcards und technischen Tests.

Flutter erkunden

State-Abhängigkeiten: Komposition und Injektion

Reale Anwendungen beinhalten voneinander abhängige States. Die Verwaltung dieser Abhängigkeiten unterscheidet beide Ansätze deutlich.

Komposition mit Riverpod

composition_riverpod.dartdart

// Base provider: configuration
@riverpod
ApiClient apiClient(Ref ref) {
  final baseUrl = ref.watch(environmentProvider).apiUrl;
  return ApiClient(baseUrl: baseUrl);
}

// Dependent provider: repository
@riverpod
ProductRepository productRepository(Ref ref) {
  // Automatic client injection
  final client = ref.watch(apiClientProvider);
  return ProductRepository(client);
}

// Provider with parameter: product by ID
@riverpod
Future<Product> product(Ref ref, String productId) async {
  final repository = ref.watch(productRepositoryProvider);
  return repository.getProduct(productId);
}

// Derived provider: filtered products
@riverpod
List<Product> filteredProducts(Ref ref) {
  final products = ref.watch(productsProvider).valueOrNull ?? [];
  final filter = ref.watch(productFilterProvider);

  return products.where((p) => p.category == filter.category).toList();
}

// Usage with parameter
class ProductDetailScreen extends ConsumerWidget {
  final String productId;

  const ProductDetailScreen({super.key, required this.productId});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // family allows passing parameters
    final productAsync = ref.watch(productProvider(productId));

    return productAsync.when(
      loading: () => const ProductSkeleton(),
      error: (e, _) => ErrorWidget(error: e),
      data: (product) => ProductDetails(product: product),
    );
  }
}

Komposition mit BLoC

composition_bloc.dartdart

// Repository injected into the Bloc
class ProductBloc extends Bloc<ProductEvent, ProductState> {
  final ProductRepository _repository;
  final CartBloc _cartBloc;
  late final StreamSubscription _cartSubscription;

  ProductBloc({
    required ProductRepository repository,
    required CartBloc cartBloc,
  })  : _repository = repository,
        _cartBloc = cartBloc,
        super(ProductInitial()) {
    on<ProductFetchRequested>(_onFetchRequested);
    on<ProductAddedToCart>(_onAddedToCart);

    // Listen to cart changes
    _cartSubscription = _cartBloc.stream.listen((cartState) {
      // React to cart changes
      if (cartState is CartUpdated) {
        add(ProductCartSyncRequested(cartState.items));
      }
    });
  }

  Future<void> _onFetchRequested(
    ProductFetchRequested event,
    Emitter<ProductState> emit,
  ) async {
    emit(ProductLoading());
    try {
      final product = await _repository.getProduct(event.productId);
      // Check if product is in cart
      final isInCart = _cartBloc.state.contains(product.id);
      emit(ProductLoaded(product, isInCart: isInCart));
    } catch (e) {
      emit(ProductError(e.toString()));
    }
  }

  @override
  Future<void> close() {
    _cartSubscription.cancel();
    return super.close();
  }
}

// Configuration with dependency injection
class ProductsPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocProvider(
      create: (context) => ProductBloc(
        repository: context.read<ProductRepository>(),
        cartBloc: context.read<CartBloc>(),
      )..add(ProductFetchRequested()),
      child: const ProductsView(),
    );
  }
}

Riverpod verwaltet Abhängigkeiten deklarativ. BLoC erfordert manuelle Verwaltung der Subscriptions zwischen Blocs.

Testbarkeit und Mocking

Testen stellt ein entscheidendes Kriterium für professionelle Projekte dar. Beide Lösungen glänzen in diesem Bereich mit unterschiedlichen Ansätzen. Testfähigkeiten werden häufig in Flutter-Interviews geprüft.

Tests mit Riverpod

test_riverpod.dartdart

import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';

class MockUserRepository extends Mock implements UserRepository {}

void main() {
  group('UserProvider Tests', () {
    late MockUserRepository mockRepository;

    setUp(() {
      mockRepository = MockUserRepository();
    });

    test('returns users from repository', () async {
      // Arrange
      final expectedUsers = [User(id: '1', name: 'Test')];
      when(() => mockRepository.fetchUsers())
          .thenAnswer((_) async => expectedUsers);

      // ProviderContainer.test auto-disposes after test
      final container = ProviderContainer.test(
        overrides: [
          userRepositoryProvider.overrideWithValue(mockRepository),
        ],
      );

      // Act
      final users = await container.read(usersProvider.future);

      // Assert
      expect(users, expectedUsers);
      verify(() => mockRepository.fetchUsers()).called(1);
    });

    test('handles repository errors', () async {
      when(() => mockRepository.fetchUsers())
          .thenThrow(Exception('Network error'));

      final container = ProviderContainer.test(
        overrides: [
          userRepositoryProvider.overrideWithValue(mockRepository),
        ],
      );

      expect(
        () => container.read(usersProvider.future),
        throwsException,
      );
    });
  });
}

Tests mit BLoC

test_bloc.dartdart

import 'package:bloc_test/bloc_test.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';

class MockUserRepository extends Mock implements UserRepository {}

void main() {
  group('UsersBloc Tests', () {
    late MockUserRepository mockRepository;

    setUp(() {
      mockRepository = MockUserRepository();
    });

    // blocTest simplifies state sequence testing
    blocTest<UsersBloc, UsersState>(
      'emits [Loading, Loaded] when fetch succeeds',
      build: () {
        when(() => mockRepository.fetchUsers())
            .thenAnswer((_) async => [User(id: '1', name: 'Test')]);
        return UsersBloc(mockRepository);
      },
      act: (bloc) => bloc.add(UsersFetchRequested()),
      expect: () => [
        isA<UsersLoading>(),
        isA<UsersLoaded>().having(
          (s) => s.users.length,
          'users count',
          1,
        ),
      ],
    );

    blocTest<UsersBloc, UsersState>(
      'emits [Loading, Error] when fetch fails',
      build: () {
        when(() => mockRepository.fetchUsers())
            .thenThrow(Exception('Network error'));
        return UsersBloc(mockRepository);
      },
      act: (bloc) => bloc.add(UsersFetchRequested()),
      expect: () => [
        isA<UsersLoading>(),
        isA<UsersError>(),
      ],
    );
  });
}

Das Paket bloc_test bietet eine dedizierte Syntax zum Testen von State-Sequenzen. Riverpod 3.x fügt ProviderContainer.test() für automatisches Aufräumen und NotifierProvider.overrideWithBuild() zum Mocken nur der build-Methode hinzu.

Testabdeckung

Nur die Standardfälle zu testen reicht nicht aus. Tests müssen Netzwerkfehler, Timeouts, Edge-Case-States und unerwartete State-Übergänge abdecken. Für umfassende Testpraktiken siehe den Flutter Testing Guide.

Leistung und Rebuild-Optimierung

Die Leistung wirkt sich direkt auf die Nutzererfahrung aus. Beide Lösungen bieten unterschiedliche Optimierungsmechanismen.

Optimierung mit Riverpod

perf_riverpod.dartdart

// select to rebuild only if targeted value changes
class UserNameWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Rebuilds only if user.name changes
    final name = ref.watch(userProvider.select((user) => user.name));
    return Text(name);
  }
}

// Provider with automatic caching
@riverpod
ExpensiveResult expensiveComputation(Ref ref) {
  final input = ref.watch(inputProvider);
  // Computation automatically cached
  return performExpensiveComputation(input);
}

// keepAlive with timer for temporary caching
@riverpod
Future<List<Product>> searchResults(Ref ref, String query) async {
  // Temporary keepAlive during typing
  final link = ref.keepAlive();

  // Timer to release after inactivity
  final timer = Timer(const Duration(seconds: 30), link.close);
  ref.onDispose(timer.cancel);

  return searchProducts(query);
}

Optimierung mit BLoC

perf_bloc.dartdart

// buildWhen limits rebuilds conditionally
class UserNameWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocBuilder<UserBloc, UserState>(
      // Rebuilds only if name changes
      buildWhen: (previous, current) {
        if (previous is UserLoaded && current is UserLoaded) {
          return previous.user.name != current.user.name;
        }
        return true;
      },
      builder: (context, state) {
        if (state is UserLoaded) {
          return Text(state.user.name);
        }
        return const SizedBox.shrink();
      },
    );
  }
}

// BlocSelector to extract a specific value
class UserAvatarWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocSelector<UserBloc, UserState, String?>(
      // Select only the avatar URL
      selector: (state) => state is UserLoaded ? state.user.avatarUrl : null,
      builder: (context, avatarUrl) {
        if (avatarUrl == null) return const DefaultAvatar();
        return NetworkImage(avatarUrl);
      },
    );
  }
}

Beide Lösungen bieten granulare Optimierungen. Riverpod mit select, BLoC mit buildWhen und BlocSelector. Für fortgeschrittene Performance-Techniken siehe den Flutter Performance Optimization Guide.

Praktischer Anwendungsfall: Vollständige Authentifizierung

Ein Authentifizierungssystem veranschaulicht reale Patterns für jede Lösung. Dieser Fall kombiniert persistenten State, API-Aufrufe und Navigation.

Authentifizierung mit Riverpod

auth_riverpod.dartdart

// Authentication state with sealed class
sealed class AuthState {
  const AuthState();
}
final class AuthInitial extends AuthState {
  const AuthInitial();
}
final class AuthLoading extends AuthState {
  const AuthLoading();
}
final class AuthAuthenticated extends AuthState {
  final User user;
  const AuthAuthenticated(this.user);
}
final class AuthUnauthenticated extends AuthState {
  final String? error;
  const AuthUnauthenticated([this.error]);
}

// Notifier to manage auth state
@riverpod
class Auth extends _$Auth {
  @override
  Future<AuthState> build() async {
    final storage = ref.watch(secureStorageProvider);
    final repository = ref.watch(authRepositoryProvider);
    
    final token = await storage.getToken();
    if (token != null) {
      try {
        final user = await repository.getCurrentUser(token);
        return AuthAuthenticated(user);
      } catch (_) {
        await storage.deleteToken();
        return const AuthUnauthenticated();
      }
    }
    return const AuthUnauthenticated();
  }

  Future<void> login(String email, String password) async {
    state = const AsyncLoading();
    final repository = ref.read(authRepositoryProvider);
    final storage = ref.read(secureStorageProvider);
    
    try {
      final result = await repository.login(email, password);
      await storage.saveToken(result.token);
      state = AsyncData(AuthAuthenticated(result.user));
    } catch (e) {
      state = AsyncData(AuthUnauthenticated(e.toString()));
    }
  }

  Future<void> logout() async {
    final storage = ref.read(secureStorageProvider);
    await storage.deleteToken();
    state = const AsyncData(AuthUnauthenticated());
  }
}

// Redirect based on auth state
@riverpod
GoRouter router(Ref ref) {
  final authState = ref.watch(authProvider);

  return GoRouter(
    redirect: (context, state) {
      final isAuth = authState.valueOrNull is AuthAuthenticated;
      final isAuthRoute = state.matchedLocation.startsWith('/auth');

      if (!isAuth && !isAuthRoute) return '/auth/login';
      if (isAuth && isAuthRoute) return '/home';
      return null;
    },
    routes: [...],
  );
}

Authentifizierung mit BLoC

auth_bloc.dartdart

// Exhaustive states for authentication
sealed class AuthState {
  const AuthState();
}
final class AuthInitial extends AuthState {
  const AuthInitial();
}
final class AuthCheckInProgress extends AuthState {
  const AuthCheckInProgress();
}
final class AuthLoginInProgress extends AuthState {
  const AuthLoginInProgress();
}
final class AuthSuccess extends AuthState {
  final User user;
  const AuthSuccess(this.user);
}
final class AuthFailure extends AuthState {
  final String error;
  const AuthFailure(this.error);
}
final class AuthLoggedOut extends AuthState {
  const AuthLoggedOut();
}

// Authentication events
sealed class AuthEvent {
  const AuthEvent();
}
final class AuthCheckRequested extends AuthEvent {
  const AuthCheckRequested();
}
final class AuthLoginSubmitted extends AuthEvent {
  final String email;
  final String password;
  const AuthLoginSubmitted(this.email, this.password);
}
final class AuthLogoutRequested extends AuthEvent {
  const AuthLogoutRequested();
}

class AuthBloc extends Bloc<AuthEvent, AuthState> {
  final AuthRepository _repository;
  final SecureStorage _storage;

  AuthBloc({
    required AuthRepository repository,
    required SecureStorage storage,
  })  : _repository = repository,
        _storage = storage,
        super(const AuthInitial()) {
    on<AuthCheckRequested>(_onCheckRequested);
    on<AuthLoginSubmitted>(_onLoginSubmitted);
    on<AuthLogoutRequested>(_onLogoutRequested);
  }

  Future<void> _onCheckRequested(
    AuthCheckRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(const AuthCheckInProgress());
    final token = await _storage.getToken();

    if (token == null) {
      emit(const AuthLoggedOut());
      return;
    }

    try {
      final user = await _repository.getCurrentUser(token);
      emit(AuthSuccess(user));
    } catch (_) {
      await _storage.deleteToken();
      emit(const AuthLoggedOut());
    }
  }

  Future<void> _onLoginSubmitted(
    AuthLoginSubmitted event,
    Emitter<AuthState> emit,
  ) async {
    emit(const AuthLoginInProgress());
    try {
      final result = await _repository.login(event.email, event.password);
      await _storage.saveToken(result.token);
      emit(AuthSuccess(result.user));
    } catch (e) {
      emit(AuthFailure(e.toString()));
    }
  }

  Future<void> _onLogoutRequested(
    AuthLogoutRequested event,
    Emitter<AuthState> emit,
  ) async {
    await _storage.deleteToken();
    emit(const AuthLoggedOut());
  }
}

Beide Implementierungen behandeln dieselbe Funktionalität in unterschiedlichen Stilen. BLoC macht jeden Übergang explizit, Riverpod vereinfacht die Syntax.

Vergleichstabelle Zusammenfassung

Kriterium	Riverpod 3.x	BLoC 9.x
Lernkurve	Moderat	Steiler
Boilerplate	Minimal (mit Codegen)	Erheblich
Type Safety	Hervorragend	Hervorragend
Testbarkeit	Hervorragend	Hervorragend
Automatische Wiederholung	Integriert	Manuelle Implementierung
Offline-Persistenz	Experimentelle Unterstützung	Externe Pakete
Nachverfolgbarkeit	Über DevTools	Explizite Events/States
Komposition	Automatisch	Manuell
Codegenerierung	Empfohlen	Nicht erforderlich
Teamgröße	Flexibel	Große Teams

Empfehlungen je nach Kontext

Die Wahl zwischen Riverpod und BLoC hängt von mehreren kontextuellen Faktoren ab.

Riverpod wählen, wenn:

Das Team Prägnanz und Produktivität priorisiert
Das Projekt flexible State-Komposition erfordert
Die Entwickler aus React oder anderen reaktiven Frameworks kommen
Automatische Wiederholung und Fehlerwiederherstellung wichtig sind
Offline-Persistenz eine Anforderung darstellt

BLoC wählen, wenn:

Das Team strikte, vorhersagbare Patterns schätzt
Das Projekt vollständige Event-Nachverfolgbarkeit für Auditing erfordert
Junioren von einer durchgesetzten Architektur profitieren
Debugging einen Übergangsverlauf benötigt
Die Branche Audit-Trails verlangt (Fintech, Healthcare)

Quellen

Riverpod 3.0 What's New: automatische Wiederholung, Pause/Resume, Offline-Persistenz
Riverpod 3.0 Migration Guide: Notifier ersetzt StateNotifier
flutter_bloc 9.0.0 Changelog: EmittableStateStreamableSource, Testing-Verbesserungen
BLoC Documentation: offizielle Patterns und Best Practices

Kernpunkte zu Riverpod vs BLoC in 2026

Riverpod und BLoC adressieren effektiv die Anforderungen des State Managements in Flutter. Riverpod 3.x glänzt durch Ergonomie, automatische Fehlerbehandlung und flexible Komposition. BLoC 9.x überzeugt durch Struktur, Vorhersagbarkeit und Enterprise-Level Nachverfolgbarkeit. Beide Lösungen bieten exzellente Testbarkeit und optimale Leistung.

Entscheidungs-Checkliste

Teamgröße und Erfahrung bewerten
Komplexität des Datenflusses berücksichtigen
Anforderungen an Nachverfolgbarkeit und Debugging analysieren
Beide Lösungen an einem Prototyp testen
Konsistenz mit der bestehenden Architektur prüfen

Fang an zu üben!

Teste dein Wissen mit unseren Interview-Simulatoren und technischen Tests.

Kostenloses Konto erstellen

Die beste Wahl bleibt diejenige, die das Team beherrscht und effektiv pflegt. Konsistenz in der Anwendung hat Vorrang vor der Wahl der Lösung selbst. Für Dart-spezifische Patterns wie Isolates und Concurrency siehe den Dart Isolates und Concurrency Guide.

Flutter State Management: Riverpod vs BLoC - Vollständiger Vergleichsleitfaden