20 Flutter-Interviewfragen – Technisches Interview meistern

Flutter-Interviews prüfen die Beherrschung des Frameworks, der Programmiersprache Dart und mobiler Architekturmuster. Dieser Leitfaden behandelt die 20 am häufigsten gestellten Fragen, von Grundlagen bis zu fortgeschrittenen Konzepten, mit ausführlichen Antworten und Codebeispielen.

Interview-Tipp

Interviewer schätzen Kandidaten, die neben dem „Wie“ auch das „Warum“ erläutern. Bei jedem Konzept machen das Verständnis von Anwendungsfällen und technischen Kompromissen den Unterschied.

Grundlegende Flutter- und Dart-Fragen

1. Was ist der Unterschied zwischen StatelessWidget und StatefulWidget?

StatelessWidget repräsentiert ein unveränderliches Widget, dessen Erscheinungsbild ausschließlich von seiner initialen Konfiguration abhängt. Einmal erstellt, ändert es sich nie. StatefulWidget verwaltet veränderlichen Zustand, der sich im Laufe der Zeit entwickeln kann und Widget-Neuaufbauten auslöst.

stateless_example.dartdart

// StatelessWidget: static display, no change after construction
class WelcomeMessage extends StatelessWidget {
  // Final parameter - never changes
  final String username;

  const WelcomeMessage({super.key, required this.username});

  @override
  Widget build(BuildContext context) {
    // Build called once (unless parent rebuilds)
    return Text('Welcome, $username');
  }
}

stateful_example.dartdart

// StatefulWidget: mutable state, can rebuild itself
class LikeButton extends StatefulWidget {
  const LikeButton({super.key});

  @override
  State<LikeButton> createState() => _LikeButtonState();
}

class _LikeButtonState extends State<LikeButton> {
  // Mutable local state
  int _likeCount = 0;

  void _incrementLike() {
    // setState triggers rebuild with new state
    setState(() {
      _likeCount++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: _incrementLike,
      child: Text('Likes: $_likeCount'),
    );
  }
}

Die Regel lautet: StatelessWidget standardmäßig verwenden, StatefulWidget nur für widget-lokalen Zustand.

Flutter organisiert die Oberfläche in drei miteinander verbundene Bäume: den Widget Tree (unveränderliche Deklaration), den Element Tree (Lebenszyklus und Bindung) und den Render Tree (Layout und Zeichnung).

widget_tree_example.dartdart

// Declarative structure - widgets describe the UI
class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Each widget creates an Element in the Element Tree
    return MaterialApp(
      home: Scaffold(
        // Scaffold creates multiple RenderObjects
        body: Center(
          // Center modifies its child's layout
          child: Column(
            children: [
              // Each Text has its own RenderParagraph
              Text('First'),
              Text('Second'),
            ],
          ),
        ),
      ),
    );
  }
}

Beim Aufruf von setState vergleicht Flutter den alten und neuen Widget-Baum, um nur die geänderten Elemente neu aufzubauen. Diese Differenzierung basiert auf Keys und Widget-Typen.

3. Was ist ein const-Konstruktor und warum sollte man ihn verwenden?

Const-Konstruktoren erstellen Widgets zur Kompilierungszeit statt zur Laufzeit. Flutter kann diese Instanzen wiederverwenden, was die Performance verbessert, indem unnötige Neuaufbauten vermieden werden.

const_example.dartdart

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

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        // ✅ const: same instance reused on each build
        const Icon(Icons.star, size: 48),
        const SizedBox(height: 16),
        const Text('Static title'),

        // ❌ Non-const: new instance on each build
        Icon(Icons.star, color: Theme.of(context).primaryColor),
      ],
    );
  }
}

// Custom widget with const constructor
class StaticCard extends StatelessWidget {
  final String title;

  // All fields must be final for const
  const StaticCard({super.key, required this.title});

  @override
  Widget build(BuildContext context) {
    return Card(child: Text(title));
  }
}

Der Flutter-Analyzer weist mit dem Lint prefer_const_constructors auf verpasste Gelegenheiten hin.

4. Die verschiedenen Arten von Keys in Flutter erklärt

Keys bewahren den Widget-Zustand bei Umstrukturierungen. Ohne Keys stützt sich Flutter auf die Position im Baum, was bei der Neuordnung von Listen zu Fehlern führen kann.

keys_example.dartdart

class TodoList extends StatelessWidget {
  final List<Todo> todos;

