Forum Clubic

{Java/J2ME} Deux Thread concurrents

Bonjour,

Mon application cliente (un Midlet Java Mobile) doit s’identifier auprès d’un serveur (via Internet).
Afin de faire ça proprement j’ai threadé la partie réseau : j’ai donc un Thread nommé ServerLink qui s’occupe de communiquer avec le serveur.

Imaginons le cas de figure suivant :
A. Le ServerLink est lancé et mis en veille (wait()).
B. L’utilisateur clique sur le bouton “Connecter”, là j’appelle le ServerLink qui va se réveiller (notify()) et faire son boulot (demander un truc au serveur via le réseau).
C. Lorsque qu’il a obtenu la réponse du serveur (délai variable parce que le réseau n’est jamais fiable), il va appeler une méthode du Midlet (genre networkResponse(String s) pour refiler le résultat.
D. Ce Midlet fera quelque chose de ce résultat (quoi exactement : on s’en fiche).

La question que je me pose c’est : les opérations effectuées par le Midlet en D sont faite dans quel thread ? Celui du ServerLink ou bien celui de l’application ?
(Moi j’aimerais que cela soit dans celui de l’application, que le ServerLink puisse retourner se coucher et être prêt pour un autre appel)

(Pour la conception, je me suis basé sur l’article : developers.sun.com…)

si dans ta méthode networkResponse(String s) tu exécutes du code, ce sera ton ServerLink qui tournera.
il faudrait plutôt envoyer les infos au midlet (setnetworkresponse(String ficelle)) et signaler au midlet qu’il a reçu la réponse. A cemoment ton thread ServerLink pourrait retourner en pause (à vérifier) et le midlet reprendre les opérations.

Le problème c’est que je ne vois pas comment signaler quoique ce soit au MIDlet (qui lui est en train d’afficher une zolie roue tournante afin de rassurer l’utilisateur : son mobile n’a pas planté). Si j’avais mis en sommeil le MIDlet (Thread.wait()), j’aurais pu le réveiller avec un le_midlet.notify()) mais ça n’est pas le cas (parce qu’il faut qu’il soit actif pour faire tourner la roue…).
En y repensant, je crois que le mieux aurait été d’avoir la roue dans un thread différent : j’aurais ainsi pû mettre en attente le MIDlet sans problèmes.

Vu que dans mon cas c’est surtout des changements d’écran qui sont effectués lors de réponses du serveur (écran de login —[demande de connexion]–> attente… —[réponse]–> écran de bienvenue)
Ce que j’ai fait c’est un appel à Display.setCurrent(ecranSuivant) qui est une fonction J2ME ne retournant rien (le ServerLink peut donc retourner dans sa boucle de wait()) et les saisies utilisateur suivantes seront ainsi gérées par le thread de l’application.
(Testé et ça me convient)

Merci :slight_smile:

heureux d’avoir pu aider :slight_smile: