Maîtriser Flutter : créer des applications mobiles prêtes pour la production

Construire un prototype Flutter est simple. Créer une application Flutter prête pour la production, évolutive, performante sous charge et maintenable au fil des années nécessite une compréhension beaucoup plus approfondie de l'architecture, de la gestion des états, des tests et des workflows de déploiement. Ce guide comble le fossé entre les projets didactiques et les applications du monde réel, couvrant les modèles et les pratiques sur lesquels les équipes professionnelles Flutter s'appuient chaque jour.

Clean Architecture pour Flutter

Clean Architecture sépare votre application en couches distinctes avec des limites et des règles de dépendance claires. Cette séparation rend votre code testable, maintenable et indépendant des frameworks et outils externes.

Structure des couches

Une application de production Flutter suit généralement une architecture à trois couches :

• Couche de présentation- Widgets, pages et gestion des états. Cette couche dépend de la couche domaine mais jamais directement des sources de données.
• Domain Layer- Logique métier, entités et cas d'utilisation. Cette couche n'a aucune dépendance sur Flutter ou sur tout package externe. Il définit les interfaces de référentiel (classes abstraites) que la couche de données implémente.
• Couche de données- Implémentations de référentiels, clients API, accès à la base de données locale et modèles de données (DTO). Cette couche implémente les interfaces définies dans la couche domaine.

lib/
  core/
    error/
      exceptions.dart
      failures.dart
    network/
      network_info.dart
    usecases/
      usecase.dart
  features/
    authentication/
      data/
        datasources/
          auth_remote_datasource.dart
          auth_local_datasource.dart
        models/
          user_model.dart
        repositories/
          auth_repository_impl.dart
      domain/
        entities/
          user.dart
        repositories/
          auth_repository.dart
        usecases/
          login.dart
          register.dart
          logout.dart
      presentation/
        bloc/
          auth_bloc.dart
          auth_event.dart
          auth_state.dart
        pages/
          login_page.dart
          register_page.dart
        widgets/
          login_form.dart

La règle de dépendance est stricte : les couches internes ne connaissent jamais les couches externes. La couche domaine définit les interfaces de référentiel abstraites et la couche données fournit des implémentations concrètes. Cette inversion de contrôle vous permet d'échanger des sources de données sans toucher à la logique métier.

Gestion d'état : BLoC et Riverpod

Choisir la bonne solution de gestion d'état est l'une des décisions architecturales les plus importantes dans un projet Flutter.

BLoC Pattern

BLoC (Business Logic Component) utilise des flux pour gérer l'état. Les événements affluent, les états sortent. Ce flux de données unidirectionnel rend les changements d'état prévisibles et faciles à déboguer.

// Events
abstract class AuthEvent {}

class LoginRequested extends AuthEvent {
  final String email;
  final String password;
  LoginRequested({required this.email, required this.password});
}

class LogoutRequested extends AuthEvent {}

// States
abstract class AuthState {}

class AuthInitial extends AuthState {}
class AuthLoading extends AuthState {}
class AuthAuthenticated extends AuthState {
  final User user;
  AuthAuthenticated(this.user);
}
class AuthError extends AuthState {
  final String message;
  AuthError(this.message);
}

// BLoC
class AuthBloc extends Bloc<AuthEvent, AuthState> {
  final LoginUseCase loginUseCase;
  final LogoutUseCase logoutUseCase;

  AuthBloc({
    required this.loginUseCase,
    required this.logoutUseCase,
  }) : super(AuthInitial()) {
    on<LoginRequested>(_onLoginRequested);
    on<LogoutRequested>(_onLogoutRequested);
  }

  Future<void> _onLoginRequested(
    LoginRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(AuthLoading());
    final result = await loginUseCase(
      LoginParams(email: event.email, password: event.password),
    );
    result.fold(
      (failure) => emit(AuthError(failure.message)),
      (user) => emit(AuthAuthenticated(user)),
    );
  }

  Future<void> _onLogoutRequested(
    LogoutRequested event,
    Emitter<AuthState> emit,
  ) async {
    await logoutUseCase();
    emit(AuthInitial());
  }
}

