Client tcp ip compatible web ou autre solution pour smartphone ?

Version imprimable

28/09/2018, 21h52
Coussati

Client tcp ip compatible web ou autre solution pour smartphone ?

bonjour

j'ai une application cliente-serveur tcp ip codé en D7 (donc compatible uniquement windows), et mes utilisateurs me réclament de plus en plus la possibilité d'utiliser le smartphone android

étant toujours sous D7, que me conseillez vous pour les satisfaire ? j'aimerais limiter le plus possible les inconvénients d'apprendre un nouveau langage comme java

je touche un peu aux langages web, l'idéale serait de faire un client qui tourne sur un navigateur, mais est ce vraiment possible de créer un client qui se connectera à un serveur tcp ip (codé en delphi) que je ne compte pas y toucher

merci d'avance à ceux qui me liront et bisous à ceux qui me trouveront une solution parce que je désespère ^^ :(
29/09/2018, 08h46
SergioMaster

Bonjour,

En restant D7 (c'est quelque part dommage maintenant qu'il y a la version Communauty ;) )

Une solution Intraweb (voir tutoriel de Dany Leblanc) et en poussant un peu une solution Intraweb mâtinée de HTML,CSS et à l'extrême saupoudrer l'ensemble de jQuery

J'écris cette proposition d'expérience puisque j'ai fait un truc de ce genre (mais pas avec D7)
cela nécessite qu'un bon serveur, une adresse internet fixe (mieux un nom de domaine) et un port (en général le 8080) ouvert et redirigé au niveau de la box

P.S. Reste la limitation de la version de Indy (licence ou non etc..) ça fait un bail que je n'ai pas suivi (surtout pour D7) ce qu'il en est. En tout cas selon les versions le nombre de clients était limité ou non donc bien vérifier ce point
29/09/2018, 16h03
tourlourou

Une solution pourrait être de passer à Delphi Community Edition, sans coûteuse licence (elle est gratuite) pour peu que tes revenus liés à cette activité ne dépassent pas 5000 € annuels.
29/09/2018, 16h16
Paul TOTH

Citation:

Envoyé par Coussati

bonjour

j'ai une application cliente-serveur codé en D7 (donc compatible uniquement windows), et mes utilisateurs me réclament de plus en plus la possibilité d'utiliser le smartphone android

étant toujours sous D7, que me conseillez vous pour les satisfaire ? j'aimerais limiter le plus possible les inconvénients d'apprendre un nouveau langage comme java

je touche un peu aux langages web, l'idéale serait de faire un client qui tourne sur un navigateur, mais est ce vraiment possible de créer un client qui se connectera à un serveur tcp ip (codé en delphi) que je ne compte pas y toucher

merci d'avance à ceux qui me liront et bisous à ceux qui me trouveront une solution parce que je désespère ^^ :(

tu ne pourras pas interroger un serveur IP depuis une page web, en Javascript tu peux envoyer des requêtes HTTP (AJAX) ou éventuellement ouvrir un WebSocket qui commence par du HTTP et qui bascule en connexion permanente en lecture/écriture...mais ça ne te permet toujours pas de dialoguer en direct sur le socket.

le communication Client/server c'est du propriétaire maison ou un standard ? mais dans tous les cas je pense que le plus simple serait un frontal serveur qui fait l'interface entre HTTP et ton serveur....un WebBroker Delphi par exemple qui interroge ton serveur quand il reçoit une requête web...ou de l'Intraweb, personnellement ce que je n'aime pas dans Intraweb c'est que tu dois apprendre le framework alors que je sais comment ça fonctionne en dessous, donc je pars de plus bas :)
29/09/2018, 18h40
Coussati

et bien le problème vient de ma version de delphi, je viens de tomber sur un lien que j'avais zappé, qui proposait une version de delphi complète Community Edition

je n'ai jamais touché les delphi > 7 et donc j'arrive sur la pointe des pieds, et en même temps je suis impatient de découvrir ce FMX Firemonkey que j'ai si souvent aperçu sur le forum et ailleurs ^^

