Flutter i Firebase w 2026: Uwierzytelnianie, Firestore i pytania rekrutacyjne

Integracja Flutter z Firebase pozostaje najpopularniejszym wyborem backendu dla aplikacji mobilnych w 2026 roku, zapewniając uwierzytelnianie, bazy danych w czasie rzeczywistym i funkcje chmurowe w milionach aplikacji. Wraz z wydaniem FlutterFire SDK v4.15 narzędzia znacząco dojrzały — od uproszczonej konfiguracji za pomocą flutterfire configure po natywne wsparcie dla Firestore Pipelines i Firebase Admin Dart SDK.

Konfiguracja Firebase w projekcie Flutter

Przed napisaniem jakiegokolwiek kodu Firebase projekt wymaga prawidłowej inicjalizacji. FlutterFire CLI automatyzuje rejestrację platformy i generuje pliki konfiguracyjne dla Android, iOS, web oraz macOS.

import 'package:firebase_core/firebase_core.dart';
import 'package:flutter/material.dart';
import 'firebase_options.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  // Initialize Firebase with platform-specific config
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );
  runApp(const MyApp());
}

Plik firebase_options.dart jest generowany automatycznie po uruchomieniu flutterfire configure. Zawiera klucze API, identyfikatory projektu i identyfikatory specyficzne dla platformy — bez konieczności ręcznego kopiowania z konsoli Firebase.

Uwierzytelnianie Firebase: Email, Google i uwierzytelnianie wielopoziomowe

Firebase Authentication obsługuje tożsamość użytkowników przy minimalnej ilości kodu szablonowego. Pakiet firebase_auth wspiera email/hasło, dostawców OAuth (Google, Apple, GitHub), weryfikację telefoniczną przez SMS oraz uwierzytelnianie wielopoziomowe (MFA).

Rejestracja za pomocą adresu email i hasła

Najczęstszy przepływ rozpoczyna się od email/hasło. Metoda createUserWithEmailAndPassword zwraca obiekt UserCredential zawierający uwierzytelniony obiekt User.

import 'package:firebase_auth/firebase_auth.dart';

class AuthService {
  final FirebaseAuth _auth = FirebaseAuth.instance;

  // Register with email and password
  Future<User?> register(String email, String password) async {
    try {
      final credential = await _auth.createUserWithEmailAndPassword(
        email: email,
        password: password,
      );
      return credential.user;
    } on FirebaseAuthException catch (e) {
      // Handle specific error codes
      switch (e.code) {
        case 'email-already-in-use':
          throw Exception('This email is already registered');
        case 'weak-password':
          throw Exception('Password must be at least 6 characters');
        default:
          throw Exception('Registration failed: ${e.message}');
      }
    }
  }

  // Sign in with existing credentials
  Future<User?> signIn(String email, String password) async {
    final credential = await _auth.signInWithEmailAndPassword(
      email: email,
      password: password,
    );
    return credential.user;
  }

  // Reactive auth state stream
  Stream<User?> get authStateChanges => _auth.authStateChanges();
}

Strumień authStateChanges() to rekomendowany sposób śledzenia stanu logowania w całej aplikacji. Emituje bieżącego użytkownika User przy subskrypcji i reaguje ponownie przy każdym zdarzeniu logowania lub wylogowania.

Integracja logowania przez Google

Dostawcy OAuth wymagają dodatkowego pakietu. Logowanie przez Google uruchamia natywny selektor kont, a następnie wymienia token z Firebase.

import 'package:firebase_auth/firebase_auth.dart';
import 'package:google_sign_in/google_sign_in.dart';

Future<UserCredential> signInWithGoogle() async {
  // Trigger the native Google Sign-In flow
  final googleUser = await GoogleSignIn().signIn();
  if (googleUser == null) throw Exception('Sign-in cancelled');

  // Obtain auth details from the Google account
  final googleAuth = await googleUser.authentication;

  // Create a Firebase credential from the Google tokens
  final credential = GoogleAuthProvider.credential(
    accessToken: googleAuth.accessToken,
    idToken: googleAuth.idToken,
  );

  // Sign in to Firebase with the Google credential
  return FirebaseAuth.instance.signInWithCredential(credential);
}

Ten wzorzec stosuje się do wszystkich dostawców OAuth: uzyskanie tokenu dostawcy, opakowanie go w credential Firebase, a następnie wywołanie signInWithCredential.

Operacje CRUD w Firestore i modelowanie danych

Cloud Firestore organizuje dane w kolekcje i dokumenty. W przeciwieństwie do baz SQL, Firestore nie wymaga schematu — każdy dokument może zawierać inne pola. Ta elastyczność dobrze pasuje do aplikacji Flutter, ale wymaga zdyscyplinowanego modelowania danych, aby uniknąć problemów z wydajnością.

Zapis i odczyt dokumentów