  const TodoList({super.key, required this.todos});

  @override
  Widget build(BuildContext context) {
    return ListView.builder(
      itemCount: todos.length,
      itemBuilder: (context, index) {
        final todo = todos[index];
        // ✅ ValueKey: preserves state if order changes
        return TodoTile(
          key: ValueKey(todo.id),
          todo: todo,
        );
      },
    );
  }
}

// Different key types for different contexts
class KeyExamples extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        // ValueKey: based on a unique value
        Container(key: ValueKey('unique-id')),

        // ObjectKey: based on object identity
        Container(key: ObjectKey(myObject)),

        // UniqueKey: new key on each build
        Container(key: UniqueKey()),

        // GlobalKey: access state from outside
        Form(key: _formKey),
      ],
    );
  }
}

GlobalKeys ermöglichen zusätzlich den Zugriff auf den Zustand eines Widgets von überall, sollten aber sparsam eingesetzt werden.

Dart-Fragen

5. Was ist der Unterschied zwischen final und const in Dart?

final definiert eine Variable, die nur einmal zugewiesen werden kann und zur Laufzeit ausgewertet wird. const erstellt eine Kompilierungszeitkonstante, unveränderlich und vor der Ausführung ausgewertet.

final_const_example.dartdart

class DateExample {
  // final: value assigned at runtime
  final DateTime createdAt = DateTime.now();

  // const: value known at compile time
  static const int maxItems = 100;
  static const String appName = 'MyApp';

  // ❌ Error: DateTime.now() not const (runtime value)
  // static const DateTime timestamp = DateTime.now();
}

void demonstrateDifference() {
  // final: each call can have different value
  final timestamp1 = DateTime.now();
  final timestamp2 = DateTime.now();
  print(timestamp1 == timestamp2); // false (different)

  // const: same instance reused
  const list1 = [1, 2, 3];
  const list2 = [1, 2, 3];
  print(identical(list1, list2)); // true (same instance)
}

In Flutter sollte const für statische Widgets und final für berechnete Werte bevorzugt werden.

6. Wie funktionieren Futures und async/await?

Future repräsentiert einen Wert, der später verfügbar sein wird. async/await bietet eine lesbare Syntax für die Behandlung dieser asynchronen Operationen ohne verschachtelte Callbacks.

async_example.dartdart

class UserRepository {
  final ApiClient _client;

  UserRepository(this._client);

  // Future: promise of a future value
  Future<User> fetchUser(String id) async {
    try {
      // await suspends execution until resolution
      final response = await _client.get('/users/$id');
      return User.fromJson(response);
    } catch (e) {
      // Errors propagate normally with async/await
      throw UserNotFoundException(id);
    }
  }

  // Parallel execution with Future.wait
  Future<List<User>> fetchUsers(List<String> ids) async {
    // All requests start simultaneously
    final futures = ids.map((id) => fetchUser(id));
    // Wait for all to complete
    return Future.wait(futures);
  }

  // Sequential processing
  Future<void> processSequentially(List<String> ids) async {
    for (final id in ids) {
      // Each request waits for the previous one
      await fetchUser(id);
    }
  }
}

Future.wait für Parallelität, asynchrone Schleifen für sequentielle Verarbeitung.

FutureBuilder vs Riverpod

FutureBuilder funktioniert für einfache Fälle, aber Riverpod (AsyncValue) bietet besseres Cache-Management, Fehlerbehandlung und Aktualisierungsfunktionen für komplexe Anwendungen.

7. Streams und ihre Verwendung erklärt

Streams repräsentieren asynchrone Wertefolgen, ideal für Echtzeit-Ereignisse: WebSockets, Sensordaten oder Benutzerinteraktionen.

stream_example.dartdart

class MessageService {
  // StreamController manages creation and broadcasting
  final _messageController = StreamController<Message>.broadcast();

  // Expose only the Stream (not the Sink)
  Stream<Message> get messages => _messageController.stream;

  void addMessage(Message message) {
    _messageController.sink.add(message);
  }

  void dispose() {
    _messageController.close();
  }
}

// Usage with StreamBuilder
class MessageList extends StatelessWidget {
  final MessageService service;

  const MessageList({super.key, required this.service});