il me semble que t'y as déjà goutté :p

peux tu me dire si je dois tout recoder en passant par Firemonkey afin que l'application fonctionne sur android ?

sinon, le plus important pour moi reste le fonctionnement d'une application cliente-serveur, ici que cliente, car mon serveur est déjà opérationnel et n'a pas besoin de fonctionner sur du multiplate-forme vu qu'il est hébergeur

par contre ne te fais pas de soucis pour le serveur et son hébergement : il est online 24h/24 et dispose d'une ip fixe ;)
29/09/2018, 18h59
Paul TOTH

Citation:

Envoyé par Coussati

et bien le problème vient de ma version de delphi, je viens de tomber sur un lien que j'avais zappé, qui proposait une version de delphi complète Community Edition

je n'ai jamais touché les delphi > 7 et donc j'arrive sur la pointe des pieds, et en même temps je suis impatient de découvrir ce FMX Firemonkey que j'ai si souvent aperçu sur le forum et ailleurs ^^

il me semble que t'y as déjà goutté :p

peux tu me dire si je dois tout recoder en passant par Firemonkey afin que l'application fonctionne sur android ?

sinon, le plus important pour moi reste le fonctionnement d'une application cliente-serveur, ici que cliente, car mon serveur est déjà opérationnel et n'a pas besoin de fonctionner sur du multiplate-forme vu qu'il est hébergeur

par contre ne te fais pas de soucis pour le serveur et son hébergement : il est online 24h/24 et dispose d'une ip fixe ;)

1) la version Community ne peut être utilisé dans ton cadre professionnel que si tu ne dégages pas plus de 5000€/an....

2) oui, pour développer avec Delphi sous Android on utilise généralement Firemonkey, bien qu'il soit possible - comme sous Windows avec l'API Win32 - de n'utiliser que l'API NDK Android...mais alors c'est tout à la main (cf https://www.youtube.com/watch?v=f_toxNTFxa0&t=2s)

3) tu peux très bien développer une appli Web avec Delphi 7, cf les chapitres 15 et 17 de mon bouquin sur Delphi 7 justement :) j'ai même commencé la programmation Web avec Delphi 2 !

sinon tu n'as pas répondu à ma question sur le protocole de communication entre ton client et ton serveur
29/09/2018, 19h43
Coussati

alors dsl Paul et tourlourou ! je n'avais pas vu vos messages, je me suis arrêté uniquement à la réponse de segiomaster ! mais je me disais bien avoir lu quelque part Delphi Community Edition ! :D

l'application est destinée à des utilisateurs d'une petite association, tout est gratuit donc pas de soucis de dépassement de 5000 €

pour ce qui est de l'application, je t'explique rapidement, tu me proposeras selon toi la meilleur solution applicable par le petit codeur que je suis ^^

j'ai déjà une application cliente-serveur qui fonctionne très bien sur windows

la connexion se fait grâce à des composant tcp ip (client et serveur)

le serveur est hébergé sur un pc windows tout le temps connecté, et donc accueil les clients pour les mettre en relation à l'image d'un tchat

maintenant que beaucoup d'utilisateur réclament une version smartphone, j'aimerais garder la version windows, et créer un client "smartphone" capable de faire de faire ce que le client windows fait

ainsi le serveur recevra des clients issu de pc windows ainsi que des clients installé sur des smartphones (android principalement) et apple en bonus :)

avec l'avancé du HTML 5, Jquery et autre technologie, j'espérais une innovation de ce côté là, mais d'après ce que tu dis, c'est à oublier ?
30/09/2018, 00h39
Paul TOTH

Citation:

Envoyé par Coussati

alors dsl Paul et tourlourou ! je n'avais pas vu vos messages, je me suis arrêté uniquement à la réponse de segiomaster ! mais je me disais bien avoir lu quelque part Delphi Community Edition ! :D

l'application est destinée à des utilisateurs d'une petite association, tout est gratuit donc pas de soucis de dépassement de 5000 €

pour ce qui est de l'application, je t'explique rapidement, tu me proposeras selon toi la meilleur solution applicable par le petit codeur que je suis ^^

