Étiquette : multiplateforme

  • Debuter avec Flutter pour Android et iOS

    Debuter avec Flutter pour Android et iOS

    Je suis venu a Flutter apres des annees a maintenir des bases de code Android et iOS separees qui divergeaient peu importe la discipline de l equipe. Un seul framework, un seul langage, deux stores. Cette promesse paraissait trop belle, alors j ai livre une vraie application avec avant de decider. Ca a tenu. Voici comment je lance un projet et ce que j aurais aime savoir des le premier jour.

    Installer la chaine d outils

    L installation est plus lourde qu on ne l avoue. Il faut le SDK Flutter, mais aussi une installation complete d Android Studio pour le SDK Android et un emulateur, et sur un Mac il faut Xcode plus les outils en ligne de commande pour iOS. Si vous sautez l un d eux, vous n avez que la moitie de la plateforme. Apres l installation, lancez la commande doctor et corrigez chaque avertissement avant d ecrire une ligne de code.

    flutter doctor -v
    flutter create my_app
    cd my_app
    flutter run -d all

    La commande doctor est la chose la plus utile du SDK. Elle verifie vos licences Android, votre configuration Xcode, votre version de CocoaPods, et si un appareil est connecte. Je la lance des que quelque chose se comporte bizarrement, car neuf fois sur dix le probleme est environnemental plutot que dans mon code.

    Comprendre l arbre de widgets

    Tout dans Flutter est un widget. Le padding est un widget. L alignement est un widget. Cela parait absurde la premiere semaine puis ca s eclaire. Au lieu de regler des proprietes sur une vue, vous enveloppez des widgets dans d autres widgets, et l imbrication decrit votre mise en page. Le framework reconstruit des parties de l arbre quand l etat change, et c est rapide car il compare a l arbre precedent plutot que de toucher directement aux vues natives.

    import 'package:flutter/material.dart';
    
    void main() => runApp(const MyApp());
    
    class MyApp extends StatelessWidget {
      const MyApp({super.key});
    
      @override
      Widget build(BuildContext context) {
        return MaterialApp(
          home: Scaffold(
            appBar: AppBar(title: const Text('Hello')),
            body: const Center(child: Text('Tourne sur les deux plateformes')),
          ),
        );
      }
    }

    StatelessWidget sert aux elements qui ne changent jamais apres leur construction. Des que vous avez besoin d un compteur, d un interrupteur ou d une valeur qui se met a jour, vous passez a StatefulWidget ou a une vraie solution d etat. J en parle en detail dans mon article sur la gestion d etat Flutter, car choisir la bonne approche tot evite un refactor penible plus tard.

    Le hot reload change la facon de travailler

    Le hot reload est la fonctionnalite qui m a convaincu. Vous sauvegardez un fichier et l application en cours se met a jour en moins d une seconde tout en gardant son etat. Ajuster une couleur, modifier un padding, corriger un bug de mise en page devient une boucle serree sans reconstruction. Il y a une difference entre le hot reload, qui preserve l etat, et le hot restart, qui jette l etat et relance depuis zero. Quand l interface parait fausse apres un reload, un hot restart la remet souvent en ordre.

    • Hot reload: garde l etat, injecte le code modifie, quasi instantane
    • Hot restart: reinitialise l etat, plus lent, necessaire apres un changement de code de haut niveau
    • Reconstruction complete: necessaire apres un changement de config native ou l ajout de plugins

    Gerer les deux plateformes honnetement

    Une seule base de code ne veut pas dire que vous pouvez ignorer les plateformes. Les utilisateurs iOS attendent un glissement de retour et une certaine sensation au defilement. Les utilisateurs Android attendent les ondulations material et un bouton retour materiel. Flutter vous donne les deux langages de design, Material et Cupertino, et vous pouvez brancher selon la plateforme quand c est utile. Je garde ce branchement petit et centralise pour qu il ne s eparpille pas dans toute l application.

    import 'dart:io' show Platform;
    import 'package:flutter/material.dart';
    
    Widget adaptiveSpinner() {
      if (Platform.isIOS) {
        return const CupertinoActivityIndicator();
      }
      return const CircularProgressIndicator();
    }

    La structure de projet que j adopte

    Le modele par defaut met tout dans un seul fichier. C est bien pour une demo et terrible pour une application a maintenir. Je decoupe le code en dossiers par fonctionnalite plutot que par type, ainsi une fonctionnalite possede ses ecrans, ses modeles et sa logique au meme endroit. Cela paie le jour ou vous supprimez une fonctionnalite et voulez qu elle disparaisse proprement.

    Une fois la structure en place, les sujets suivants sont la facon dont l application parle aux API natives et comment elle reste fluide sous charge. Je creuse les ponts natifs dans les canaux de plateforme Flutter, et le maintien de temps de trame bas dans l optimisation des performances Flutter. Posez d abord de bonnes fondations, puis ajoutez ces sujets par dessus.

    Quoi construire en premier

    Ne commencez pas par l application de vos reves. Construisez quelque chose de petit qui touche un appel reseau, une liste, un ecran de detail et un stockage local. Cela couvre la plupart de ce dont une vraie application a besoin et expose les asperites de votre configuration tant que les enjeux sont faibles. Quand vous l aurez fait deux fois, le framework cesse de vous combattre et commence a disparaitre en arriere plan, exactement la ou un bon outil doit etre.