  @override
  Widget build(BuildContext context) {
    return StreamBuilder<Message>(
      stream: service.messages,
      builder: (context, snapshot) {
        // Handle all possible states
        if (snapshot.connectionState == ConnectionState.waiting) {
          return const CircularProgressIndicator();
        }
        if (snapshot.hasError) {
          return Text('Error: ${snapshot.error}');
        }
        if (!snapshot.hasData) {
          return const Text('No messages');
        }
        return MessageCard(message: snapshot.data!);
      },
    );
  }
}

.broadcast()-Streams erlauben mehrere Listener, im Gegensatz zu Single-Subscription-Streams.

Bereit für deine Flutter-Interviews?

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

Flutter erkunden

Architektur- und State-Management-Fragen

8. State-Management-Lösungen im Vergleich: Provider, Riverpod, Bloc

Jede Lösung adressiert unterschiedliche Bedürfnisse. Provider bietet Einfachheit und native Integration. Riverpod bringt Typsicherheit und Testbarkeit. Bloc erzwingt eine strikte ereignisgesteuerte Architektur.

riverpod_example.dartdart

// Riverpod: declarative and type-safe approach
final userProvider = FutureProvider.autoDispose<User>((ref) async {
  final repository = ref.watch(userRepositoryProvider);
  return repository.fetchCurrentUser();
});

class UserProfile extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // AsyncValue handles loading/error/data
    final userAsync = ref.watch(userProvider);

    return userAsync.when(
      loading: () => const CircularProgressIndicator(),
      error: (error, stack) => Text('Error: $error'),
      data: (user) => Text(user.displayName),
    );
  }
}

bloc_example.dartdart

// Bloc: explicit events/states separation
abstract class AuthEvent {}
class LoginRequested extends AuthEvent {
  final String email;
  final String password;
  LoginRequested(this.email, this.password);
}

abstract class AuthState {}
class AuthInitial extends AuthState {}
class AuthLoading extends AuthState {}
class AuthSuccess extends AuthState {
  final User user;
  AuthSuccess(this.user);
}
class AuthFailure extends AuthState {
  final String error;
  AuthFailure(this.error);
}

class AuthBloc extends Bloc<AuthEvent, AuthState> {
  AuthBloc() : super(AuthInitial()) {
    on<LoginRequested>(_onLoginRequested);
  }

  Future<void> _onLoginRequested(
    LoginRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(AuthLoading());
    try {
      final user = await _repository.login(event.email, event.password);
      emit(AuthSuccess(user));
    } catch (e) {
      emit(AuthFailure(e.toString()));
    }
  }
}

Riverpod wird für neue Projekte empfohlen, dank seiner modernen API und einfachen Testbarkeit.

9. Was ist Clean Architecture in Flutter?

Clean Architecture trennt Code in unabhängige Schichten: Domain (Geschäftslogik), Data (Datenquellen) und Presentation (UI). Diese Trennung erleichtert Testen und Wartung.

domain/entities/user.dartdart

// Entity: pure business object, no framework dependency
class User {
  final String id;
  final String email;
  final String name;

  const User({
    required this.id,
    required this.email,
    required this.name,
  });
}

// domain/repositories/user_repository.dart
// Interface: abstract contract, implementation in Data
abstract class UserRepository {
  Future<User> getUser(String id);
  Future<void> updateUser(User user);
}

// domain/usecases/get_user_usecase.dart
// Use case: isolated business logic
class GetUserUseCase {
  final UserRepository _repository;

  GetUserUseCase(this._repository);

  Future<User> call(String userId) {
    return _repository.getUser(userId);
  }
}

data/repositories/user_repository_impl.dartdart

// Concrete implementation with data sources
class UserRepositoryImpl implements UserRepository {
  final UserRemoteDataSource _remoteDataSource;
  final UserLocalDataSource _localDataSource;

  UserRepositoryImpl(this._remoteDataSource, this._localDataSource);

  @override
  Future<User> getUser(String id) async {
    try {
      // Try local cache first
      final cachedUser = await _localDataSource.getUser(id);
      if (cachedUser != null) return cachedUser;
    } catch (_) {}

    // Fallback to API
    final user = await _remoteDataSource.fetchUser(id);
    await _localDataSource.cacheUser(user);
    return user;
  }
}

Die Domain-Schicht hängt von nichts ab, Data hängt von Domain ab, Presentation hängt von beiden ab.

10. Wie implementiert man Dependency Injection?

Dependency Injection entkoppelt Komponenten, indem Abhängigkeiten von außen bereitgestellt werden. Riverpod eignet sich dafür hervorragend mit seinen Providern.