j'ai déjà une application cliente-serveur qui fonctionne très bien sur windows

la connexion se fait grâce à des composant tcp ip (client et serveur)

le serveur est hébergé sur un pc windows tout le temps connecté, et donc accueil les clients pour les mettre en relation à l'image d'un tchat

maintenant que beaucoup d'utilisateur réclament une version smartphone, j'aimerais garder la version windows, et créer un client "smartphone" capable de faire de faire ce que le client windows fait

ainsi le serveur recevra des clients issu de pc windows ainsi que des clients installé sur des smartphones (android principalement) et apple en bonus :)

avec l'avancé du HTML 5, Jquery et autre technologie, j'espérais une innovation de ce côté là, mais d'après ce que tu dis, c'est à oublier ?

tu as lu mes réponses ? tu peux faire une client web, mais il ne pourra pas interroger directement ton serveur IP, il lui faut une passerelle web

solution 1 : une appli Delphi (7 ou CE on s'en fiche) est serveur Web ET client de ton serveur, c'est donc une passerelle web pour ton serveur
solution 2 : une appli CE sur mobile (pour iOS il faut payer sinon c'est niet)
30/09/2018, 20h11
Coussati

salut

Citation:

Envoyé par Paul TOTH

tu as lu mes réponses ? tu peux faire une client web, mais il ne pourra pas interroger directement ton serveur IP, il lui faut une passerelle web

oui j'ai vu, je ne vois pas bien encore comment s'y prendre pour faire la passerelle, mais je me demande si ce sera efficace ? encore une fois je ne vois pas encore comment ça fonctionnera, mais ça fera un peu comme de l'udp ? c'est à dire qu'on ne sera pas connecté en temps réel ...

Citation:

Envoyé par Paul TOTH

solution 1 : une appli Delphi (7 ou CE on s'en fiche) est serveur Web ET client de ton serveur, c'est donc une passerelle web pour ton serveur

en faite cette solution est liée à ce que tu disais plus haut ?

Citation:

Envoyé par Paul TOTH

solution 2 : une appli CE sur mobile (pour iOS il faut payer sinon c'est niet)

ok pour le moment, je peux me contenter de android uniquement ... je n'ai pas encore installé CE, mais je suppose que je devrais recoder en utilisant un projet firemonkey ? et aurais je un composant client du même style que ce qu'on trouve sur D7 ?

si vous avez une source client-server je suis preneur, j'avoue trouver peu d'exemple

pour information : l'utilisateur se connecte au serveur, et reste connecté durant "tout son séjour", il faut donc une connexion directe et fiable

en cas de perte de connexion ou déconnexion, l'utilisateur est éjecté
01/10/2018, 10h09
Paul TOTH

je pense surtout que tu n'as pas les idées claires

un navigateur ne conserve généralement pas de connexion permanente sur le serveur, il envoie une requête et réceptionne une réponse, fin de la conversation (principe REST).
avec AJAX il est possible d'interroger périodiquement le serveur suivant ce même principe sans pour autant recharger la page (ce qu'on faisait avant AJAX)
avec les Websocket il est possible de garder une connexion persistante pour échanger des données avec le serveur, mais c'est un protocole spécifique d'échange de données qui sont généralement du JSON bien que ce ne soit pas une obligation, je m'en sert personnellement pour pousser une information au navigateur sans qu'il ait besoin d'interroger le serveur périodiquement justement.

sur mobile, et notamment en 3/4G il faut savoir que les connexions sont bien moins stables qu'en LAN, et il n'est pas rare d'avoir des interruptions de communication.

dès lors une passerelle web peut avoir l'architecture suivante

1) un navigateur sollicite la passerelle, celui-ci retourne une page web avec un COOKIE de session
2) pour chaque nouvelle requête de la page web, le cookie permet à la passerelle de savoir qu'on est dans la même session
3) le serveur garde en mémoire les informations de session entre deux connexions et gère simplement un timeout pour fermer la session si elle est inactive depuis trop longtemps puisque rien ne viendra nous dire que le navigateur ne fera plus de requête; même s'il peut éventuellement envoyer une demande de fermeture de session explicite par un bouton "deconnexion" par exemple, si je ferme brutalement le navigateur il n'y aura pas de déconnexion sur le serveur puisqu'il n'y a de fait pas de connexion (sauf en WebSocket)
4) la session active sur le serveur peut très bien être client de ton serveur IP avec une connexion persistante.