Riverpod

Riverpod offre une approche plus flexible et sécurisée pour la compilation de la gestion des états. Contrairement à Provider, Riverpod ne dépend pas de l'arborescence des widgets, ce qui facilite le test et la composition.

// Define providers
final authRepositoryProvider = Provider<AuthRepository>((ref) {
  return AuthRepositoryImpl(
    remoteDatasource: ref.read(authRemoteDatasourceProvider),
    localDatasource: ref.read(authLocalDatasourceProvider),
  );
});

final authStateProvider = StateNotifierProvider<AuthNotifier, AuthState>((ref) {
  return AuthNotifier(ref.read(authRepositoryProvider));
});

class AuthNotifier extends StateNotifier<AuthState> {
  final AuthRepository _repository;

  AuthNotifier(this._repository) : super(const AuthState.initial());

  Future<void> login(String email, String password) async {
    state = const AuthState.loading();
    final result = await _repository.login(email, password);
    state = result.fold(
      (failure) => AuthState.error(failure.message),
      (user) => AuthState.authenticated(user),
    );
  }
}

// Use in widgets
class LoginPage extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final authState = ref.watch(authStateProvider);
    return authState.when(
      initial: () => LoginForm(),
      loading: () => const CircularProgressIndicator(),
      authenticated: (user) => HomePage(user: user),
      error: (message) => ErrorDisplay(message: message),
    );
  }
}

Injection de dépendances

Une injection de dépendances appropriée est essentielle pour un code testable. Le packageget_itfournit un localisateur de services simple qui fonctionne bien avec une architecture propre.

final sl = GetIt.instance;

void initDependencies() {
  // External
  sl.registerLazySingleton(() => Dio()..interceptors.add(AuthInterceptor()));
  sl.registerLazySingleton(() => InternetConnectionChecker());

  // Data sources
  sl.registerLazySingleton<AuthRemoteDatasource>(
    () => AuthRemoteDatasourceImpl(dio: sl()),
  );
  sl.registerLazySingleton<AuthLocalDatasource>(
    () => AuthLocalDatasourceImpl(secureStorage: sl()),
  );

  // Repositories
  sl.registerLazySingleton<AuthRepository>(
    () => AuthRepositoryImpl(
      remoteDatasource: sl(),
      localDatasource: sl(),
      networkInfo: sl(),
    ),
  );

  // Use cases
  sl.registerLazySingleton(() => LoginUseCase(sl()));
  sl.registerLazySingleton(() => RegisterUseCase(sl()));

  // BLoCs
  sl.registerFactory(() => AuthBloc(
    loginUseCase: sl(),
    logoutUseCase: sl(),
  ));
}

Intégration API avec Dio

Dio est le client HTTP le plus populaire pour Dart, offrant des intercepteurs, une configuration globale et une prise en charge de FormData. Structurez votre couche API avec une gestion des requêtes et des réponses de type sécurisé.

class ApiClient {
  final Dio _dio;

  ApiClient(this._dio) {
    _dio.options = BaseOptions(
      baseUrl: Environment.apiBaseUrl,
      connectTimeout: const Duration(seconds: 10),
      receiveTimeout: const Duration(seconds: 15),
      headers: {'Content-Type': 'application/json'},
    );

    _dio.interceptors.addAll([
      AuthInterceptor(),
      LogInterceptor(requestBody: true, responseBody: true),
      RetryInterceptor(dio: _dio, retries: 3),
    ]);
  }

  Future<T> get<T>(
    String path, {
    Map<String, dynamic>? queryParameters,
    required T Function(dynamic data) parser,
  }) async {
    try {
      final response = await _dio.get(path, queryParameters: queryParameters);
      return parser(response.data);
    } on DioException catch (e) {
      throw _handleError(e);
    }
  }

  AppException _handleError(DioException error) {
    switch (error.type) {
      case DioExceptionType.connectionTimeout:
      case DioExceptionType.receiveTimeout:
        return NetworkException('Connection timed out');
      case DioExceptionType.badResponse:
        return ServerException(
          error.response?.statusCode ?? 500,
          error.response?.data?['message'] ?? 'Unknown error',
        );
      default:
        return NetworkException('Network error occurred');
    }
  }
}

