Forum Programmation.java Gestion d'un timer en Java/Android

Posté par  .
Étiquettes : aucune
1
28
déc.
2011

Bonjour,

Je débute en Java, j'ai une bonne expérience en programmation d'interfaces graphiques C++/Qt, et je cherche à programmer un chronomètre en Java pour un Smartphone Android.

Avec Qt en C++, pour faire cet objet graphique, je ferai un QWidget avec un timer intégré, qui génère un signal toutes les millisecondes, et un slot réceptionne le signal pour mettre à jour l'affichage du temps écoulé.

Mais en Java, il n'y a pas de Signal/Slot.
Il y'a un objet Timer qui permet d'effectuer une tâche toutes les millisecondes. D'après la doc cela créé un Thread qui s'éxécute périodiquement.

Etant dans un Thread on ne peut pas toucher aux objet graphiques du thread principal. A part peut être avec la fonction Android "runOnUiThread" à l'intérieur du Thread du timer.
Mais c'est un peu lourd à coder.

Il y'a un objet chronomètre dans la bibliothèque Android, mais qui ne convient pas. Il utilise l'objet Handler qui envoie un message avec la fonction "sendMessageDelayed" qui s'éxécute alors à répétition avec 1 ms de retardement. Le mot clé "synchronized" est utilisé pour mettre à jour le texte graphique.

Y'a t-il un objet ou d'autres moyens qui peuvent générer un événement toutes les millisecondes pour actualiser l'affichage du temps écoulé ?

  • # Handler

    Posté par  . Évalué à 1.

    J'ai trouvé un exemple d'une barre de progression en Java/Android :

    http://www.mkyong.com/android/android-progress-bar-example/

    La méthode utilisé est encore les "Handler" de la bibliothèque d'Android, qui permettent d'effectuer une action toutes les X millisecondes :

     // Update the progress bar
progressBarHandler.post(new Runnable() {
 public void run() {
 progressBar.setProgress(progressBarStatus);
 }
});

    Je comprend pas trop le fonctionnement, au niveau de "post" en particulier.

    D'après la doc sur Handler on peut envoyer soit un message soit un code exécutable via Handle.

    Un peu bizarre je trouve ..

    • [^] # Re: Handler

      Posté par  (site web personnel) . Évalué à 1.

      Vu de loin çà ressemble au principe des run loops dans le monde iOS : en gros tu as un thread dans lequel tu veux traiter des messages (ou exécuter du code) lorsque surviennent divers types d'évènements (données via le réseau, échéance d'un timer, etc...).

      Ce message ou ce code, en l'occurrence, c'est ce qui est posté. Il est stocké dans une file et sera traité de manière asynchrone, donc pas forcément tout de suite.

      C'est donc particulièrement adapté pour les cas classiques où tu as un thread pouvant faire des modifications graphiques, mais potentiellement plusieurs threads pouvant générer des évènements entrainant des modifications de la dite interface graphique.

  • # System.currentTimeMillis()

    Posté par  (Mastodon) . Évalué à 2.

    A première vue, en lisant le descriptif de ton problème, la manière dont il est posé, on dirait que tu cherches à voir les réponses pour les réponses ;-) Mais je tombe dans le panneau quant même.

    objet chronomètre (...) mais qui ne convient pas. Il utilise l'objet Handler

    DateUtils ?

    • [^] # Re: System.currentTimeMillis()

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 30 décembre 2011 à 11:02. 

         private void init() {
        mBase = SystemClock.elapsedRealtime();
        updateText(mBase);
    }



      private synchronized void updateText(long now) {
        long seconds = now - mBase;
        seconds /= 1000;
        String text = DateUtils.formatElapsedTime(mRecycle, seconds);
    }

      ?

  • # Threads

    Posté par  . Évalué à 0.

    Ce qui m'étonne c'est qu'on est obligé d'utiliser un Thread pour chaque objet graphique a actualiser / annimer.

    Dans Qt que j'ai pas mal étudié, pour faire une barre de progression, une animation etc... on utilise l'objet QTimer.

    Et QTimer n'utilise pas de Thread. C'est un objet pris en compte dans la boucle d'évenements QEventLoop de l'application. Cette boucle d'évenement, lorsqu'elle utilise l'appel système select() pour attendre les evenement de Xorg, doit prendre en compte les QTimers en ajoutant un timeout dans select. Ensuite avec le mécanisme de Signal/Slot de Qt, les slots d'objets liés au signal du QTimer sont alors appelés.

    On fait donc avec Qt des objet animés (Barre de progression etc ...) sans qu'il n'y ai de Thread créés.

    Dans Java Swing, il y'a l'air d'y avoir la même chose que sous Qt.

    javax.swing.Timer :

    "Fires one or more action events after a specified delay. For example, an animation object can use a Timer as the trigger for drawing its frames."

    Mais dans l'API Java d'Android, Il n'y pas Swing.

    Et pas d'autres objets Timer que Java.utils.Timer (Timer lié a un thread TimerTask).

    Le problème est que en terme de performances ce n'est pas génial d'avoir plein de threads dans une application.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.