du coup le boulot de la passerelle c'est
1) gérer les cookies de sessions
2) maintenir une liste de sessions actives
3) réceptionner des requêtes HTTP et les traiter en requête Client/serveur pour renvoyer une réponse HTTP

note aussi que cette architecture peut très bien être exploitée par un client natif qui au lieu d'interroger le serveur IP peut, lui aussi, envoyer des requêtes HTTP à la passerelle avec des connexions non persistantes afin d'économiser la batterie par exemple ou supporter les coupures de réseau....dans ce cas la passerelle retournera plutôt du JSON (ou du XML) que du HTML...comme pour AJAX dans la version web.
01/10/2018, 17h53
Coussati

Citation:

Envoyé par Paul TOTH

je pense surtout que tu n'as pas les idées claires

non au contraire, je te suis, même si je ne maîtrise pas tout forcément

Citation:

Envoyé par Paul TOTH

un navigateur ne conserve généralement pas de connexion permanente sur le serveur, il envoie une requête et réceptionne une réponse, fin de la conversation (principe REST).
avec AJAX il est possible d'interroger périodiquement le serveur suivant ce même principe sans pour autant recharger la page (ce qu'on faisait avant AJAX)
avec les Websocket il est possible de garder une connexion persistante pour échanger des données avec le serveur, mais c'est un protocole spécifique d'échange de données qui sont généralement du JSON bien que ce ne soit pas une obligation, je m'en sert personnellement pour pousser une information au navigateur sans qu'il ait besoin d'interroger le serveur périodiquement justement.

on est d'accord également

étant donné que les échanges doivent être possibles dans les 2 sens, on retiendra que c'est possible en websocket (échange client vers server et server vers client) mais le problème restera au niveau de l’architecture, notre server acceptant que des connexions tcp ip

Citation:

Envoyé par Paul TOTH

sur mobile, et notamment en 3/4G il faut savoir que les connexions sont bien moins stables qu'en LAN, et il n'est pas rare d'avoir des interruptions de communication.

j'y avais pensé également, je me demandais si je n'allais pas décider d'accepter que les connexions wifi ? et en même temps je m'oppose au principe du smartphone qui est censé être un outil portable :/

je me demande comment font "les autres" pour mettre en relation toutes les plateformes ? :(

je commence à me dire que je dois peut être revoir mon architecture, et oublier delphi, passer le navigateur pour tout le monde (socket.io websocket) ? ou alors je dois bien revoir mon architecture, mais cette fois en oubliant la connexion directe ? parce qu'il est là mon soucis ... c'est d'avoir la main sur tous mes clients ! j'ai mon serveur qui dort, ou attend plus tot que les clients se connectent et le serveur les gère bien : nombre de connecté, décide d'éjecter un client précis, transmet les données à chacun, ect

je me vois mal faire une telle application sans être sûr de qui est connecté, depuis quand, ect ...

bon, ensuite tu parles de "passerelle", donc pour bien savoir si je te suis :

- je garde mon server tcp ip actif, toujours hébergé sur un pc windows connecté H24

- mais UNIQUEMENT le serveur web pourra échanger avec le serveur tcp ip c'est bien ça ? et cette connexion sera du directe si j'ai bien compris ? ET DONC, le client lui sera en relation avec le serveur web, et ce sera à moi d'élaborer une architecture client-server web ?

je ne sais pas si j'ai bien compris (u si je mélange tout), mais dans ce cas est ce que c'est possible de faire ainsi :

le client depuis le navigateur est connecté directement au server web depuis les websockets, et le serveur web est connecté au server tcp ip ? en espérant que ça ne fera pas trop de chose à gérer ...