Stockage local avec Hive et Sqflite

La plupart des applications de production nécessitent la persistance des données locales. Choisissez le bon outil en fonction de la complexité de vos données.

Hive pour le stockage de valeurs-clés et d'objets

Hive est une base de données NoSQL légère et ultra-rapide écrite en Dart pur. Il est idéal pour la mise en cache, les préférences des utilisateurs et le stockage d'ensembles de données de petite à moyenne taille.

@HiveType(typeId: 0)
class CachedArticle extends HiveObject {
  @HiveField(0)
  final String id;

  @HiveField(1)
  final String title;

  @HiveField(2)
  final String content;

  @HiveField(3)
  final DateTime cachedAt;

  CachedArticle({
    required this.id,
    required this.title,
    required this.content,
    required this.cachedAt,
  });
}

class ArticleCacheService {
  static const _boxName = 'articles_cache';

  Future<void> cacheArticles(List<Article> articles) async {
    final box = await Hive.openBox<CachedArticle>(_boxName);
    final cached = articles.map((a) => CachedArticle(
      id: a.id,
      title: a.title,
      content: a.content,
      cachedAt: DateTime.now(),
    ));
    await box.clear();
    await box.addAll(cached);
  }

  Future<List<CachedArticle>> getCachedArticles() async {
    final box = await Hive.openBox<CachedArticle>(_boxName);
    return box.values.toList();
  }
}

Sqflite pour les données relationnelles

Lorsque vos données ont des relations complexes et que vous avez besoin de requêtes SQL, Sqflite fournit une implémentation complète de SQLite pour Flutter. Utilisez-le pour les données structurées bénéficiant de jointures, d'index et de transactions.

Notifications push

Implémentez des notifications push à l'aide de Firebase Cloud Messaging (FCM) avec une gestion appropriée des autorisations et un traitement des messages en arrière-plan.

class NotificationService {
  final FirebaseMessaging _messaging = FirebaseMessaging.instance;

  Future<void> initialize() async {
    // Request permission
    final settings = await _messaging.requestPermission(
      alert: true,
      badge: true,
      sound: true,
    );

    if (settings.authorizationStatus == AuthorizationStatus.authorized) {
      // Get FCM token
      final token = await _messaging.getToken();
      await _sendTokenToServer(token);

      // Listen for token refresh
      _messaging.onTokenRefresh.listen(_sendTokenToServer);

      // Handle foreground messages
      FirebaseMessaging.onMessage.listen(_handleForegroundMessage);

      // Handle background/terminated message taps
      FirebaseMessaging.onMessageOpenedApp.listen(_handleMessageTap);
    }
  }

  void _handleForegroundMessage(RemoteMessage message) {
    // Show local notification using flutter_local_notifications
    FlutterLocalNotificationsPlugin().show(
      message.hashCode,
      message.notification?.title,
      message.notification?.body,
      const NotificationDetails(
        android: AndroidNotificationDetails(
          'default_channel',
          'Default',
          importance: Importance.high,
        ),
      ),
    );
  }
}

Liens profonds

Les liens profonds permettent aux utilisateurs de naviguer directement vers un contenu spécifique de votre application à partir d'URL externes. Flutter prend en charge à la fois les liens profonds basés sur des URI et les liens dynamiques.

// Configure in MaterialApp
MaterialApp(
  onGenerateRoute: (settings) {
    final uri = Uri.parse(settings.name ?? '');

    if (uri.pathSegments.first == 'product') {
      final productId = uri.pathSegments[1];
      return MaterialPageRoute(
        builder: (_) => ProductDetailPage(id: productId),
      );
    }

    if (uri.pathSegments.first == 'order') {
      final orderId = uri.pathSegments[1];
      return MaterialPageRoute(
        builder: (_) => OrderTrackingPage(id: orderId),
      );
    }

    return MaterialPageRoute(builder: (_) => const HomePage());
  },
)

