Interopérabilité améliorée, mise en réseau spécifique à la plate-forme, amélioration de l'inférence de type et mise à jour importante de notre feuille de route du langage de sécurité nul

Dart 2.18 est disponible aujourd'hui. Cette version présente un aperçu de l'interopérabilité Objective-C et Swift et un nouveau package de mise en réseau iOS/macOS construit au-dessus de cette interopérabilité. Il contient également une inférence de type améliorée pour les fonctions génériques, des améliorations des performances du code asynchrone, de nouvelles fonctionnalités pub.dev et le nettoyage de nos outils et bibliothèques principales.

Enfin, nous avons les derniers numéros de statut de migration de sécurité nulle et une mise à jour importante de la feuille de route sur notre chemin vers un Dart entièrement sûr. Merci de lire jusqu'au bout !

Présentation de Dart avec Objective-C et Swift Interop

Nous avons prévisualisé l'interface de fonction étrangère Dart (FFI) pour appeler les API C natives en 2020 et l'avons publiée dans Dart 2.12 en mars 2021. Depuis cette version, une large sélection de packages a profité de cette fonctionnalité pour s'intégrer aux API C natives existantes. Quelques exemples incluent file_picker, printing, win32, objectbox, realm, isar, tflite_flutteret dbus.

L'équipe Dart souhaite que Dart prenne en charge l'interopérabilité avec toutes les langues principales sur les plates-formes sur lesquelles Dart s'exécute. Dart 2.18 atteint la prochaine étape vers cet objectif. Votre code Dart peut appeler le code Objective-C et Swift, généralement utilisé pour les API sur les plates-formes macOS et iOS. Dart prend en charge ce mécanisme d'interopérabilité dans n'importe quelle application, de l'application CLI au code backend vers une interface utilisateur Flutter.

Ce nouveau mécanisme utilise le fait que le code Objective-C et Swift peut être exposé en tant que code C basé sur des liaisons d'API. L'outil de génération d'encapsuleur d'API Dart, ffigen, peut créer ces liaisons à partir des en-têtes d'API. Prenons un exemple.

Exemple de fuseau horaire avec Objective-C

macOS dispose d'une API pour interroger les informations sur les fuseaux horaires exposées sur la NSTimeZoneclasse . Vous pouvez interroger cette API pour le fuseau horaire et le décalage de fuseau horaire UTC que l'utilisateur a configuré pour son appareil.

L'exemple d'application Objective-C suivant utilise cette API de fuseau horaire pour obtenir le fuseau horaire du système et le décalage GMT :

L'application importe Foundation.h, qui contient les en-têtes d'API pour la bibliothèque Apple Foundation. Ensuite, à l'intérieur de la mainméthode, il appelle la systemTimeZoneméthode de la NSTimeZoneclasse. Cette méthode renvoie une NSTimeZoneinstance avec le fuseau horaire sélectionné sur l'appareil. Enfin, l'application affiche deux lignes sur la console contenant le nom du fuseau horaire et le décalage UTC en heures.

Si vous exécutez cette application, elle devrait renvoyer quelque chose ressemblant à ce qui suit, selon votre emplacement :

Timezone name: Europe/Copenhagen
Timezone offset GMT: 2 hours

Reproduisons ce résultat avec Dart en utilisant la nouvelle interopérabilité Objective-C.

Créez d'abord une nouvelle application Dart CLI :

$ dart create timezones

Cela sélectionne les liaisons Objective-C pour les en-têtes NSTimeZone.het inclut uniquement les API dans l' NSTimeZoneinterface. Pour générer les wrappers, exécutez ffigen:

$ dart run ffigen

C'est ça! Ce nouveau support est disponible dans un état expérimental à partir de Dart 2.18 d'aujourd'hui. Cela renforce la prise en charge générale de l'interopérabilité de Dart pour appeler directement les API macOS et iOS. Ceci, à son tour, complète les plugins de Flutter, avec un nouveau support qui fonctionne dans n'importe quelle application Dart, et qui vous permet d'appeler les API macOS et iOS directement à partir du code Dart.

Vos commentaires sont les bienvenus. Faites-nous savoir ce qui a fonctionné, ce qui pourrait être changé ou les problèmes que vous avez rencontrés en commentant dans le problème de commentaires sur GitHub. Pour en savoir plus sur cette interopérabilité, consultez le guide d'interopérabilité Objective-C et Swift .

Bibliothèques http spécifiques à la plate-forme

Dart comprend une bibliothèque générale multiplateforme http. Cette bibliothèque vous permet d'écrire du code sans vous soucier des spécificités de la plate-forme. À l'occasion, vous souhaiterez peut-être écrire du code spécifique aux API réseau d'une plate-forme hôte particulière.

