Discussion :

[Anselme45]

Bonjour à tous,

Je dois développer une application tournant sur Android et iOS qui doit interagir avec les fonctions du smartphone (caméra, localisation GPS) et interagir avec une base de données localisée sur un serveur (donc échange de données nécessitant un transfert de données sécurisé).

Connaissant Delphi, mais n'ayant jamais abordé le développement pour appareil mobile, je suis à la recherche d'un retour d'expérience. Est-ce que quelqu'un sur ce forum peut partager son expérience? Est-ce que Delphi est une bonne solution pour développer une application sur les 2 OS? Est-ce que le même code peut tourner sur Android et iOS ou faut-il adapter le code pour fonctionner sur les 2 OS?

Merci d'avance pour tout commentaire

[Invité]

En Delphi le développement iOS et Android est réalisé avec Firemonkey, normalement ce que tu souhaites est réalisable sans problème (enfaîte si), tu va forcément devoir adapter une partie de ton code pour iOS et une pour Android. Il faut perdre les réflexes de la VCL et penser différemment mais vu que tu connais Delphi tu ne seras pas perdu.

L'avantage de cette interface RAD est la rapidité pour développer, de ce que j'ai pu essayer c'est plutôt stable (version Berlin et Tokyo).

Pour tester rapidement je le fait en compilant sous Windows, ensuite je compile sur Android et de temps en temps il faut adapter le code.
Par exemple un affichage réalisé dans le FormShow et qui fonctionnent sous Windows n'était pas bien sous Android, j'ai du le gérer dans le FormResize, etc...

Ces derniers temps l'aide Embarcadero c'est bien développé, les membres sur ce forum et sur stackoverflow.
Jusqu’à maintenant je suis jamais resté bloqué sur un problème FMX.

Pour la version iOS et il faut compiler depuis un Mac

[Anselme45]

Merci retwas pour ton avis.

Je pensais bien qu'il y aurait quelques problèmes à passer d'un OS à l'autre...

Quand tu dis que pour iOS, il faut compiler sur un Mac, comment cela se passe concrètement? Vu que tu as ton Delphi sur un poste Windows... Comment fais-tu pour compiler sur un Mac? Tu mets le Mac en réseau et tu lances un genre de commande dans une console pour lancer la compilation à distance?

[free07]

Merci retwas pour ton avis.

Je pensais bien qu'il y aurait quelques problèmes à passer d'un OS à l'autre...

Quand tu dis que pour iOS, il faut compiler sur un Mac, comment cela se passe concrètement? Vu que tu as ton Delphi sur un poste Windows... Comment fais-tu pour compiler sur un Mac? Tu mets le Mac en réseau et tu lances un genre de commande dans une console pour lancer la compilation à distance?

Bonjour,

Oui, il faut un mac qui soit connecté en réseau ou alors tu as la solution d'installer Windows dans une VM créée à partir du mac, il y a par exemple VirtualBox pour mac qui fonctionne très bien ( c'est la solution que j'utilise ). Il faut ensuite que tu installes PAServer qui fait le lien entre l'OS X du mac et Windows. C'est par ce programme que tu peux lancer d'un OS à l'autre ton programme suivant la cible sélectionné ( OSX ou iOS ).
En ce qui concerne iOS, il faut bien sur que ton iphone, ipad ou iMachin soit connecté en usb sur ton mac

Tu peux retrouver toutes les infos utiles sur le wiki

Sinon, pour te parler de mon expérience avec fmx qui est pour l'instant uniquement sur Windows, OS X et iOS, cela fonctionne très bien et comme l'a dit Retwas, c'est de mieux en mieux, c'était un peu galère avant XE 7 et depuis, je n'ai plus de mauvaise surprise.
Je n'ai pour l'instant aucune expérience pour Android mais je devrais dans les prochaines mois, porter certaines applications sur cet OS.
Il y a effectivement certaines différences entre iOS et Android, mais tu peux adapter ton code grâce aux directives de compilation et pour ma part, les quelques différences que j'ai pu rencontrer doivent se résumer à quelques dizaines de lignes de codes, ce qui est peu par rapport à l'ensemble du projet.

[delaio]

Bonjour,

je suis à la recherche d'un retour d'expérience

Anselme45 : je viens de développer ma première application android sous delphi 10.2 tokyo (adaptation IOS très prochainement). J'ai eu les mêmes interrogations que toi et je confirme que Delphi est une très bonne solution pour développer ce genre d'application.

Perso, j'ai découvert les compos firemonkey, le concepteur de style et le livebinding par la même occasion : c'est vrai que c'est un peu déroutant au début mais ça laisse d'agréables surprises (possibilité d'intégrer un composant dans un autre via la structure, possibilité de lier les champs d'un clientdataset à un listview via le livebinding sans gérer les affectations dans le code, possibilité d'agencer plusieurs données dans le même item d'un listbox via le concepteur de style...).

Un détail dont on se rend compte assez vite mais qui a, à mon sens de l'importance, Android fonctionne de manière asynchrone : par exemple, il n'attend pas le retour utilisateur tel que le clic sur un showmessage pour continuer d'avancer dans le programme. ça change un peu la manière de penser son code, comparé à windows. Un autre détail important : tout traitement long doit être intégré dans des threads (TTask et Future sont sympathiques à utiliser).

Concernant les éventuelles difficultés, la communauté delphi m'a bien aidée et jusqu'à présent, je n'ai pas rencontré de point bloquant (je touche du bois ).

[foetus]

Un détail dont on se rend compte assez vite mais qui a, à mon sens de l'importance, Android fonctionne de manière asynchrone : par exemple, il n'attend pas le retour utilisateur tel que le clic sur un showmessage pour continuer d'avancer dans le programme. ça change un peu la manière de penser son code, comparé à windows.