di_example.dartdart

// Provider definitions (dependencies)
final apiClientProvider = Provider<ApiClient>((ref) {
  return ApiClient(baseUrl: Environment.apiUrl);
});

final userRepositoryProvider = Provider<UserRepository>((ref) {
  // Automatically injects ApiClient
  final client = ref.watch(apiClientProvider);
  return UserRepositoryImpl(client);
});

final getUserUseCaseProvider = Provider<GetUserUseCase>((ref) {
  final repository = ref.watch(userRepositoryProvider);
  return GetUserUseCase(repository);
});

// Usage in a widget
class UserScreen extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final getUserUseCase = ref.watch(getUserUseCaseProvider);
    // Use the use case...
  }
}

// Tests: easy dependency override
void main() {
  testWidgets('displays user', (tester) async {
    await tester.pumpWidget(
      ProviderScope(
        overrides: [
          // Replace with mock for tests
          userRepositoryProvider.overrideWithValue(MockUserRepository()),
        ],
        child: const MyApp(),
      ),
    );
  });
}

Der größte Vorteil: Tests können jede Abhängigkeit durch ein Mock ersetzen.

Performance-Fragen

11. Wie optimiert man die Rebuild-Performance?

Die Minimierung von Rebuilds verbessert die Performance. Zentrale Techniken: const-Widgets, granulare Aufspaltung und Riverpod-Selektoren.

rebuild_optimization.dartdart

// ❌ Bad: everything rebuilds on each change
class BadExample extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final user = ref.watch(userProvider);
    return Column(
      children: [
        Text(user.name),
        Text(user.email),
        const ExpensiveWidget(), // Rebuilds unnecessarily
      ],
    );
  }
}

// ✅ Good: selector to rebuild only if name changes
class GoodExample extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // select: rebuilds only if name changes
    final name = ref.watch(userProvider.select((u) => u.name));
    return Text(name);
  }
}

// ✅ Good: splitting into smaller widgets
class OptimizedScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        const Header(), // Static, never rebuilds
        const UserNameWidget(), // Rebuilds if name changes
        const UserEmailWidget(), // Rebuilds if email changes
        const Footer(), // Static
      ],
    );
  }
}

DevTools Performance hilft bei der Identifizierung überflüssiger Rebuilds.

12. Wie optimiert man lange Listen?

Lange Listen erfordern Lazy Loading mit ListView.builder. ListView mit direkten Kindern sollte bei mehr als 20 Elementen vermieden werden.

list_optimization.dartdart

class OptimizedList extends StatelessWidget {
  final List<Item> items;

  const OptimizedList({super.key, required this.items});

  @override
  Widget build(BuildContext context) {
    // ✅ ListView.builder: builds on demand
    return ListView.builder(
      // Fixed height improves scrolling
      itemExtent: 72,
      itemCount: items.length,
      itemBuilder: (context, index) {
        return ItemTile(
          // Key to preserve state during scroll
          key: ValueKey(items[index].id),
          item: items[index],
        );
      },
    );
  }
}

// List widget with infinite loading
class InfiniteList extends ConsumerStatefulWidget {
  @override
  ConsumerState<InfiniteList> createState() => _InfiniteListState();
}

class _InfiniteListState extends ConsumerState<InfiniteList> {
  final _scrollController = ScrollController();

  @override
  void initState() {
    super.initState();
    _scrollController.addListener(_onScroll);
  }

  void _onScroll() {
    // Load more data near the end
    if (_scrollController.position.pixels >=
        _scrollController.position.maxScrollExtent - 200) {
      ref.read(itemsProvider.notifier).loadMore();
    }
  }

  @override
  Widget build(BuildContext context) {
    final items = ref.watch(itemsProvider);
    return ListView.builder(
      controller: _scrollController,
      itemCount: items.length,
      itemBuilder: (context, index) => ItemTile(item: items[index]),
    );
  }
}

Für sehr lange Listen (1000+ Elemente) sind ListView.separated oder spezialisierte Pakete wie scrollable_positioned_list empfehlenswert.

Bild-Caching

Bei Listen mit Bildern sollte cached_network_image verwendet werden, um Neuladen zu vermeiden. Nicht gecachte Bilder verursachen Ruckler beim Scrollen.

13. Wie funktioniert die Impeller-Rendering-Engine?