Operacje Firestore są proste dzięki pakietowi cloud_firestore. Każdy odczyt i zapis dotyczy konkretnej ścieżki dokumentu.

import 'package:cloud_firestore/cloud_firestore.dart';

class TaskService {
  final _db = FirebaseFirestore.instance;
  final String _collection = 'tasks';

  // Create a new document with auto-generated ID
  Future<String> createTask(String userId, String title) async {
    final doc = await _db.collection(_collection).add({
      'userId': userId,
      'title': title,
      'completed': false,
      'createdAt': FieldValue.serverTimestamp(),
    });
    return doc.id;
  }

  // Read a single document by ID
  Future<Map<String, dynamic>?> getTask(String taskId) async {
    final snapshot = await _db.collection(_collection).doc(taskId).get();
    return snapshot.data();
  }

  // Update specific fields without overwriting the entire document
  Future<void> toggleComplete(String taskId, bool completed) async {
    await _db.collection(_collection).doc(taskId).update({
      'completed': completed,
      'updatedAt': FieldValue.serverTimestamp(),
    });
  }

  // Delete a document
  Future<void> deleteTask(String taskId) async {
    await _db.collection(_collection).doc(taskId).delete();
  }
}

FieldValue.serverTimestamp() zapewnia spójne znaczniki czasu na wszystkich urządzeniach, wykorzystując zegar serwera Firestore zamiast zegara klienta.

Strumienie czasu rzeczywistego z snapshots()

Firestore wyróżnia się synchronizacją w czasie rzeczywistym. Metoda snapshots() zwraca Stream, który emituje nowe dane za każdym razem, gdy bazowe dokumenty ulegną zmianie — bez konieczności odpytywania.

import 'package:cloud_firestore/cloud_firestore.dart';

class TaskStream {
  final _db = FirebaseFirestore.instance;

  // Stream all tasks for a specific user, ordered by creation date
  Stream<List<Map<String, dynamic>>> userTasks(String userId) {
    return _db
        .collection('tasks')
        .where('userId', isEqualTo: userId)
        .orderBy('createdAt', descending: true)
        .snapshots()
        .map((snapshot) => snapshot.docs.map((doc) {
              final data = doc.data();
              data['id'] = doc.id; // Include document ID
              return data;
            }).toList());
  }
}

W widgecie Flutter ten strumień integruje się bezpośrednio z StreamBuilder, aby przebudowywać interfejs przy każdej zmianie w bazie danych. Firestore automatycznie zarządza połączeniami, buforowaniem i trwałością offline.

Reguły bezpieczeństwa Firestore dla aplikacji Flutter

Reguły bezpieczeństwa działają na serwerze Firestore i kontrolują dostęp do odczytu/zapisu na poziomie dokumentu. Bez odpowiednich reguł każdy uwierzytelniony użytkownik mógłby odczytać lub zmodyfikować dowolny dokument.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Users can only access their own profile
    match /users/{userId} {
      allow read, update: if request.auth != null
                          && request.auth.uid == userId;
      allow create: if request.auth != null;
      allow delete: if false; // Prevent self-deletion
    }

    // Tasks belong to the user who created them
    match /tasks/{taskId} {
      allow read, write: if request.auth != null
                         && resource.data.userId == request.auth.uid;
      allow create: if request.auth != null
                    && request.resource.data.userId == request.auth.uid;
    }
  }
}

Zmienna request.auth.uid zawiera identyfikator uwierzytelnionego użytkownika z Firebase Auth. Reguły odwołujące się do resource.data sprawdzają istniejące pola dokumentu, natomiast request.resource.data waliduje przychodzące dane zapisu.

Trwałość offline i strategia buforowania

Firestore domyślnie włącza trwałość offline na platformach mobilnych. Gdy urządzenie traci łączność, operacje odczytu zwracają dane z pamięci podręcznej, a operacje zapisu kolejkują się lokalnie do momentu wznowienia połączenia.

To zachowanie jest transparentne dla kodu Flutter — te same wywołania get() i snapshots() działają offline. Jednak w aplikacjach produkcyjnych istotne są dwie kwestie:

• Rozmiar pamięci podręcznej: Firestore buforuje wszystkie dokumenty, które klient odczytał. Dla aplikacji z dużą ilością danych warto skonfigurować Settings(cacheSizeBytes: Settings.CACHE_SIZE_UNLIMITED) lub ustawić konkretny limit. Wydanie v6.4.1 naprawiło błąd, gdzie nieograniczona pamięć podręczna nie była poprawnie stosowana na iOS.
• Wskaźnik oczekujących zapisów: Właściwość SnapshotMetadata.hasPendingWrites pozwala pokazać użytkownikom, kiedy lokalne zmiany nie zostały jeszcze zsynchronizowane z serwerem.