Windows est aussi asynchrone Tous les évènements sont mis dans une file de messages et traiter lorsque Windows a fini avec les messages arrivés plus tôt.

Par contre, il y a 2 fonctions : PostMessage et SendMessage : 1 des 2 bloque tant que Windows n'a pas fini de traiter le message et donné le retour

Un autre détail important : tout traitement long doit être intégré dans des threads (TTask et Future sont sympathiques à utiliser)

Windows tout également. iOS si je ne dis pas de bêtises aussi

Les applications ont toujours un thread principal (fil d'exécution) qui est consacré aux traitements des messages, de l'interaction avec le système d'exploitation en dessous et de l'affichage.
Si le développeur surcharge ce thread principal, l'application fige tant que le traitement n'est pas fini (des fois l'application reprend temporairement la main dans les moments d'inactivité)

[Andnotor]

Tous les évènements sont mis dans une file de messages et traiter lorsque Windows a fini avec les messages arrivés plus tôt.

Seulement les messages envoyés par PostMessage. SendMessage s'adresse directement à la fenêtre cible.

Les applications ont toujours un thread principal (fil d'exécution) qui est consacré aux traitements des messages, de l'interaction avec le système d'exploitation en dessous et de l'affichage.

Ce n'est pas propre au thread principal, les secondaires aussi. Même l'affichage d'une fenêtre est possible pour autant qu'on fasse directement appel aux API. C'est l'implémentation de la VCL qui n'est pas thread-safe.

[delaio]

Bonjour,

Windows est aussi asynchrone

Je me suis peut être mal exprimé... un petit bout de code sera peut être plus explicite :

application multi périphérique avec 1 form et 1 bouton. évenement onclick du bouton :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
procedure TForm1.Button1Click(Sender: TObject);
begin
  showmessage('1');
  showmessage('2');
  showmessage('3');
end;

compilé sous windows, l'application fera apparaitre "1" et attendra que l'utilisateur clique sur "ok" pour afficher "2" et ainsi de suite...
compilé pour android, l'application affichera tout dans la foulée sans attendre le retour utilisateur. Si l'exécution est rapide, ce dernier verra à l'écran "3", puis "2" puis "1".

c'était de cela dont je voulais parler. De même, la gestion des boites de dialogues pour poser une question à l'utilisateur ("souhaitez vous faire ceci ? oui non") est gérée différemment.

@delaio: tout traitement long doit être intégré dans des threads @foetus: Windows tout également. iOS si je ne dis pas de bêtises aussi

Certes, je suis entièrement d'accord avec toi, on ne doit jamais laisser une application se figer, quelque soit l'OS. là où je voulais en venir, c'est que, par exemple, la connexion internet sur un pc est relativement stable : un traitement qui prend une ou deux secondes n'est pas systématiquement collé dans un thread (exemple : enregistrer un champ dans la table d'une base de données située sur un serveur distant).
Avec Android, le raisonnement est différent : connexion wifi ou données mobiles : l'enregistrement d'un champ dans une table sur un serveur distant qui ne prend que 1/2 seconde, peut vite basculer à 10 secondes si l'utilisateur est en rase campagne avec un mauvais débit. d'autant qu'Android vérifie l'état de chaque application qui tourne, et pour celle qui ne répond pas ("suffisamment vite"), il envoie un message à l'utilisateur pour savoir s'il veut killer l'application ou attendre. Ces 2 notions, pour une 1ère appli, il vaut mieux les avoir avant d'avoir terminé et testé son dev avec une excellente connexion wifi

[foetus]

C'est l'implémentation de la VCL qui n'est pas thread-safe.

C'est surtout la winapi/ win32 qui n'est pas "thread safe"

J'ai regardé Qt , et la bibliothèque est "thread safe" parce que chaque thread (fil d'exécution) a sa propre file de messages.

Je me suis peut être mal exprimé...

Le terme technique c'est modal (en anglais modal et modeless) : Fenêtre modale (<- lien wiki)

il vaut mieux les avoir avant d'avoir terminé et testé son dev avec une excellente connexion wifi

Non c'est le b.a.-ba de la programmation réseau : écran d'attente passive et configuration de délai réaliste (timeout, à peu près entre 30 secondes et 1 minute)

Et encore , ce n'est que de l'UDP sans QoS.

[Andnotor]

C'est surtout la winapi/ win32 qui n'est pas "thread safe"

J'ai regardé Qt , et la bibliothèque est "thread safe" parce que chaque thread (fil d'exécution) a sa propre file de messages.

Il faudrait savoir alors quelle définition tu donnes à thread safe.

Une fenêtre créée par API dépend uniquement du thread qui l'a créé. L'ensemble du traitement se fait dans ce thread (principal ou secondaire) en toute sécurité.
Une fenêtre Delphi aura toujours une partie de son code exécuté dans le thread principal (bien ou mal, c'est ainsi que Delphi a été pensé) quelque soit le thread demandant la création.

C'est donc parfaitement sûr en faisant appel aux API mais pas du tout par l'implémentation Delphi puisque plusieurs threads sont impliqués mais sans aucune synchronisation.

Que Qt se rapproche plus du modèle API est tout à fait possible (je ne connais pas) et dès lors que l'ensemble du code est exécuté depuis le même thread, il est thread safe.

Mais ne pas confondre avec du multi-threads qui ne sera jamais safe sans synchronisation, et cela quelque soit le langage.

Et pour information, il suffit d'appeler GetMessage (ou PeekMessage) pour automatiquement créer une pile de messages. Rien de compliqué donc