Impeller ersetzt Skia als Standard-Rendering-Engine (Flutter 3.16+). Shader werden vorkompiliert, um „Jank“ bei der ersten Anzeige zu eliminieren.

impeller_benefits.dartdart

// Complex animations benefit from Impeller
class SmoothAnimation extends StatefulWidget {
  @override
  State<SmoothAnimation> createState() => _SmoothAnimationState();
}

class _SmoothAnimationState extends State<SmoothAnimation>
    with SingleTickerProviderStateMixin {
  late AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      duration: const Duration(seconds: 2),
      vsync: this,
    )..repeat();
  }

  @override
  Widget build(BuildContext context) {
    return AnimatedBuilder(
      animation: _controller,
      builder: (context, child) {
        // Impeller: no runtime shader compilation
        return Transform.rotate(
          angle: _controller.value * 2 * 3.14159,
          child: child,
        );
      },
      child: const FlutterLogo(size: 100),
    );
  }
}

Impeller ist standardmäßig auf iOS aktiviert. Auf Android lässt sich die Kompatibilität mit flutter run --enable-impeller prüfen.

Navigations- und Formular-Fragen

Deep Linking ermöglicht das Öffnen der App auf einem bestimmten Bildschirm über eine URL. GoRouter behandelt diese Funktionalität nativ.

deep_linking.dartdart

final router = GoRouter(
  routes: [
    GoRoute(
      path: '/products/:productId',
      builder: (context, state) {
        // Extract URL parameter
        final productId = state.pathParameters['productId']!;
        return ProductScreen(productId: productId);
      },
    ),
    GoRoute(
      path: '/search',
      builder: (context, state) {
        // Query parameters (?query=flutter)
        final query = state.uri.queryParameters['query'] ?? '';
        return SearchScreen(initialQuery: query);
      },
    ),
  ],
);

// Programmatic navigation
void navigateToProduct(BuildContext context, String id) {
  // go: replaces navigation stack
  context.go('/products/$id');

  // push: adds to stack (allows back)
  context.push('/products/$id');

  // pushNamed with extra for complex data
  context.pushNamed(
    'productDetail',
    pathParameters: {'productId': id},
    extra: ProductData(id: id),
  );
}

Die nativen Dateien (AndroidManifest.xml, Info.plist) müssen konfiguriert werden, um systemweites Deep Linking zu aktivieren.

15. Wie validiert man Formulare effektiv?

Validierung kombiniert Form, TextFormField und benutzerdefinierte Validatoren. Zod-ähnliche Pakete wie formz bringen zusätzliche Struktur.

form_validation.dartdart

class RegistrationForm extends StatefulWidget {
  @override
  State<RegistrationForm> createState() => _RegistrationFormState();
}

class _RegistrationFormState extends State<RegistrationForm> {
  final _formKey = GlobalKey<FormState>();
  final _emailController = TextEditingController();
  final _passwordController = TextEditingController();
  final _confirmController = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      // Real-time validation
      autovalidateMode: AutovalidateMode.onUserInteraction,
      child: Column(
        children: [
          TextFormField(
            controller: _emailController,
            decoration: const InputDecoration(labelText: 'Email'),
            keyboardType: TextInputType.emailAddress,
            validator: _validateEmail,
          ),
          TextFormField(
            controller: _passwordController,
            decoration: const InputDecoration(labelText: 'Password'),
            obscureText: true,
            validator: _validatePassword,
          ),
          TextFormField(
            controller: _confirmController,
            decoration: const InputDecoration(labelText: 'Confirm'),
            obscureText: true,
            validator: _validateConfirmPassword,
          ),
          ElevatedButton(
            onPressed: _submit,
            child: const Text('Create account'),
          ),
        ],
      ),
    );
  }

  String? _validateEmail(String? value) {
    if (value == null || value.isEmpty) {
      return 'Email required';
    }
    final emailRegex = RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$');
    if (!emailRegex.hasMatch(value)) {
      return 'Invalid email format';
    }
    return null;
  }

  String? _validatePassword(String? value) {
    if (value == null || value.length < 8) {
      return 'Minimum 8 characters';
    }
    if (!value.contains(RegExp(r'[A-Z]'))) {
      return 'At least one uppercase letter required';
    }
    if (!value.contains(RegExp(r'[0-9]'))) {
      return 'At least one number required';
    }
    return null;
  }

  String? _validateConfirmPassword(String? value) {
    if (value != _passwordController.text) {
      return 'Passwords do not match';
    }
    return null;
  }

  void _submit() {
    if (_formKey.currentState!.validate()) {
      // Form is valid, proceed
    }
  }
}

