Discussion :

[pepito62]

Bonjour,

J'ai été amené à développer avec FMX Mobile en Delphi et en C++ Builder v10.1 update 2 et j'ai constaté de nombreux "défauts". Des cas basiques non géré dans FireMonkey, plus de 6 ans après la sortie de FMX.

Voici les soucis constatés :

1- Simulateur ios non présent sur C++ Builder

2- Les caractères Arabes sont mal géré dans le composant TEdit

3- Lorsqu'on clique sur un contrôle (TEdit) qui se trouve en bas de l'écran, le composant TEdit est caché par le clavier :
De base, FireMonkey devrait remonter l'écran pour visualiser la saisie dans le composant

4- Lorsqu'on scroll dans un TListBox / TVertScrollBox avec des TEdit et que le point de départ se situe sur un composant TEdit, alors le composant TEdit obtient le focus et ouvre le clavier
De base, FireMonkey devrait faire la différence entre un défilement et une saisie.

5- On ne peut pas ajouter ou supprimer des composants visuels dans les vues spécifiques : iPad, iPhone, Android / Windows...

6- On ne peut pas gérer de vues spécifiques dans les TFrames


Je n'ai pas trouvé de solution PROPRE à tous ces défauts, c'est dommage...


J'ai également testé C++ QT et je n'ai pas rencontré ces défauts.


Avez-vous des solutions propres et fiables pour gérer les points 3 et 4 ?

[Coudrak]

Je suis bien d'accord.

1 -> bah je conseille d'oublier aussi bien le simulateur Android que iOS pour tester, c'est lent, et ne donne pas de toute façon pas les mêmes problèmes que lorsque l'on branche un vrai mobile, donc mieux vaut ne pas perdre de temps avec les simulateurs...

2 -> pas essayé mais il faudrait essayer d'installer un autre composant (de TMS, DPF Delphi iOS Native Component ou autre...)

3 -> complètement d'accord. Ils donnent une façon de bidouiller dans un exemple, mais ça devrait être implémenté par défaut, car tout le monde tombe forcément sur ce problème.
Je me suis basé sur leur exemple ScrollableForm qui demande de mettre dessous une TVertScrollBox.

4 -> complètement d'accord aussi. J'ai eu ce problème dans mes TVertScrollBox : TComboBox qui s'ouvrent alors que l'on veut juste défiler, etc. J'ai dû passer un temps fou pour coder un contournement.
Je mets HitTest à False pour les controls, avec OnMouseDown sur la form je garde la position XY et le control de dessous s'il y en a un à cet endroit, puis sur le OnMouseUp, je mets le focus sur le control (ou l'ouvre selon son type).

5 6 -> je n'ai pas essayé de vues spécifiques, je garde le même look natif pour tout pour pas m'embêter, je trouve qu'avoir plusieurs vues va à l'encontre de l'idée d'1 seul code pour toutes les plateformes et je me base sur les guidelines Apple même pour l'interface Android car ils sont plus select et précis, donc si on est accepté sur l'App Store, c'est bon aussi pour Android, ce qui n'est pas vrai dans le cas inverse...

[Paul TOTH]

5- On ne peut pas ajouter ou supprimer des composants visuels dans les vues spécifiques : iPad, iPhone, Android / Windows...

c'est normal, les vues permettent uniquement de modifier les propriétés des composants existants...ce qui assez logique puisqu'on a un seul TForm associé, on peut difficilement imager que le member Button1 soit instancié dans un environnement et pas dans un autre.

il est par contre tout à fait possible de les rendre invisibles.

[pepito62]

Je suis bien d'accord.

1 -> bah je conseille d'oublier aussi bien le simulateur Android que iOS pour tester, c'est lent, et ne donne pas de toute façon pas les mêmes problèmes que lorsque l'on branche un vrai mobile, donc mieux vaut ne pas perdre de temps avec les simulateurs...

2 -> pas essayé mais il faudrait essayer d'installer un autre composant (de TMS, DPF Delphi iOS Native Component ou autre...)

3 -> complètement d'accord. Ils donnent une façon de bidouiller dans un exemple, mais ça devrait être implémenté par défaut, car tout le monde tombe forcément sur ce problème.
Je me suis basé sur leur exemple ScrollableForm qui demande de mettre dessous une TVertScrollBox.

4 -> complètement d'accord aussi. J'ai eu ce problème dans mes TVertScrollBox : TComboBox qui s'ouvrent alors que l'on veut juste défiler, etc. J'ai dû passer un temps fou pour coder un contournement.
Je mets HitTest à False pour les controls, avec OnMouseDown sur la form je garde la position XY et le control de dessous s'il y en a un à cet endroit, puis sur le OnMouseUp, je mets le focus sur le control (ou l'ouvre selon son type).

5 6 -> je n'ai pas essayé de vues spécifiques, je garde le même look natif pour tout pour pas m'embêter, je trouve qu'avoir plusieurs vues va à l'encontre de l'idée d'1 seul code pour toutes les plateformes et je me base sur les guidelines Apple même pour l'interface Android car ils sont plus select et précis, donc si on est accepté sur l'App Store, c'est bon aussi pour Android, ce qui n'est pas vrai dans le cas inverse...

1- Difficile de donner un device pour tester à 40 développeurs.

2-Malheureusement

3/4-Effectivement, mais ce n'est pas très propre et une solution devrait être natif au framework FireMonkey : mais que fait Embarcadero, ça fait plus de 6 ans que ça existe !

5/6-Les écrans sont parfois plus light sur mobile et donc parfois un composant est remplacé par un autre voir supprimé. On peut certes le rendre invisible mais il est quand même alloué en mémoire


=> Autre point, je trouve que les performances peuvent être dégradé. Pas très fluide notamment sur un iPad mini

[skywaukers]

Bonjour,

5/6-Les écrans sont parfois plus light sur mobile et donc parfois un composant est remplacé par un autre voir supprimé. On peut certes le rendre invisible mais il est quand même alloué en mémoire


=> Autre point, je trouve que les performances peuvent être dégradé. Pas très fluide notamment sur un iPad mini

Si je peux me permettre, je pense que l'approche n'est pas tout à fait la bonne. Si tu as deux vues avec des composants différents, alors il ne me semble pas judicieux d'utiliser le multi-view. Ce dernier (à mon avis) est utile pour disposer différemment les composants, pour les redimensionner, pour utiliser des composants qui savent s'adapter à la plate-forme. Mais comment peux-tu avec un même code gérer des composants différents selon la cible ? ça va vite devenir une usine à Gaz qui va exploser si les composants non affichables ne sont pas créés. En effet, si tu les a posé sur une vue c'est que logiquement tu t'en sert et que par conséquent il y a de fortes chances qu'ils soient référencés quelque part dans ton code, ils ont donc besoin d'exister. Alors tu peux remplir ton unité de pleins de tests de plateforme pour utiliser tel ou tel composant adéquat, mais ça va vite devenir impossible à maintenir, et le gain de l'unité unique n'y sera plus. Autant alors utiliser une unité spécifique pour la plate-forme (ou les plate-formes) qui t'impose(nt) des choix de composants différents.
Dans ce cas je pense qu'il ne serait pas aberrant d'avoir 2 multi-views : une pour les desktop (PC/MAC) et une autre pour les mobiles (IOS/Android). En mutualisant un maximum de choses en dehors de l'unité de la vue le travail ne sera pas alourdi (je dirai même qu'il devrait être allégé dans le cas où il y aurait de grosses différence de composants).

@++
Dany