StreamBuilder<DocumentSnapshot>(
  stream: FirebaseFirestore.instance
      .collection('tasks')
      .doc(taskId)
      .snapshots(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) return const CircularProgressIndicator();

    final data = snapshot.data!;
    final isPending = data.metadata.hasPendingWrites;

    return Row(
      children: [
        Text(data['title']),
        if (isPending) const Icon(Icons.cloud_upload, size: 16),
      ],
    );
  },
)

Architektura produkcyjnej aplikacji Flutter z Firebase

Skalowalna architektura oddziela logikę Firebase od kodu UI. Wzorzec repozytorium zapewnia czystą warstwę abstrakcji, która upraszcza testowanie i przyszłe migracje backendu.

abstract class TaskRepository {
  Future<String> create(String userId, String title);
  Stream<List<Task>> watchAll(String userId);
  Future<void> update(String id, Map<String, dynamic> fields);
  Future<void> delete(String id);
}

// firebase_task_repository.dart
class FirebaseTaskRepository implements TaskRepository {
  final _db = FirebaseFirestore.instance;

  @override
  Future<String> create(String userId, String title) async {
    final doc = await _db.collection('tasks').add({
      'userId': userId,
      'title': title,
      'completed': false,
      'createdAt': FieldValue.serverTimestamp(),
    });
    return doc.id;
  }

  @override
  Stream<List<Task>> watchAll(String userId) {
    return _db
        .collection('tasks')
        .where('userId', isEqualTo: userId)
        .orderBy('createdAt', descending: true)
        .snapshots()
        .map((s) => s.docs.map(Task.fromFirestore).toList());
  }

  // ... update and delete implementations
}

Dzięki temu wzorcowi rozwiązania zarządzania stanem, takie jak Riverpod czy BLoC, konsumują interfejs repozytorium bez wiedzy o Firestore. Testy jednostkowe mogą podstawić mocka repozytorium zwracającego predefiniowane dane.

Najczęstsze pytania rekrutacyjne: Flutter i Firebase

Rozmowy kwalifikacyjne często sprawdzają zarówno zrozumienie koncepcyjne, jak i praktyczną implementację usług Firebase. Poniższe pytania regularnie pojawiają się na rozmowach z programistami Flutter w 2026 roku.

Czym różni się authStateChanges() od idTokenChanges() i userChanges()?

authStateChanges() reaguje wyłącznie na zdarzenia logowania i wylogowania. idTokenChanges() reaguje dodatkowo na odświeżenie tokenu ID (mniej więcej co 60 minut). userChanges() obejmuje wszystkie powyższe zdarzenia plus aktualizacje profilu, takie jak updateDisplayName(). Do większości zabezpieczeń nawigacyjnych wystarczający jest authStateChanges().

Co dzieje się, gdy zapis do Firestore następuje, gdy urządzenie jest offline?

Zapis jest przechowywany w lokalnej pamięci podręcznej i kolejce oczekujących zapisów. Listenery snapshots() natychmiast otrzymują zaktualizowane dane z metadata.hasPendingWrites == true. Po wznowieniu łączności Firestore automatycznie synchronizuje oczekujące zapisy, stosując rozwiązywanie konfliktów "ostatni zapis wygrywa" na poziomie pola.

Jak powinno wyglądać modelowanie danych Firestore dla aplikacji czatu?

Popularne podejście: kolekcja chats, gdzie każdy dokument zawiera metadane (uczestnicy, znacznik czasu ostatniej wiadomości) oraz podkolekcja messages pod każdym dokumentem czatu. Ta struktura umożliwia efektywne zapytania o listę czatów użytkownika przy jednoczesnym stronicowaniu wiadomości w każdej konwersacji. Denormalizacja ostatniej wiadomości do dokumentu nadrzędnego pozwala uniknąć odczytywania podkolekcji przy wyświetlaniu listy.

Dlaczego FieldValue.serverTimestamp() jest preferowane nad DateTime.now()?

DateTime.now() korzysta z zegara urządzenia, który może być niedokładny lub zmanipulowany. FieldValue.serverTimestamp() wykorzystuje zegar serwera Firestore, gwarantując spójne sortowanie na wszystkich klientach. Ma to znaczenie dla funkcji takich jak kolejność wiadomości, kanały aktywności i logi audytu.

Jak obsługiwane są zapytania złożone w Firestore i jakie są wymagania dotyczące indeksów?

Firestore wymaga indeksu złożonego dla zapytań łączących wiele pól z klauzulami where i orderBy. Indeksy jednopolowe są tworzone automatycznie, ale indeksy złożone muszą być zdefiniowane ręcznie w pliku firestore.indexes.json lub przez konsolę Firebase. Gdy zapytanie kończy się niepowodzeniem, Firestore loguje bezpośredni link do utworzenia brakującego indeksu.

Więcej materiałów do przygotowania do rozmów kwalifikacyjnych z Flutter i Firebase dostępnych jest w interaktywnych modułach ćwiczeniowych, które obejmują te zagadnienia wraz ze szczegółowymi wyjaśnieniami.