Der Modus AutovalidateMode.onUserInteraction bietet die beste UX: Fehler werden erst nach der Interaktion angezeigt.

Testing-Fragen

16. Wie testet man Flutter-Widgets?

Widget-Tests verifizieren die UI ohne Abhängigkeit von einem Gerät. Das Paket flutter_test stellt die notwendigen Hilfsmittel bereit.

widget_test.dartdart

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

void main() {
  testWidgets('displays welcome message', (tester) async {
    // Arrange: build the widget
    await tester.pumpWidget(
      const ProviderScope(
        child: MaterialApp(
          home: WelcomeScreen(username: 'Alice'),
        ),
      ),
    );

    // Assert: verify content
    expect(find.text('Welcome, Alice'), findsOneWidget);
  });

  testWidgets('button increments counter', (tester) async {
    await tester.pumpWidget(
      const MaterialApp(home: CounterScreen()),
    );

    // Initial state
    expect(find.text('0'), findsOneWidget);

    // Act: tap the button
    await tester.tap(find.byType(ElevatedButton));
    await tester.pump(); // Rebuild after setState

    // Assert: counter incremented
    expect(find.text('1'), findsOneWidget);
  });

  testWidgets('form validates email', (tester) async {
    await tester.pumpWidget(
      const MaterialApp(home: LoginForm()),
    );

    // Enter invalid email
    await tester.enterText(
      find.byKey(const Key('email-field')),
      'invalid-email',
    );
    await tester.tap(find.byType(ElevatedButton));
    await tester.pump();

    // Verify error message
    expect(find.text('Invalid email format'), findsOneWidget);
  });
}

pump() rückt einen Frame vor, pumpAndSettle() wartet auf den Abschluss aller Animationen.

17. Wie testet man Riverpod-Provider?

Riverpod erleichtert das Testen durch ProviderContainer und Overrides.

provider_test.dartdart

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

// Repository mock
class MockUserRepository extends Mock implements UserRepository {}

void main() {
  late MockUserRepository mockRepository;
  late ProviderContainer container;

  setUp(() {
    mockRepository = MockUserRepository();
    container = ProviderContainer(
      overrides: [
        userRepositoryProvider.overrideWithValue(mockRepository),
      ],
    );
  });

  tearDown(() {
    container.dispose();
  });

  test('loads user from repository', () async {
    // Arrange
    final expectedUser = User(id: '1', name: 'Test');
    when(() => mockRepository.getUser('1'))
        .thenAnswer((_) async => expectedUser);

    // Act
    final user = await container.read(userProvider('1').future);

    // Assert
    expect(user, expectedUser);
    verify(() => mockRepository.getUser('1')).called(1);
  });

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

    expect(
      () => container.read(userProvider('1').future),
      throwsException,
    );
  });
}

Provider-Tests sind schnell, da sie kein UI-Rendering erfordern.

Deployment-Fragen

18. Wie verwaltet man verschiedene Umgebungen (Dev, Staging, Prod)?

Umgebungen werden über .env-Dateien oder Kompilierungszeitkonstanten mit --dart-define konfiguriert.

environment.dartdart

enum Environment { dev, staging, prod }

class AppConfig {
  final Environment environment;
  final String apiUrl;
  final bool enableAnalytics;

  const AppConfig._({
    required this.environment,
    required this.apiUrl,
    required this.enableAnalytics,
  });

  // Predefined configurations
  static const dev = AppConfig._(
    environment: Environment.dev,
    apiUrl: 'https://api-dev.example.com',
    enableAnalytics: false,
  );

  static const staging = AppConfig._(
    environment: Environment.staging,
    apiUrl: 'https://api-staging.example.com',
    enableAnalytics: true,
  );

  static const prod = AppConfig._(
    environment: Environment.prod,
    apiUrl: 'https://api.example.com',
    enableAnalytics: true,
  );

  // Read from --dart-define
  static AppConfig fromEnvironment() {
    const env = String.fromEnvironment('ENV', defaultValue: 'dev');
    switch (env) {
      case 'prod':
        return prod;
      case 'staging':
        return staging;
      default:
        return dev;
    }
  }
}

bash