Pour des liens profonds plus robustes, utilisez le packagego_routerqui fournit un routage déclaratif avec prise en charge des liens profonds, des redirections et une navigation imbriquée.

CI/CD avec Codemagic et Fastlane

Les pipelines de création et de déploiement automatisés sont essentiels pour les applications de production. Codemagic fournit un service CI/CD natif Flutter, tandis que Fastlane propose une automatisation plus personnalisable.

Configuration Codemagic

# codemagic.yaml
workflows:
  production-release:
    name: Production Release
    max_build_duration: 60
    environment:
      flutter: stable
      vars:
        APP_STORE_CONNECT_KEY_ID: Encrypted(...)
        GOOGLE_PLAY_SERVICE_ACCOUNT: Encrypted(...)
    scripts:
      - name: Install dependencies
        script: flutter pub get
      - name: Run tests
        script: flutter test --coverage
      - name: Build Android
        script: flutter build appbundle --release
      - name: Build iOS
        script: |
          flutter build ipa --release \
            --export-options-plist=/path/to/ExportOptions.plist
    artifacts:
      - build/**/outputs/**/*.aab
      - build/ios/ipa/*.ipa
    publishing:
      google_play:
        credentials: $GOOGLE_PLAY_SERVICE_ACCOUNT
        track: internal
      app_store_connect:
        api_key: $APP_STORE_CONNECT_KEY_ID

Intégration Fastlane

Fastlane offre un contrôle granulaire sur le processus de création et de soumission. Définissez des voies pour les différentes étapes de publication :

# fastlane/Fastfile
platform :ios do
  desc "Deploy to TestFlight"
  lane :beta do
    build_flutter_app(target: "lib/main.dart")
    upload_to_testflight(
      skip_waiting_for_build_processing: true
    )
  end

  desc "Deploy to App Store"
  lane :release do
    build_flutter_app(target: "lib/main.dart")
    upload_to_app_store(
      submit_for_review: true,
      automatic_release: false
    )
  end
end

Profilage des performances

Les applications de production exigent des performances constantes. Flutter DevTools offre des capacités de profilage complètes.

• Suivi de la reconstruction des widgets- Utilisez la superposition de performances et les DevTools pour identifier les widgets qui se reconstruisent de manière excessive. Appliquez les constructeursconstet la gestion sélective des états pour minimiser les reconstructions.
• Rendu d'images- Surveillez la vue chronologique pour garantir le rendu des images dans un délai de 16 ms (60 ips) ou 8 ms (120 ips). Recherchez les phases coûteuses de construction, d’aménagement et de peinture.
• Profilage de la mémoire- Suivez l'allocation de mémoire pour détecter les fuites. Les coupables courants incluent les abonnements à des flux non annulés, les contrôleurs non supprimés et les références conservées dans les fermetures.
• Performances de démarrage- Différer les initialisations lourdes à l'aide deWidgetsBinding.instance.addPostFrameCallback. Utilisez le chargement différé avec les importationsdeferred aspour les fonctionnalités qui ne sont pas immédiatement nécessaires.

// Profile-mode build for accurate performance measurement
// flutter run --profile

// Add performance overlay in debug builds
MaterialApp(
  showPerformanceOverlay: true,
  // ...
)

Conclusion

La création d'applications Flutter prêtes pour la production nécessite plus que la simple connaissance du catalogue de widgets. Cela nécessite une architecture réfléchie, une gestion d’état robuste, des tests complets et des pipelines de déploiement automatisés. En adoptant une architecture propre, en investissant dans une injection de dépendances appropriée, en mettant en œuvre une gestion approfondie des erreurs et en établissant des flux de travail CI/CD, vous créez des applications qui sont non seulement fonctionnelles, mais aussi maintenables et évolutives sur le long terme.

Commencez par établir votre architecture dès le début, écrivez des tests dès le premier jour et automatisez votre pipeline de déploiement avant votre première version. Ces investissements initiaux s'accumulent au fil du temps, permettant à votre équipe de proposer des fonctionnalités plus rapidement avec moins de régressions et une plus grande confiance dans chaque version.