Par exemple, la bibliothèque réseau d'Apple NSURLSessionpermet de spécifier un réseau Wi-Fi uniquement ou qu'il nécessite un VPN. Pour prendre en charge ces cas d'utilisation, nous avons créé un nouveau package de mise en réseau destiné aux plates-formes macOS et iOS, cupertino_http. Cela s'appuie sur la nouvelle interopérabilité Objective-C mentionnée dans la section précédente. Il utilise un grand nombre d'encapsuleurs d'API générés à partir des API réseau d'Apple dans Foundation.

Exemple de bibliothèque http Cupertino

L'exemple suivant définit le client http d'une application Flutter pour utiliser la cupertino_httpbibliothèque sur macOS et iOS et la bibliothèque http habituelle de Dart sur dart:iod'autres plates-formes :

Après cette configuration initiale, l'application effectue tous les appels réseau ultérieurs sur le client spécifique. Par exemple, une get()requête http ressemble maintenant à ceci :

Lorsque vous ne pouvez pas utiliser l'interface client commune, vous pouvez appeler les API réseau d'Apple directement à l'aide de la cupertino_httpbibliothèque :

Mise en réseau spécifique à la plate-forme dans les applications multiplateformes

Lors de la conception de cette fonctionnalité, l'objectif restait de garder les applications aussi multiplateformes que possible. Pour atteindre cet objectif, nous avons conservé notre ensemble d'API multiplateforme général httppour les opérations http de base et autorisé la configuration par plate-forme de la bibliothèque réseau à utiliser. Vous pouvez réduire la quantité de code spécifique à la plateforme que vous devez écrire à l'aide de l' package:httpAPI client . Cette API peut être configurée par plate-forme mais utilisée de manière indépendante de la plate-forme.

Dart 2.18 offre une prise en charge expérimentale de deux bibliothèques http spécifiques à la plate-forme qui prennent en charge l' package:http API client :

• cupertino_httpbasé sur NSURLSessionpour macOS/iOS.
• cronet_httpbasé sur Cronet , la bibliothèque de mise en réseau populaire sur Android.

Inférence de type améliorée

Dart utilise de nombreuses fonctions génériques. Considérez la foldméthode, qui réduit une collection d'éléments à une seule valeur. L'exemple suivant calcule la somme d'une liste d'entiers :

List<int> numbers = [1, 2, 3];
final sum = numbers.fold(0, (x, y) => x + y);
print(‘The sum of $numbers is $sum’);

line 2 • The operator ‘+’ can’t be unconditionally invoked because the receiver can be ‘null’.

final sum = numbers.fold(0, (int x, int y) => x + y);

Améliorations des performances asynchrones

Cette version de Dart améliore la façon dont la machine virtuelle Dart applique la asyncméthode et les fonctions du générateur async*/ sync*. Cela réduit la taille du code. Sur deux grandes applications Google internes, nous avons constaté une réduction de la taille de l'instantané AOT d'environ 10 %. Nous avons également constaté une augmentation des performances dans nos microbenchmarks.

Ces modifications incluent de petits changements de comportement supplémentaires ; pour en savoir plus, consultez le changelog .

améliorations de pub.dev

Parallèlement à la version 2.18, nous avons apporté deux modifications au pub.devréférentiel de packages.

Les particuliers maintiennent souvent des packages publiés sur pub.devpendant leur temps libre. Cela peut être coûteux, tant en termes de temps que de finances. Pour faciliter les parrainages, nous prenons désormais en charge une nouvelle fundingbalise dans le pubspec, qui peut être utilisée par les éditeurs de packages pour répertorier les liens vers une ou plusieurs façons de parrainer le package. Ces liens sont ensuite affichés pub.devdans la barre latérale :

Pour en savoir plus, consultez la pubspecdocumentation .

De plus, nous aimerions encourager un riche écosystème de packages open source. Pour souligner cela, la notation automatisée des packages sur pub.devattribue 10 points supplémentaires aux packages qui utilisent une licence approuvée par l'OSI .

Quelques changements de rupture

Dart met l'accent sur la simplicité et l'apprentissage. Nous essayons constamment de maintenir un équilibre prudent lors de l'ajout de nouvelles fonctionnalités. Une méthode pour garder les choses simples consiste à supprimer les fonctionnalités et les API historiques avec peu d'utilisation ou de meilleurs remplacements. Dart 2.18 nettoie les éléments de cette catégorie, y compris quelques modifications mineures :

