Flutter est framework multi-plateforme qui permet en un seul projet dʼadresser les plateformes Android, IOS, Linux, Windows et MacOs. On sʼest focalisé surun projet compatible mobile et Windows, nous vous proposons ici un retour dʼexpérience.

‍

‍Flutter et Windows, comment ça avance ?

Le 3 mars 2021, la version 2.0 de Flutter est sortie et permettait une compatibilité avec Windows. Bien que cette première version ait été très bien accueillie par la communauté, trop peu de packages supportaient cette nouvelle plateforme, ce qui ne permettait pas encore une stabilité suffisante pour une mise en production.

Depuis février 2022, le support de Windows a été annoncé comme totalement stable. Aujourdʼhui, de nombreux packages sur pub.dev offrent des interactions avec des fonctionnalités natives de Windows, ce qui permet de créer des applications Windows très intéressantes.

La prochaine avancée sur Windows pourrait être le support de plusieurs fenêtres pour l'application, une fonctionnalité qui améliorait lʼexpérience sur cette plateforme. Aucune date de sortie nʼa encore été annoncée et, malheureusement, lʼéquipe de développement de Flutter a dû mettre en pause son avancée. Suivez lʼavancement du développement sur GitHub).

‍

Fonctionnalités natives

Le framework offre une compatibilité avec de nombreuse plateformes, pour autant il est parfois nécessaire de gérer certaine plateforme une par une pour accéder aux fonctionnalités natives (l'accès aux caméras, l'utilisation duBluetooth ou l'accès aux paramètres système). De manière générale, on essaie dʼavoir un package pour une fonctionnalité, compatible avec toutes nos plateformes pour réduire les dépendances ajoutées au projet.

Dans notre cas dʼétude, l'objectif est d'avoir une compatibilité mobile etWindows. Il n'est pas encore possible de tout faire, mais des alternatives existent grâce à notre communauté très active.

‍

Caméra

Dans notre projet, une fonctionnalité permet à lʼutilisateur de prendre des photos depuis la caméra du téléphone ou du laptop. Le package image_picker est notre référence pour une implémentation mobile, mais il nʼoffre pas dʼimplémentation direct sur Windows. il est tout de même possible dʼimplémenter des interfaces, mais cela nécessite lʼutilisation dʼun deuxième package en parallèle. Dʼaprès le retour du créateur du package, cʼest une limitation technique : lʼutilisation de lʼapplication Caméra sur Windows nʼest pas possible depuis une application externe, contrairement aux applications natives sur mobile.

Une autre alternative résident dans lʼutilisation des packages camera (mobile)et camera_windows qui mettent à disposition des fonctions pour prendre des photos et accéder aux caméras. Cependant ces packages nʼoffrant pas dʼélément dʼinterface graphique, ils impliquent du développement supplémentaire pour lʼintégrer dans lʼapplication.

‍

Oauth 2.0

Un de nos objectifs prioritaires était dʼintégrer un système dʼauthentification sécurisée OAuth 2.0. La mise en place dʼun tel système permet dʼautoriser lʼutilisateur et de lʼauthentifier dans un espace unique et sécurisé (une page web prévue pour la connexion). Il est souvent utilisé sur mobile, et nʼest pas complexe à implémenter. Cependant certaines limitations techniques nous ont forcé à mettre en place une implémentation différente pour le mobile etWindows.

Le processus dʼauthentification est constitué de trois étapes principales : Lʼouverture dʼune page web dʼauthentification utilisateur
 La redirection vers lʼapplication une fois authentifié
 La récupération du token permettant dʼappeler le service API

Lʼétape de redirection vers lʼapplication a été le point noir de ce processus dʼauthentification. Cette redirection nécessite lʼutilisation des liens universels pour permettre à lʼapplication de revenir au premier plan du téléphone ou laptop.

Lʼimplémentation mobile utilise le système app_links ou uni_link. Un lien http(s)entré dans le navigateur, est reconnue par le téléphone et permet dʼouvrir lʼapplication avec des informations venant du lien. Sur Windows, lʼimplémentation est un peu différente, lʼutilisation http(s) est uniquement réservée à une utilisation navigateur, si un lien http(s) est entrée dans un navigateur, il lʼinterprète forcément comme une page à ouvrir et non un lien de redirection, ce qui ne permet pas dʼouvrir une application.

Une alternative de ‘protocoleʼ est proposée, un protocole peut être vu comme une chaine de caractère permettant dʼouvrir lʼapplication depuis un navigateur ou en ligne de commande. Par exemple ‘myappʼ ou ‘mobiappsdevʼ sont enregistrés auprès de Windows comme étant une commande qui permet de lancer lʼapplication.

Le package win32_registry apporte tous les outils pour enregistrer sonprotocole dans Windows. Par la suite, le package app_links permet àlʼapplication dʼécouter le protocole et de récupérer les informations ajoutéesdans celui-ci, lʼimplémentation donne la configuration suivante :

- mobile : https://myapp?accessToken="abc"&expireIn=3600...
- windows : myapp://accessToken="abc"&expireIn=3600...

Une dernière étape à ne pas oublier, lors de la création de lʼapplication Windows : il est nécessaire de spécifier le protocole utilisé, dans la section ci-dessous (cf. configuration YAML, la variable sera représentée par ‘protocol_activationʼ. Une fois lʼapplication envoyée sur le store Microsoft, si cette variable nʼest pas renseignée, lʼapplication ne sera pas autorisée à appeler votre protocole.

Malgré une documentation autour de cette solution pas très fournie, il a quand même été possible de rendre notre système dʼauthentification compatibles avec les plateformes.

‍

Déploiement sur le store Microsoft

La mise en production dʼune application peut être lʼune des phases les plus frustrantes pour un développeur : les erreurs de génération du build, la CI qui échoue pour un paramètre manquant, lʼapplication refusée par le store Apple mais acceptée par Google. Qu'en est-il dʼune application Windows et de son déploiement sur son store ?

Comme à son habitude, la documentation de Flutter décrit le processus.Lʼobjectif est de générer lʼapplication sous un format spécifique, le format ‘.msixʼ, qui est à ce jour le seul format quʼune application Flutter Windows est capable de générer pour être envoyée sur le Microsoft Store. Le package msix offre la possibilité de configurer son application et de générer un build (implémentation Dart du package originel MSIX.

Tout comme une application Android ou iOS, une application Windows est reconnue par un identifiant unique. La configuration de lʼapplication Windows peut être réalisée dans le fichier pubspec.yaml ou en ligne de commande :

 msix_config:
   display_name: MYAPP
   msix_version: 1.0.0.0 languages: fr-FR
   publisher_display_name: WINDOWS_COMPAGNY_NAME identity_name: WINDOWS_COMPAGNY_IDENTIFIER
   sign_msix: false # Use automatic certificate by Windows Sto publisher: WINDOWS_APP_IDENTIFIER
   protocol_activation : SCHEME
   logo_path : assets/logo.png # 1080x1080 required

Ces informations sont disponibles depuis la console du Microsoft Store et sont propres à une application. Lʼun des avantages du Microsoft Store est quʼil est capable de générer un certificat pour lʼapplication, ce qui évite à lʼéquipe de développement de se soucier de cet aspect parfois contraignant sur le storeApple.

Voici la commande pour générer le build Windows (uniquement disponible sur un appareil Windows) :

 # Avec une flavor à passer dans le build windows
flutter build windows --dart-define-from-file={ENV}.json
dart run msix:create --store true 
ou
dart run msix:build # Aucune flavor à passer dans le build wi

Conseil : Développeurs ou DevOps, accrochez-vous, l’interface du Microsoft Store est moins intuitive que celle des stores Google et Apple. Il est parfois plus compliqué de retrouver la configuration de son application ou ses groupes de testeurs…

‍

Un déploiement en test interne ou restreint à certains utilisateurs est possible. Les testeurs auront accès à l’application depuis le Microsoft Store et pourront l’installer comme un utilisateur classique. Quant à la vérification de son application, un déploiement en test interne est très rapide et ne demande pas de vérification. Pour un déploiement public, le Microsoft Store fonctionne de la même manière que les autres stores : il demande l’accès à des comptes de test si nécessaire et une description claire des fonctionnalités.

‍

En résumé ?

Depuis sa création, Flutter répond à toutes nos attentes. Il nous permet de développer des applications sur toutes les plateformes. Cependant, il est parfois nécessaire de mettre en place des solutions spécifiques à chaque plateforme dans le cas de fonctionnalités natives complexes. En dehors de ces cas spécifiques, une application compatible Windows peut être vue comme une simple case à cocher lors de la création de son projet.

Les petits plus…

Notre top trois des packages non utilisés mais fortement appréciés pour leursfonctionnalités :

fluent_ui : C’est un package de composant graphique qui reprend le visuel des applications Windows, très pratique pour utiliser le style graphique de Microsoft.
flutter_acrylic : Petit package qui permet d’implémenter un fond transparent apparu depuis Windows 11.
flutter_context_menu : Package très récent, qui permet la création de menu contextuelle, une fonctionnalité très pratique sur tout type de projet laptop.

‍

Sources externes

https://docs.flutter.dev/deployment/windows

https://learn.microsoft.com/en-us/windows/msix/app-installer/install-parameters

https://learn.microsoft.com/en-us/windows/msix/

https://partner.microsoft.com/fr-fr/

‍

Clément Marchais - Développeur Flutter

‍

Flutter & Windows - Notre retour d'expérience