taraskuzio.com

Flutter 3.47, le kit de développement logiciel open source créé par Google pour le développement multiplateforme, introduit des paquets d'interface utilisateur autonomes

Flutter 3.47 est disponible. Flutter est un kit de développement logiciel open source pour interfaces utilisateur créé par Google. Il permet de développer des applications multiplateformes à partir d’une base de code unique. Flutter 3.47 propose désormais des paquets d’interface utilisateur autonomes Material et Cupertino, permettant des mises à jour indépendantes des bibliothèques de conception en dehors du SDK principal. Le moteur de rendu Impeller est activé par défaut sur macOS, Windows et Linux, remplaçant Skia pour offrir des graphismes de bureau améliorés et des animations plus fluides.

Flutter est un kit de développement logiciel open source pour interfaces utilisateur créé par Google. Il permet de développer des applications multiplateformes à partir d’une base de code unique pour le Web, Fuchsia, Android, iOS, Linux, macOS et Windows. Présenté pour la première fois en 2015, Flutter a été lancé en mai 2017. Flutter est utilisé en interne par Google dans des applications telles que Google Pay et Google Earth, ainsi que par d'autres développeurs de logiciels, notamment ByteDance et Alibaba.

Flutter intègre son propre moteur de rendu qui transmet directement les données de pixels à l’écran. Cela contraste avec de nombreux autres frameworks d’interface utilisateur qui s’appuient sur la plateforme cible pour fournir un moteur de rendu, comme les applications Android natives qui s’appuient sur le SDK Android au niveau de l’appareil ou le SDK iOS qui utilise la pile d’interface utilisateur intégrée à la plateforme cible. Le contrôle exercé par Flutter sur son pipeline de rendu simplifie la prise en charge multiplateforme, car un code d’interface utilisateur identique peut être utilisé pour toutes les plateformes cibles. L’une des fonctionnalités clés de Flutter est le « hot reload », qui permet aux développeurs de voir instantanément les modifications apportées au code sans avoir à redémarrer l’application.

Récemment, Flutter 3.47 est disponible, et propose désormais des paquets d’interface utilisateur autonomes Material et Cupertino, permettant des mises à jour indépendantes des bibliothèques de conception en dehors du SDK principal. Le moteur de rendu Impeller est activé par défaut sur macOS, Windows et Linux, remplaçant Skia pour offrir des graphismes de bureau améliorés et des animations plus fluides. Les aperçus de widgets ont atteint le stade de la version stable, ce qui rationalise le développement et les tests de l’interface utilisateur. Une prise en charge expérimentale de WebAssembly et toute une série d’améliorations spécifiques à chaque plateforme sont également incluses.

Voici la présentation des principales nouveautés de Flutter 3.47 :

Choisissez votre propre aventure UI

La première étape vers un Flutter découplé est franchie : Material et Cupertino sont désormais disponibles sous forme de paquets autonomes !

L’une des plus grandes forces de Flutter réside dans sa capacité à afficher des widgets Material et Cupertino au pixel près. Cependant, comme ces bibliothèques de design étaient historiquement intégrées directement au SDK principal, cela ralentissait leur développement et rendait plus difficile toute contribution ou mise à jour.

Bien que le SDK principal inclue toujours ces bibliothèques dans cette version, vous pouvez désormais opter pour les paquets autonomes material_ui et cupertino_ui, qui ont officiellement atteint la version 1.0 sur pub.dev.

Dissociation des feuilles de route de conception (option d’activation opt-in)

En optant pour les systèmes de conception dissociés, vous prenez le contrôle de votre feuille de route de conception. Comme material_ui et cupertino_ui sont désormais hébergés sur pub.dev, ils peuvent publier des corrections de bogues et de nouveaux composants selon leurs propres calendriers hebdomadaires, indépendamment des versions trimestrielles du SDK Flutter.

Le découplage des systèmes de design nous apporte les avantages suivants :

- Vous pouvez utiliser les derniers styles de widgets Cupertino et Material sans être obligé de mettre à jour l’intégralité de votre version du SDK Flutter.
- Nous pouvons intégrer les contributions et les mises à jour plus rapidement et plus fréquemment.
- Nous posons les bases d’un catalogue de widgets Flutter de base neutre en termes de style, ce qui facilitera la création de systèmes de conception personnalisés à l’avenir.

Comment migrer

Pour migrer votre projet vers les nouveaux paquets autonomes, exécutez la commande suivante :

dart fix --apply --code=migrate_design_widgets

Cet outil met automatiquement à jour vos importations depuis package:flutter/material.dart et package:flutter/cupertino.dart vers les nouveaux paquets autonomes.

Remarque : si l’outil de migration rencontre des problèmes lors de la mise à jour de votre fichier pubspec.yaml (un bug connu en cette phase précoce), vous pouvez y remédier en exécutant manuellement la commande flutter pub add material_ui (et cupertino_ui si vous l’utilisez), puis en relançant la commande dart fix --apply.

Les bibliothèques de design d’origine incluses dans le SDK de base devraient être officiellement dépréciées lors de la prochaine version stable d’automne, prévue en novembre. Si vous migrez un paquet au sein de l’écosystème, considérez ce passage aux paquets autonomes comme une mise à jour majeure.

Combler le fossé de la migration

Pour faciliter la transition de l’écosystème vers les nouvelles bibliothèques de conception autonomes, material_ui et cupertino_ui sont fournis avec des utilitaires de migration. Le MaterialUiCompatibilityBridge permet à votre application de migrer immédiatement vers les paquets autonomes, même si certaines des dépendances de votre paquet utilisent encore des importations héritées du SDK de base.

