Discussion :

[xino972]

Bonjour,
Je poste ce message dans l'espoir d'avoir quelques conseils sur l'architecture et la faisabilité d'un projet SI d'auto école.


En gros au sein d'une auto école, une base de données regroupe toutes les informations concernant les plannings des élèves et des moniteurs.


L'idée est d'envoyer à chaque fin de journée ou semaine le planning des moniteurs via sms.

Le SI doit permettre également aux moniteurs de valider ou non la présence d'un élève sur la route afin de débiter les heures de cours prises par l'élève.

Je m'y connais en java et là j'attaque tout ce qui est java mobile.
Mes questions :

1) Est ce que ça vous parait jouable ?
2) Par quoi dois je commencer ?
3) Quelle architecture me conseillée vous ?
J'ai lu pas mal de doc et je ne vois pas pas à part le net ou un truc du genre gprs quelle interface réseau utliser pour faire communiquer les mobiles et la base de données du siège de l'auto école.

Merci pour vos réponses et vos conseils.

[castader]

à part la fonction d'envoi d'sms (si on imagine qu'il faut envoyer de mail par ex) me parait une question simple et classique mais sinon la partie envoi d'sms et plus original et sort du cadre du si pour rentrer dans un cadre de TELECOM donc cette interface pour l'envoi d'sms doit etre fournie par un operateur specialisé en cela de manière à ce que le SI puisse communiquer avec cette interface à travers un WEBservice par exemple .

[wiztricks]

Utiliser les SMS comme couche de transport est assez original. En supposant qu'on identifie les SMS à interpréter en fonction du numéro d'appel ou de leur format - comment filtrer ceux qui... - enfin pourquoi pas?
Une question peut être le nombre de caractères limités à quelques centaines (je ne sais plus de mémoire mais c'est pas beaucoup).

Est-on aujourd'hui condamné à utiliser une telle couche de transport? Ne peut on pas supposer que les mobiles pourraient utiliser une interface au dessus de TCP/IP que permet d'avoir GPRS/Edge?

Cela permettrait à une application WEB développée pour 'mobile' - avec des contraintes côté interface utilisateur - de s'appuyer sur une couche de services assez 'standard' et utilisable depuis n'importe quel terminal (un PC connecté à Internet par exemple).

Dans ces affaires, le soucis est l'"utilisabilité"(*) de l'interface utilisateur et son éventuelle portabilité sur des environnements d'exploitation différents: il sera difficile de garder le même mobile 'longtemps' et les coûts de tests de l'interface sur des mobiles particuliers doit être raisonnable.
(*) désolé je ne sais pas traduire usuability en français.
-W

[crazycrow]

d'après mes souvenir, qui datent un peut, tu ne pas pas traiter de sms si celui n'est pas reçu au moment où l'application est ouverte, je veut dire qu'il faut que l'application soit lancé avant l'envoie de sms.

Sinon, tu peut prendre le problème a l'envers, au lieu d'envoyer, tu peut demander au utilisateur de l'application d'aller chercher (il faudra un serveur, ou une page perso par exemple). On reviens sur une connexion http basique avec requête et traitement du résultat.Genre pour chaque séance , aux début, l'utilisateur peut choisir de dire si oui où non l'élève est venue.

Par contre, comme disait wiztricks (enfin si j'ai bien compris) tu peut faire une sorte de site wap, avec par exemple un login et un password pour identifier le moniteur, qui accèderais a son planning, et qui aurai juste un bouton a appuyer pour validé le fait que l'élève soit présent. Cela passerai sur tous les mobiles qui vont sur le wap/web, tu n'aurais pas le coût (temps) du portage sur diffèrent téléphones.

[wiztricks]

Par contre, comme disait wiztricks (enfin si j'ai bien compris) tu peut faire une sorte de site wap, avec par exemple un login et un password pour identifier le moniteur, qui accèderais a son planning, et qui aurai juste un bouton a appuyer pour validé le fait que l'élève soit présent. Cela passerai sur tous les mobiles qui vont sur le wap/web, tu n'aurais pas le coût (temps) du portage sur diffèrent téléphones.

C'est a peu près çà... Je suis assez vague sur la définition d'une application WEB car tout est dans la répartition des activités faites entre le morceau qui s'exécute sur le mobile et ce qui s'exécute à distance.
Il peut être intéressant d'avoir un minimum d'intelligence locale: pas la peine de se connecter tout le temps pour rapporter les élèves, récupérer le planning de la semaine. D'autant que nous avons beaucoup de capacités de calcul et de stockage 'en local'.
Puisque nous sommes en Europe, Nokia propose Qt comme IDE (iPhone c'est Objective-C), d'autre c'est je ne sais quoi d'autre.
Après on peut tenter WAP mais çà ne tient pas encore toutes ses promesses: d'un téléphone à l'autre les différences sont subtiles et côté IHM ça coûte.
Pas facile de faire un choix sans trop fermer les mobiles supportés, les possibilités de l'IHM, la perénité des technologies utilisées,...
- W

[nouknouk]

salut,

amha, le principal souci auquel tu devras faire face sont les soucis d'incompatibilités entre les différents téléphones J2ME.

Donc si ton projet est spécifique à une auto-école bien précise, et que tu optes pour un 'client lourd' en J2ME, imposer l'utilisation d'un unique modèle de téléphone te ferait économiser énormément de temps de développement.

Pour les moyens de communication, tout dépend si:
- tu veux obligatoirement du push (ie. que les utilisateurs de téléphone soient prévenus dès qu'une nouvelle info est dispo)
- ou si un principe de polling: les utilisateurs iront plus ou moins régulièrement vérifier s'ils ont de nouvelles infos.

Si le principe du polling est acceptable et que tu choisis des téléphones relativement récents et qui ont un navigateur web, un simple site web dynamique (en PHP, J2EE ou autre) serait amha très rapide à coder et probablement plus 'portable' d'un téléphone à un autre : à partir du moment ou le téléphone est assez récent pour intégrer un browser web et que les pages du site sont basiques (HTML pur), n'importe quel téléphone pourrait faire l'affaire.

Enfin, question coût, un simple accès 'DATA' (GPRS, EDGE, 3G) au net n'est plus très chère comparée aux SMS. Elle permet plus de choses (cf. limitation taille d'un SMS), réutilisation de technos 'standards' (XML, ...) et nécessitera à coup sûr beaucoup moins d'effort de développement.