Discussion :

[Bluedeep]

Bonjour

Je précise d'entrée de jeu que j'ai des connaissance en Java extrémement rouillées et des connaissance sur le J2ME à peu près nulle.

Je suis actuellement en train de travailler sur les spécifications techniques d'une application qui aura une partie "mobile".

La partie mobile doit travailler sur des téléphones avec J2ME (pré-requis).

L'application doit supporter un mode déconnecté avec resynchronisation lorsque la connexion devient à nouveau possible (sans intervention de l'utilisateur).

Basiquement, chaque téléphone va porter une appli autorisant de la saisie/affichage, les éléments saisis doivent être persistés, et lorsque la synchro est possible ou à intervalle régulier, le téléphone se connecte au SI pour metrre à jour un flux descendant de donnée et un flux montant (les données saisies).

Coté SI, je vais utiliser une base dédiée à la flotte de mobile qui contiendra toutes les données à "descendre" et recevra les données "montantes".
La synchro utilisera SyncLM avec un serveur Funambol (sauf si il y a un autre choix valable).

A partir de là, j'ai un certain nombre d'interrogation :

- ma grosse préoccupation est la couche de persistence sur le mobile. J'ai jeté un oeil à RMS; c'est pauvre ..... existe-t-il quelque chose de plus évolué en terme de fonctionnalité ?? (une sorte de SqlIte pour j2ME, ou quoique ce soit supportant une syntaxe SQL)

- apparement il n'existe pas non plus de parser XML. Confirmé ?

- j'ai cru comprendre que J2ME ne connaissait pas les appli "back-ground". Donc apparemment, l'appli de saisie/affichage devra s'occuper aussi de la synchronisation. Ceci me pose un problème de design puisque la gestion des threads semble un peu incomplète. Comment contournez vous ce type de problème ?

- authentification sur la passerelle du SI lors de la connexion; puis je manipuler le flux HTML envoyé depuis la passserelle avec des lib standards ?

C'est tout pour le moment; merci par avance !!!!

[Uther]

- ma grosse préoccupation est la couche de persistence sur le mobile. J'ai jeté un oeil à RMS; c'est pauvre ..... existe-t-il quelque chose de plus évolué en terme de fonctionnalité ?? (une sorte de SqlIte pour j2ME, ou quoique ce soit supportant une syntaxe SQL)

Le RMS est certes pauvre mais c'est le seul système disponible sur tous les mobile. Il devrait être suffisant pour permettre de stoquer des informations en attendant la disponibilité de la connection.
Pour le sql, il y a bien la JSR-169(JDBC for JavaMe) additionnelle, mais il ne me semble pas quelle soit utilisée par beaucoup de téléphone. D'ailleurs, je en pense pas que le SQL soit vraiment adapté pour ce type de terminal.

- apparement il n'existe pas non plus de parser XML. Confirmé ?

Il y a des bibiothèque qui peuvent faire ça. Je me souviens plus des noms mais une recherche par google devrait suffire a trouver

- j'ai cru comprendre que J2ME ne connaissait pas les appli "back-ground". Donc apparemment, l'appli de saisie/affichage devra s'occuper aussi de la synchronisation. Ceci me pose un problème de design puisque la gestion des threads semble un peu incomplète. Comment contournez vous ce type de problème ?

En effet les applis background devraient arriver dans Midp3. En attendant, je penses que tu n'as pas d'autre choix que de faire la synchronisation au démarrage de ton appli.
La gestion des Thread est certes plus légère qu'en Java SE, mais tu devrais quand même pouvoir te débrouiller avec.

- authentification sur la passerelle du SI lors de la connexion; puis je manipuler le flux HTML envoyé depuis la passserelle avec des lib standards ?

Je suis pas sur d'avoir compris. Le flux envoyé depuis la passerelle ne peux normalement être manipulé que par la passerelle elle même.

[Bluedeep]

Merci pour ta réponse rapide; reprenons :

Le RMS est certes pauvre mais c'est le seul système disponible sur tous les mobile. Il devrait être suffisant pour permettre de stoquer des informations en attendant la disponibilité de la connection.

Le problème est son usage va entraîner une importante charge de développement pour la couche d'accès aux données de l'application embarquée (habitué à chiffrer des dev. utilisant un SGBDR pour la persistance, le fait de devoir se contenter d'un système de fichier à accès direct va compliquer monstrueusement les choses, notamment par l'absence de controle d'intégrité relationnelle - ca me rajeunit de 20 ans )

Il n'existe même pas de bibliothèqque ISAM style BerkeleyDB ?

Pour le sql, il y a bien la JSR-169(JDBC for JavaMe) additionnelle, mais il ne me semble pas quelle soit utilisée par beaucoup de téléphone. D'ailleurs, je en pense pas que le SQL soit vraiment adapté pour ce type de terminal.

Ok, je vais voir par rapport à mon parc (trois modèles différents, dont un modèle pas récent).

Il y a des bibiothèque qui peuvent faire ça. Je me souviens plus des noms mais une recherche par google devrait suffire a trouver

Oui, j'ai trouvé entre-temps.

En effet les applis background devraient arriver dans Midp3. En attendant, je penses que tu n'as pas d'autre choix que de faire la synchronisation au démarrage de ton appli.

Ma problématique est un peu plus complexe. Je dois synchroniser au démarrage de l'appli, puis tenter de synchroniser les données montantes en cas de saisie d'info par l'utilisateur, et synchroniser les données descendantes (et les montantes si elle n'ont pas pu être synchronisées car hors zone de couverture) à intervalle régulier (typiquement toutes les 1/2 heures).

La gestion des Thread est certes plus légère qu'en Java SE, mais tu devrais quand même pouvoir te débrouiller avec.

Oui, j'ai vu entretemps : je peux laisser "vivant" un thread de synchro visiblement.

Je suis pas sur d'avoir compris. Le flux envoyé depuis la passerelle ne peux normalement être manipulé que par la passerelle elle même.

Quand je connecte ma passerelle d'authentification des utilisateurs en mobilité, elle présente une page de saisie utilisateur/mot de passe. C'est parfait pour mes appli WAP, mais un peu plus lourd pour cet appli J2ME (qui va devoir poster la page de manière "transparente").