Discussion :

[Papy214]

Bonjour

Quelqu'un aurait-il déjà testé ça ?

https://en.delphipraxis.net/topic/66...e-development/

Bonne année

[pprem]

Ca semblait être un produit intéressant pour du développement sans passer par FMX, mais je ne vois pas l'intérêt de payer un abonnement annuel pour ne pouvoir faire que du Android/iOS alors que je me débrouille déjà très bien avec FMX en standard et pour du desktop/mobile sur les mêmes projets.

Ils ont une version d'évaluation, ça se teste sans problème.
https://fgx-native.com/en/download.html

[Paul TOTH]

j'ai regardé le site rapidement, le produit à l'air intéressant et bien intégré dans l'IDE...l'abonnement me semble nécessaire cependant car les mobiles bougent tellement vite qu'il faut forcément un produit à jour. Petit point négatif, les sources ne sont pas disponibles, donc tu restes dépendant d'eux et de la version de Delphi.

après il faut voir la réactivité du support russo anglais, pas de français manifestement.

[pprem]

que eux proposent un abonnement est un atout pour la durée de vie du produit, c'est plus que nous ayons envie d'en payer un sur un truc comme ça alors que tout le monde critique déjà le prix de Delphi à chaque mise à jour pour un truc mobile, mais l'approche "que du natif sans s'encombrer avec le desktop et l'historique de FMX/VCL" n'est pas forcément une mauvaise chose si on aime les trucs natifs des plateformes et les composants packages autour

[Papy214]

En fait, si j'ai bien compris, il n'y aurait pas besoin d'aller chercher des API des OS cibles et ça donnerait des applications plus rapides.
Et j'avoue que contrairement à beaucoup, FMX ne m'a pas vraiment convaincu dans son utilisation. Mais ça reste un avis pers. Je ne dénigre pas le produit.

[pprem]

Ca fonctionne forcément avec les SDK / API des systèmes cibles, sinon ils ne peuvent pas faire "du natif" pour les affichages mais peut-être qu'une grande partie n'est que du dessin sur l'écran comme l'avait fait Stéphane dans son application de rencontre qui a donné lieu aux composants Alcinoe

[Papy214]

Je ne connaissais pas les composants Alcinoe mais ça semble intéressant.

Pour FMX, lors de mes premiers essais pour réaliser une application IOS, il m'est arrivé de chercher une façon de faire certaines choses et de voir qu'on me proposait seulement d'utiliser directement des API de l'OS cible. Sauf que, quand on n'a aucune notion de l'utilisation de ces API, c'est pas simple du tout.

Je ferai l'essai avec fgx au moins par curiosité.
Aujourd'hui, le travail n'est plus vraiment d'actualité sauf comme passe-temps vu que l'heure de la retraite a sonné.

Merci pour vos avis

[Paul TOTH]

en fait, pour faire de l'Android natif (avec Delphi) tu as deux approches possibles

1) ne pas utiliser FMX du tout comme je le fais dans CubeMan3D
https://github.com/tothpaul/Delphi-L...ster/CubeMan3D

2) utiliser FMX et sa capacité à afficher des contrôles natifs, ce que j'ai fait pour afficher un panel OpenGL dans FMX, y compris sous Windows
https://github.com/tothpaul/Firemonk...master/GLPanel

après il faut savoir de quoi on parle, sous Android, le "natif" c'est du Java, Delphi pour Android est un compilateur "natif" ARM

quand on créer une Native Application, c'est une "fiche" Java qui invoque un code ARM...c'est exactement ce que fait FMX.
ensuite FMX a choisi au départ de dessiner lui même, via DirectX (ou Direct2D ou GDIP) sous Windows et OpenGL ailleurs (Metal sous Mac maintenant)
puis il a permis d'intégrer des composants "natif" dedans, avec les limites un peu équivalente à ce qu'on trouve dans la VCL entre GraphicControl et WinControl...les composants FMX non-natifs n'ont pas d'existence au niveau OS donc on ne peut pas mettre un composant non natif dans un natif et vis et versa.

après il est envisageable de développer en Pascal pour Android (FreePascal le permet je crois), j'ai un POC avec APKPascal
https://github.com/tothpaul/APKPascal
là on n'a plus du tout de code ARM (même si au final l'appli est recompilée par l'OS) et donc plus de JNI (passerelle entre Java et ARM)

[Anselme45]

que eux proposent un abonnement est un atout pour la durée de vie du produit, c'est plus que nous ayons envie d'en payer un sur un truc comme ça alors que tout le monde critique déjà le prix de Delphi à chaque mise à jour pour un truc mobile,

C'est exact! Déjà que les utilisateurs doivent passer à la caisse chaque année pour un abonnement Delphi qui ne sert la plupart du temps que pour avoir une nouvelle version qui gomme des bugs qui ont été laissé dans la version précédente (apparemment la notion de garantie existe quand on achète une voiture mais pas dans le cas de certains logiciels ) et qui en ajoute d'autres, je ne vois pas l'intérêt de payer un abonnement en plus pour faire de l'Android alors que que c'est principalement pour l'aspect mulit-plateforme que l'on utilise encore Delphi...

PS: Je ne suis pas sûr que tabler sur un add-on payant à Delphi (qui doit déjà faire face à de très nombreux concurrents sur le marché de l'outil de développement... Et il n'est de loin pas dans les sucess story du moment) soit vraiment une politique gagnante...