Par exemple, vous pouvez encapsuler votre application dans le pont de compatibilité :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import 'package:material_ui/material_ui.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
theme: ThemeData(
colorScheme: ColorScheme.fromSeed(seedColor: const Color(0xFF6750A4)),
),
builder: (BuildContext context, Widget? child) {
return MaterialUiCompatibilityBridge(child: child!);
},
home: const HomeScreen(),
);
}
}

Localisations dissociées

Dans le cadre de cette transition, flutter_localizations a également été dissocié. Les délégués de localisation et les chaînes traduites pour les widgets Material et Cupertino se trouvent désormais respectivement dans package:material_ui et package:cupertino_ui.

Avant :

1
2
3
4
5
6
7
8
9

import 'package:flutter_localizations/flutter_localizations.dart';
import 'package:flutter/material.dart';
// ...
localizationsDelegates: const <LocalizationsDelegate<dynamic>>[
GlobalCupertinoLocalizations.delegate,
GlobalMaterialLocalizations.delegate,
GlobalWidgetsLocalizations.delegate,
],

Après :

1
2
3
4

import 'package:material_ui/material_ui.dart';
// ...
localizationsDelegates: GlobalMaterialLocalizations.delegates,

Définir localizationsDelegates sur GlobalMaterialLocalizations.delegates inclut désormais également les délégués Cupertino et Widgets, ce qui simplifie votre configuration.

Ouvert aux contributions

En gelant les contributions aux bibliothèques Material et Cupertino en avril dernier, nous avons pu garantir une migration en douceur. Les bibliothèques qui vous attendent dans material_ui et cupertino_ui sont les mêmes que celles que vous utilisez déjà.

Maintenant que nous sommes prêts à lever ce gel, attendez-vous à ce que davantage de corrections et de fonctionnalités soient déployées régulièrement dans les nouveaux paquets, avec des versions actuellement prévues chaque semaine. Nous sommes également ravis d’ouvrir officiellement ces paquets aux contributions de la communauté.

Se préparer à la prochaine vague de mises à jour Apple

Avec l’arrivée prévue cet automne de Xcode 27, iOS 27 et macOS 27, nous nous sommes fortement attachés à faire en sorte que Flutter soit prêt pour les mises à jour à venir. Afin d’éviter à vos utilisateurs toute mauvaise surprise dès le premier jour, nous vous recommandons de tester dès maintenant vos applications avec les versions bêta d’Apple.

De plus, pour prendre en charge Xcode 27, les versions minimales prises en charge du système d’exploitation ont été revues à la hausse :

Obligation relative au cycle de vie UIScene

Le SDK iOS 27 impose désormais le cycle de vie UIScene pour toutes les applications basées sur UIKit. Les applications créées avec Xcode 27 qui n’adoptent pas UIScene ne pourront pas se lancer au démarrage.

Pour la plupart des applications, la CLI Flutter gère automatiquement cette migration lors de la compilation. Cependant, une migration manuelle est nécessaire si votre AppDelegate contient du code natif personnalisé ou si vous utilisez des plugins qui s’appuient encore sur l’ancien cycle de vie de l’application. Dans ces cas-là, vous devez effectuer la migration manuellement en suivant le guide d’adoption d’UIScene/Delegate.

Fin progressive de la prise en charge des Mac Intel

Conformément à la transition d’Apple vers Apple Silicon, Flutter met progressivement fin à la prise en charge des Mac équipés de processeurs Intel. Nous avons désactivé les exécutions de tests automatisés sur le matériel Intel, et la CLI Flutter affiche désormais des avertissements lors de la compilation sur des hôtes Intel ou lorsque l’application cible deux architectures. Ces avertissements deviendront des erreurs dans une prochaine version.

Vous pouvez choisir dès maintenant de compiler des applications macOS exclusivement pour ARM64 en exécutant la commande flutter config --enable-macos-arm64-only.

Progrès concernant Swift Package Manager

La communauté a réalisé des progrès incroyables dans la transition vers Swift Package Manager : 92 des 100 principaux plugins iOS ont désormais été migrés. Si vous aviez précédemment désactivé Swift Package Manager, vous pouvez l’essayer à nouveau en exécutant la commande flutter config --enable-swift-package-manager.

CocoaPods étant désormais en mode de maintenance, les plugins qui ne migrent pas vers SwiftPM cesseront à terme de fonctionner. Les plugins non migrés obtiennent également des scores pub.dev plus faibles.

Cette version propose également des temps de compilation optimisés avec des améliorations des pipelines de compilation en filtrant les schémas de paquets SwiftPM inutiles dès le début du processus de compilation.

Cap sur Wasm par défaut

Nous travaillons activement à l’activation par défaut de WebAssembly (Wasm) pour les applications web Flutter, afin d’apporter des performances proches de celles des applications natives au navigateur. Si vous n’avez pas encore testé vos applications web avec Wasm, vous pouvez l’activer dès aujourd’hui en passant l’indicateur --wasm à votre commande de compilation de version :

flutter build web --release --wasm

Alors que vous vous préparez à cette transition, gardez à l’esprit que Wasm nécessite la migration de votre base de code vers le nouveau paquet d’interopérabilité JS (package:web), car l’ancienne bibliothèque dart:html n’est plus prise en charge. La mise à jour des dépendances de paquets de votre projet résout souvent automatiquement ces problèmes d’interopérabilité hérités.

Pour faciliter la mise à l’échelle des applications web de grande envergure, cette version introduit également une...

La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.