# terminal
# Launch with specific environment
flutter run --dart-define=ENV=staging

# Production build
flutter build apk --dart-define=ENV=prod --release

19. Wie implementiert man Flavoring für mehrere App-Varianten?

Flavoring erstellt mehrere Varianten (Client1, Client2) mit unterschiedlichen Konfigurationen (Icon, Name, API).

main_client1.dartdart

import 'package:flutter/material.dart';
import 'config/flavor_config.dart';
import 'app.dart';

void main() {
  FlavorConfig(
    flavor: Flavor.client1,
    name: 'App Client 1',
    apiUrl: 'https://api.client1.com',
    primaryColor: Colors.blue,
  );
  runApp(const App());
}

// config/flavor_config.dart
enum Flavor { client1, client2, internal }

class FlavorConfig {
  final Flavor flavor;
  final String name;
  final String apiUrl;
  final Color primaryColor;

  // Singleton for global access
  static FlavorConfig? _instance;
  static FlavorConfig get instance => _instance!;

  FlavorConfig({
    required this.flavor,
    required this.name,
    required this.apiUrl,
    required this.primaryColor,
  }) {
    _instance = this;
  }

  bool get isProduction => flavor != Flavor.internal;
}

Die nativen Dateien Android (build.gradle) und iOS (xcconfig) müssen für jeden Flavor konfiguriert werden.

20. Welche Sicherheits-Best-Practices gibt es für Flutter?

Sicherheit umfasst die Speicherung sensibler Daten, Eingabevalidierung und Schutz gegen Reverse Engineering.

security_example.dartdart

import 'package:flutter_secure_storage/flutter_secure_storage.dart';

class SecureStorage {
  // Encrypted storage for sensitive data
  final _storage = const FlutterSecureStorage(
    aOptions: AndroidOptions(encryptedSharedPreferences: true),
    iOptions: IOSOptions(accessibility: KeychainAccessibility.first_unlock),
  );

  Future<void> saveToken(String token) async {
    await _storage.write(key: 'auth_token', value: token);
  }

  Future<String?> getToken() async {
    return _storage.read(key: 'auth_token');
  }

  Future<void> deleteToken() async {
    await _storage.delete(key: 'auth_token');
  }
}

// Input validation
class InputValidator {
  // Injection prevention
  static String sanitize(String input) {
    return input
        .replaceAll(RegExp(r'[<>"\']'), '')
        .trim();
  }

  // Length validation
  static bool isValidLength(String input, int min, int max) {
    return input.length >= min && input.length <= max;
  }
}

// SSL pinning protection
class SecureApiClient {
  Dio createSecureClient() {
    final dio = Dio();
    // Add certificate pinning
    (dio.httpClientAdapter as IOHttpClientAdapter).createHttpClient = () {
      final client = HttpClient();
      client.badCertificateCallback = (cert, host, port) {
        // Verify certificate fingerprint
        return _isValidCertificate(cert);
      };
      return client;
    };
    return dio;
  }
}

Geheimnisse sollten niemals im Code gespeichert werden. flutter_secure_storage für Tokens und --obfuscate für die Produktion verwenden.

Fazit

Diese 20 Fragen decken die wesentlichen Aspekte von Flutter-Interviews ab: Framework-Grundlagen, Dart-Beherrschung, Architekturmuster und Produktions-Best-Practices. Der Erfolg liegt im tiefen Verständnis der zugrundeliegenden Mechanismen, nicht nur in der Syntax.

Vorbereitungs-Checkliste

✅ Den Unterschied zwischen StatelessWidget und StatefulWidget sowie deren Anwendungsfälle beherrschen
✅ Den Widget-Baum und die Rebuild-Optimierung verstehen
✅ async/await, Futures und Streams mit Übungen praktizieren
✅ Ein Projekt mit Riverpod für State Management implementieren
✅ GoRouter und Deep Linking kennen
✅ Unit-Tests und Widget-Tests schreiben
✅ Multi-Umgebungs-Konfiguration verstehen

Fang an zu üben!

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

Kostenloses Konto erstellen

Regelmäßiges Üben an eigenen Projekten bleibt der beste Weg, dieses Wissen zu festigen. Jede hier behandelte Frage verdient eine tiefere Auseinandersetzung mit echtem Code, um die Feinheiten des Flutter-Frameworks zu meistern.

Die 20 wichtigsten Flutter-Interviewfragen für Mobile-Entwickler