• Nous avons ajouté l' dartoutil de développement CLI unifié en octobre 2020. Dans la version 2.18, nous avons terminé la transition. Cette version supprime les deux derniers outils obsolètes dart2js(use dart compile js) et dartanalyzer(use dart analyze).
• Avec l'introduction de la gestion des versions de langue, pubgénère un nouveau fichier de résolution : .dart_tool/package_config.json.le fichier précédent, .packages, utilisait un format qui ne pouvait pas contenir de versions. Nous avons cessé d'utiliser le .packagesfichier. Si vous avez des .packagesfichiers, vous pouvez les supprimer.
• Les mixins de classes qui ne s'étendent pas Objectne peuvent pas être utilisés (changement cassant #48167 ). Ce comportement n'a jamais été voulu.
• La uripropriété de dart:io's RedirectExceptiona été changée en nullable (changement cassant #49045 ).
• Les constantes dans dart:ioles API de mise en réseau suivant la convention SCREAMING_SNAKE ont été supprimées (modification avec rupture #34218 ; précédemment obsolète). Utilisez plutôt les constantes lowerCamelCase correspondantes.
• La machine virtuelle Dart ne restaure plus les paramètres initiaux du terminal à la sortie. Programmes qui modifient les Stdinparamètres lineModeet echoModesont désormais responsables de la restauration des paramètres à la sortie du programme (changement avec rupture #45630 ).

Nous sommes très heureux de voir la large utilisation de la sécurité nulle depuis sa version bêta en novembre 2020 et la version Dart 2.12 en mars 2021.

Tout d'abord, les développeurs d'applications de la plupart des packages populaires ont pub.devmigré vers la sécurité nulle. L'analyse montre que 100 % des 250 premiers et 98 % des 1 000 premiers packages les plus utilisés prennent en charge la sécurité nulle.

Deuxièmement, la plupart des développeurs d'applications travaillent dans des bases de code avec une migration de sécurité nulle complète. C'est crucial. La sécurité nulle complète de Dart ne s'active pas tant que vous n'avez pas migré tout le code et toutes les dépendances (y compris transitives). Nous suivons cela via la télémétrie à partir flutter rundes commandes.

Le graphique suivant montre les exécutions de sécurité nulles non saines et saines de flutter run. Avant l'introduction de la sécurité nulle, il n'y en avait aucune. Une croissance rapide de la sécurité nulle malsaine a suivi. Lorsque les applications ont commencé à migrer vers la sécurité nulle, les développeurs ont effectué une migration partielle. Certaines parties devaient encore être migrées. Au fil du temps, nous constatons une croissance très saine des sessions de sécurité nulles. À la fin du mois dernier, il y avait quatre fois plus de sessions de sécurité nulles saines que de sessions non saines. Nous espérons qu'au cours des prochains trimestres, nous verrons la sécurité nulle sonore approcher à 100 % !

Une mise à jour importante de la feuille de route de sécurité null

La prise en charge à la fois de la sécurité nulle non saine et saine ajoute des frais généraux et de la complexité.

Tout d'abord, les développeurs Dart doivent apprendre et comprendre les deux modes. Chaque fois que vous lisez un morceau de code Dart, vérifiez la version du langage pour voir si les types sont non nuls par défaut (Dart 2.12 et versions ultérieures) ou nullables par défaut (Dart 2.11 et versions antérieures).

Deuxièmement, la prise en charge des deux modes dans nos compilateurs et nos runtimes ralentit l'évolution du SDK Dart pour prendre en charge de nouvelles fonctionnalités.

Sur la base de la surcharge de la sécurité nulle instable et des chiffres d'adoption très positifs mentionnés dans la section précédente, notre objectif est de passer à la prise en charge uniquement de la sécurité nulle saine et d'interrompre les modes de sécurité non nulle et de sécurité nulle insalubre. Nous avons provisoirement prévu sa sortie d'ici la mi-2023.

Cela signifierait que l'arrêt de la prise en charge de Dart 2.11 et versions antérieures. Les fichiers Pubspec avec une contrainte SDK ayant une limite inférieure inférieure à 2,12 ne seraient plus résolus dans Dart 3 et versions ultérieures. Dans le code source contenant des marqueurs de langue, ceux-ci échoueraient s'ils étaient définis sur moins de 2,12 (comme // @dart=2.9).

Si vous avez migré vers la sécurité null sonore, votre code fonctionnera avec une sécurité null complète dans Dart 3. Si ce n'est pas le cas, veuillez migrer maintenant ! Pour en savoir plus sur ces changements, consultez ce problème GitHub .

Résumé

La nouvelle prise en charge de l'interopérabilité, de la mise en réseau, de l'inférence de type et pub.devest disponible aujourd'hui. Pour commencer, vous pouvez directement télécharger la version 2.18 de Dart ou l'intégrer dans la version actuelle du SDK Flutter 3.3 .