Pourquoi J2ME Midlet Suite et HTTPConnection doivent se trouver dans des threads différents

Question

Je souhaite appeler un servlet à partir du midlet J2ME. J'ai donc écrit le code HTTPConnection pour que l'URL du servlet appelle la méthode GET.

Lorsque les suites Midlet tentent de se connecter à l'URL du servlet, j'ai le message ci-dessous dans l'émulateur :

{#MyMidlet} Midlet Suite wants to connect to {#Servlet URL} using air time,
  this may result in charges, Is it ok to use airtime ?

Si je clique sur Non ou Oui, rien ne se passe, il s'est simplement bloqué, j'utilise EclipseME et SUN WTK 2.5.2.Et dans la console il y avait un avertissement,

Warning: To avoid potential deadlock, operations that may block, such as 
 networking, should be performed in a different thread than the 
 commandAction() handler.

Ce qui signifie que si je crée HttpConnection dans un fil de discussion séparé, le problème sera-t-il résolu ?

Answer 1

Si je crée HttpConnection dans un fil de discussion séparé, le problème sera-t-il résolu ?

Si vous le faites correctement, oui, le problème sera résolu.Il s'agit d'un problème typique et il existe une solution standard.

L'avertissement auquel vous faites référence indique un problème de conception dans votre midlet.Vous avez une activité « lourde » (connexion http) qui s’exécute dans le même thread que l’interface utilisateur, la bloquant et la rendant irresponsable.

Évitez les charges lourdes dans le fil d’événements de l’interface utilisateur.Quand il y a beaucoup à faire de quelque chose à l'intérieur commandAction ou keyPressed ou pointerPressed etc, créez simplement un nouveau fil de discussion pour ce faire.Pour mieux comprendre pourquoi, pensez à étudier ce tutoriel pour savoir comment bien faire les choses :

Réseautage, expérience utilisateur et fils de discussion

^{Cet article explique comment votre MIDlet peut établir des connexions réseau sans compromettre votre interface utilisateur.Il comprend six exemples itératifs qui illustrent la mise en réseau multithread et l'utilisation d'un écran d'attente...}

• Après le tout premier exemple du tutoriel (PrimitiveMidlet), il y a même une explication détaillée du problème que vous rencontrez :

  ...un programmeur a détourné un thread système pour son propre traitement long.Le système appelle sa méthode commandAction() lorsque l'utilisateur sélectionne une commande.Le thread qui appelle cette méthode appartient au système et non au développeur.Ce ne serait pas un crime si la méthode s'exécutait rapidement, mais dans ce cas, la connexion réseau peut monopoliser le thread du système pendant une longue période.

  Dans la programmation d'applications J2SE et même dans la programmation de servlets, le système crée un thread pour vous et il existe peu de restrictions sur la durée de votre traitement.La règle du threading MIDlet est simple et stricte :les seuls fils qui vous appartiennent sont ceux que vous créez vous-même.

  Dans un MIDlet, vous écrivez du code que le système appellera depuis l'un de ses propres threads.Lorsque les méthodes startApp(), pauseApp(), destroyApp() et du gestionnaire d'événements de votre MIDlet sont appelées, par exemple, elles s'exécutent dans un thread système.Vos méthodes doivent revenir rapidement pour que le thread système puisse continuer son autre travail.Toute tâche qui ne peut pas être accomplie rapidement doit être déplacée hors du thread du système.

  Ce style de programmation peut prendre un certain temps pour s'y habituer, car vous n'écrivez en réalité que du code appelé à partir des threads du système.Cependant, si vous avez déjà programmé une autre interface graphique, cette technique vous sera familière.AWT et Swing disposent d'un thread de répartition d'événements qui gère les événements du système d'exploitation et appelle les gestionnaires d'événements dans votre code.La règle est la même :les gestionnaires d'événements doivent s'exécuter rapidement et rendre le contrôle au thread de répartition des événements afin que le reste de l'interface ne se bloque pas...

D'autres exemples de code dans le didacticiel montrent comment corriger les erreurs de conception comme ci-dessus et comment faire en sorte que l'interface utilisateur MIDlet interagisse en douceur avec les activités réseau.

Answer 2

crée sa connexion comme thread séparé comme celui-ci:

Thread myConnection = new Thread(new Runnable() {

        public void run() {
            // TODO open connection here


            HttpConnection conn = null;

            try {

                        conn = (HttpConnection) Connector.open(serverURL,
                                Connector.READ_WRITE, true);

                        conn.setRequestMethod(HttpConnection.GET); // or POST method

                    } catch (Exception e) {

                // TODO: handle exception

            } finally {

                // close connection here
            }

        }
    });
    myConnection.start();

Answer 3

en J2ME, le fonctionnement du réseau est mis en fil séparé.
u Placez le module de réseau dans un fil séparé.Si U placez le module de réseau dans le fil séparé, puis le message suivant n'est pas apparu.

Warning: To avoid potential deadlock, operations that may block, such as 
 networking, should be performed in a different thread than the 
 commandAction() handler.

en J2ME (Sun / Oracle qui est propriétaire de J2ME) donne quelques limitations.Pour Sécurité Certains API ont besoin des certificats de parti de confiance. Pour ce faire, certains mobiles demandent à l'utilisateur une autorisation lorsque l'utilisateur clique sur Oui, alors il autorisera,Sinon, cela ne permettra pas.
Les éléments suivants sont les membres de l'API sous ces scénarios sont de la fileconnection (lecture / écriture à fichier) API, httpconnection, httpsconnection, etc.
u Vérifiez votre périphérique si c'est la prise en charge du certificat auto-signé.Si est le support signifie que vous utilisez un certificat auto-signé.
Le certificat de fête de confiance est coûteux. Le coût minimum est de 10000 Rupppees par an.Les fournisseurs de partis de confiance Thawte, Verizon, Semantec, etc.