Le framework FireMonkey est une nouvelle fois mis en avant. Si la version 10.2.3 Tokyo introduisait les modèles UI afin de faciliter la création d’interfaces personnalisées de qualité, la version 10.3 baptisée Carnival prendra en charge le Z-Order et une série de composants natifs d’Android. Il deviendra donc possible de faire cohabiter sur la même fiche des contrôles stylés de FireMonkey et des contrôles natifs sans craindre de désagréables défauts d’affichage. De plus, au niveau des API, Android 8.0 devrait avec cette nouvelle version faire partie de la panoplie du programmeur Delphi. Contrairement à l’habitude qui veut qu’ils attendent la sortie définitive du nouveau produit, les testeurs pourront même déployer leurs productions sur le Google Play Store dès la phase de test.
Petite déception cependant pour les développeurs Apple : la prise en charge de macOS en 64 bits est reportée de quelques mois. Officiellement, il s’agit de porter les efforts sur la qualité et la stabilité du produit (ce qui n’est pas une mauvaise chose!). Comme Apple refuse sur son App Store les produits en 32 bits, il est suggéré aux développeurs de passer par leurs propres outils de diffusion, ce pis-aller pouvant laisser quelque peu perplexe. Cependant, la politique d’Apple est sans doute à l’origine du retard : il est ainsi expliqué que l’annonce, il y a quelques mois, de l’abandon d’OpenGL au bénéfice de Metal 2 exige à terme des efforts importants de réécriture du code.
Pour ce qui est des applications Windows, l’effort portera sur le contrôle du statut des applications placées sur le Windows Store (par exemple, pour le contrôle de l’achat ou le paiement d’extensions) et une amélioration de la prise en charge du High-DPI et des moniteurs 4K. Les problèmes rencontrés avec les moniteurs multiples devraient aussi trouver leur solution. On notera l’introduction d’un composant de liste d’images en multi-résolutions équivalent à celui présent FireMonkey, permettant ainsi le choix d’images en fonction de la résolution en cours.
Les changements qui ont trait au cœur du langage sont évidemment les plus difficiles à mettre en œuvre du fait des conséquences qu’ils peuvent avoir sur la stabilité de l’ensemble du système. Ainsi, les adeptes des types nullables devront patienter encore un peu. En revanche, les enregistrements auront un constructeur sans paramètre par défaut, un destructeur ainsi qu’un opérateur de copie, les rapprochant ainsi des structures telles que les classes.
Enfin, la RTL est continuellement repensée pour travailler de manière plus rapide et plus efficace. En lien avec RAD Server, le traitement des chaînes, du JSON et de la classe TStringBuilder devrait être amélioré. Pour les services JSON et HTTP, il est prévu une prise en charge exhaustive des standards et des protocoles.
En dehors de quelques menus retards, Embarcadero semble avoir renoué depuis deux ans avec une feuille de route réaliste. Les utilisateurs de Delphi ne peuvent que se réjouir de l’effort continu de stabilisation du code, même si chacun sait que des progrès restent à faire dans ce domaine. Quant aux améliorations annoncées, l’expérience montrera dans quelle mesure elles répondront à cette exigence professée de qualité.
Source : Embarcadero
Que pensez-vous des annonces de cette feuille de route ?
Pensez-vous migrer vers cette nouvelle version lorsqu’elle sera publique ?