Ceci est un retour d’expérience que j’aurais aimé trouver lorsque j’ai été amené, en 2017, à choisir un nouvel outil de développement. Il s’agit ici de raconter et aussi donner mon impression subjective dans l’utilisation de Delphi et FireMonkey.
Le projet
Redévelopper une application typiquement Desktop en Delphi, pour Windows, OSX (Mac), Android et IPad (IOS). Le déploiement se fera au travers des Stores.
Qui suis-je ?
Je développe depuis que j’ai 18 ans (Z80, Commodore64, Apple2, les premiers Mac) et j’en ai 58. Je connais très bien VB (depuis la version 2 jusqu’à la version 6), Java, puis moins bien (mais quand même…) le C (couches de comm temps réel avec dialogue Unix, Windows), C++, php, mysql, SQL, HTML, JavaScript (un peu), ACCESS et enfin vaguement DotNet C#.
Bref je suis loin d’être un débutant.
L’application
Elle n’est pas hyper complexe mais comporte beaucoup d’écrans modaux. La version actuelle que je redéveloppe sous Delphi a nécessité deux ans pleins de développement sous VB6. La précédente avait pris plus d’un an, mais était moins sophistiquée.
Elle n’utilise pas de base de données (c’est important), mais elle dessine beaucoup à l’écran, en print et pdf (natif).
Elle dialogue avec le serveur (Apache , php, MySql) sous forme d’appel https sur du php, qui lui gère la base de données. Les accès Internet sont fréquents, mais elle doit pouvoir fonctionner hors-connexion.
Comme c’est une application Desktop, elle a beaucoup recours à des boîtes de dialogues.
Elle se paramètre dans ses droits et habilitations en temps réel, suivant les dialogues avec le serveur.
Le contexte
Comme je suis un peu feignant, j’ai décidé de m’adjoindre le support d’un MVP Delphi (très talentueux et constructif). Je lui dis ce que je veux, nous discutons d’une stratégie argumentée, et avec lui je développe (dans un premier temps) dans le projet d’être 100% autonome.
Quand il y a des bugs, je lui donne les sources et il cherche. Parfois je lui sous-traite des modules.
C’est donc une configuration de succès idéale.
Le projet à la base est de coder sous Windows, et de lancer sur les autres plateformes directement. Cela fonctionne bien dans 95% des cas, une fois les bonnes stratégies adoptées …
La gageure
Les environnements tablette ne sont pas prévus pour avoir des fenêtres modales, et encore moins du code qui stoppe son exécution lors de l’affichage d’une boîte de dialogue.
En revanche, l’application nécessite de manière impérieuse d’avoir des boîtes de dialogue (pour de multiples excellentes raisons que je ne développerai pas ici, et qui ne sont pas informatiques, mais marketing).
La gageure est alors de re-fabriquer de façon totalement artificielle le système modal sur des systèmes qui sont conçus pour être définitivement asynchrones, tels que JavaScript.
L’expérience
L’apprentissage du langage
Delphi est du Pascal qui à mon sens ne pose pas de pb particulier. L’orientation objet fonctionne bien. Le debuggage sous Windows ne pose pas de pb particulier (sous les autres OS, c’est plus sioux, voire peu opérationnel). Le compilateur Windows est très rapide (Proc I7, 8 threads à 2.5 Hgz, 16Go de ram, SSD 1 T). RAS.
J’ai trouvé Delphi confortable comme langage.
FireMonkey est un FrameWork (qui remplace la VCL) crossplatform qui fournit les contrôles et la Frame et bien d’autres choses plus ou moins pratiques. Il a quelques curiosités de conception que l’on comprend bien du fait du caractère crossplatform de la bête. Soyons clairs : il est très loin d’être dépourvu de bugs, et c’est là une vraie difficulté.
L’aide
L’aide n’est pas très claire, mais pléthorique, donc peu aisée à utiliser. Parfois, il y a certaines propriétés/instructions qui ne bénéficient d’aucune aide, tout simplement. Le cas appelle d’être souligné car il est récurrent.
L’aide sur Internet : puisque Delphi existe depuis des lustres, il y a quantité de code sur le Net qui traîne. Bonne nouvelle ! Grossière erreur : les versions successives de Delphi ont fait que du code ancien ne fonctionne tout simplement pas sur la version actuelle (Berlin, Tokyo). Donc en fait il est assez délicat de se dépanner grâce au Net.
Méthode de développement
Pour celles et ceux qui croient que sous Delphi on développe 5 fois plus vite, dans ce cas il faut coder ( ?) en mode graphique, c’est-à-dire poser les contrôles sur les feuilles, comme on faisait en VB (au début). De même, on utilise alors les systèmes de lien des contrôles avec les champs des tables des bases de données (les exemples proposés sont effectivement très séduisants).
À l’usage, et très personnellement, j’ai laissé tomber cette stratégie, et je code tout. Je ne crois pas à cette façon de faire pour des applications lourdes et qui se redimensionnent et se re-paramètrent en temps réel. Mais ceci est un avis personnel.
Bugs
Il y en a pas mal. Surtout sur FireMonkey. Et ceux-ci sont particulièrement délicats à identifier. Certains nécessitent de revoir complétement la stratégie. Plus grave pour moi : l’aide indique certaines choses, qui ne sont pas effectives, donc fausses. J’ai été amené à redévelopper des outils de base car ceux proposés étaient buggués (par exemple des listes qui contiennent des objets : la base – ceci est dû à la gestion mémoire particulière).
Après quelques temps, on en arrive à douter systématiquement de FireMonkey, ce qui est sage et qui fait gagner du temps dans l’identification des bugs.
Gestion de la mémoire et fuites
Du fait du Crossplatform, il y a 2 systèmes de gestion mémoire :
• Le traditionnel, à la dure sous Windows (et Mac),
• Arc, pour les tablettes et téléphones (système de déchargement automatique suite à un comptage de référence, comme sur Java).
Clairement, Arc n’est pas fiable (exemple de redéveloppement d’objets de base cité plus haut, qui fonctionne bien sous Windows, pas sous IPad/Android), et parfois décharge des collections, et ainsi supprime des objets en cours d’utilisation. La stratégie consiste donc à conserver une méthode plus traditionnelle, en mode bourrin, pour gérer la mémoire et limiter les fuites.
Ceci était su, on arrive à fonctionner correctement.
Emabarcadero – Mises à jour
C’est l’éditeur de Delphi. L’ancienne équipe a été remerciée il y a bientôt deux ans. Aujourd’hui la nouvelle équipe tente de réparer les erreurs passées (et y arrive peu à peu), tout en continuant d’avancer.
Cela se traduit par 3 à 4 mises à jour par an, immanquablement suivies par des patchs et des fixs qui mettent à jour la mise à jour.
Bref : il est urgent de ne pas se presser de mettre à jour. Voire, il est recommandé d’installer sur une machine virtuelle pour tester les sources, avant de mettre à jour.
Personnellement, j’installe sur accord de mon support MVP, qui lui s’appuie tous les tests.
Ce serait à refaire
Delphi est à ma connaissance un des seuls outils à faire aussi bien du Crossplatform. Xamarin a tenté (j’avais regardé à l’époque, mais la couche Mac était seulement en cours de développement, et surtout Visual Studio était une usine à gaz très peu fiable). Malgré son côté gratuit, j’ai renoncé très vite. Je ne sais pas ce qu’il en est maintenant.
J’ai maintenant trouvé QT, qui est fort mal référencé, et plus cher que Delphi. Aujourd’hui, si je n’étais pas aussi avancé, je regarderais cette solution de très près.
Prendre un conseil MVP est pour moi une nécessité définitive : sans lui j’aurais abandonné (pourtant je ne suis pas un débutant). Disons aussi que pour lui, l’application est réellement complexe (150 fichiers sources pour l’instant, sachant qu’à la fin il y en aura probablement 300 à 500).
Je doute ? Oui, mais c’est trop tard. Donc je continue. Et finalement l’application commence à tourner très proprement et de façon opérationnelle.
Forces Freins
Les forces : FireMonkey reste en définitive une force. Le langage, quant à lui, me semble bien fait. L’environnement, malgré les critiques, est très opérationnel et fait pour cela. C’est confortable. La productivité est dans la norme, sans plus.
Les freins : pas mal de bugs sur FireMonkey, avec une équipe qui rame un peu (mais qui avance, je tiens à le souligner) pour rattraper les errances du passé.
Le code once, run anywhere est un peu une vue de l’esprit, atteinte à 95% pourtant une fois les bonnes stratégies adoptées.
Le debuggage reste souvent un problème du fait de sa lenteur, très particulièrement sur Android.
La compilation Android aussi (durée du fait des outils fournis par Google qui n’utilisent pas tous les threads disponibles, donc pas du fait de Delphi).
Il est clair aussi qu’il y a une marge de progrès très considérable pour créer des simulateurs dignes de ce nom.
En synthèse
Heureusement que je n’ai pas de Dead-line. Grâce à cela, et un bon budget pour mon conseil MVP, j’avance, avec la foi chevillée au corps (c’est utile dans les phases de découragement, régulières).
Dans tous les cas, Delphi, à par QT qui est sensiblement plus cher, n’a pas de réel concurrent à ma connaissance. Xamarin pourrait rattraper son retard à terme, mais clairement Delphi a aussi ici beaucoup d’avance dans les nombreux outils, bien intégrés, qu’il propose.
En revanche, démarrer un grosse appli orientée Desktop, de zéro et sans aide extérieure, ressemble pour moi à une stratégie à très gros risques, et surtout très coûteuse à bien des points de vue.
Hope this helps
Christian
