Le Garbage collector est-il fait pour cela ?

Avant de parler de mes petites misères, un grand merci aux membres très éclairés, jahbromo et MrDuChnok sans lesquel je n'aurais pas réussi à décoller ...
Je sais maintenant faire ce dont j'ai besoin et que j'avais décrit dans un post que j'ai clôturé (Dessiner sur un Canvas) bien qu'il se termine sur une question non résolue ..pour moi évidemment !

Le dessin que j'ai besoin de réaliser est réactualisé par les infos du GPS. Ce dessin se réalise avec la méthode onDraw qui dessine donc sur un Canvas dans une classe monTrace qui "extends View"

Pour faire dessiner je crée une instance de la classe et je rajoute l'objet ainsi créé au LinearLayer prévu pour.
Soit :
monTrace traceHsi = new monTrace(null);
Llayout122.addView(traceHsi) ;

Avec l'émulateur ça marche (une seule fois du fait du pb qui fait que le simulateur de GPS envoie toujours des coordonnées nulles et que je n'ai pas bien pigé comment on contournait le pb).
Le code indiqué plus haut est placé dans le onLocationChanged et ça roule.

La question est, est-ce que cela va rouler de façon durable, que deviennent tous ces objets créés (environ un par seconde), est-ce que c'est le boulot du Garbage collector de nettoyer tout ça ?

Y-a-t-il un moyen de détruire l'objet avant d'en créer un nouveau ?

Merci de vos réponses ....

Citation:

---

protected void finalize()
Called by the garbage collector on an object when garbage collection determines that there are no more references to the object.

---

source : javadoc classe Objet

Edit : Le ramasse miette fait tous tout seul.
Mais si tu veux (quand même) appeler le garbage collector toi même pour un objet, appelle la méthode finalize() de cet Object.

Salut,

Citation:

---

Envoyé par Ivelios

Edit : Le ramasse miette fait tous tout seul.
Mais si tu veux (quand même) appeler le garbage collector toi même pour un objet, appelle la méthode finalize() de cet Object.

---

Non : la méthode finalize() n'est pas un destructeur et ne permet pas de détruire un objet !



@macRiaz : Le GC va bien gérer les objets temporaires. Toutefois si tu en génère vraiment beaucoup tu risques de lui donner beaucoup de travail.

a++

Bonjour et merci pour vos réponses ....

Le fait que le GC ait trop de boulot est bien ce qui m'inquiète. Je n'ai pas de mobile ANDROID sous la main pour voir l'effet produit dans la vraie vie.

La seule façon de procéder que j'ai trouvé pour redessiner mon tracé à chaque fois que onLocationChanged permet de récupérer de nouvelles valeurs GPS, est de recréer une instance et donc un objet par seconde.

J'ai fait fonctionner une (pseudo) boucle onDraw / invalidate() mais avec des données qui sont calculées dans la boucle elle-même. Mon problème consiste à relancer le onDraw avec un évènement qui intervient en dehors de cette boucle ...

Je n'ai pas trouvé ... pour le moment...

Question subsidiaire : quelle est la méthode qui indroduit un délai (temporisation). J'ai trouvé plein de trucs pour faire des animations mais android: delay s'utilise dans les définitions xml.

Je n'ai pas testé ton code sur mobile, mais une des règles pour le dév mobile (android, iphone, wimo, etc) c'est de minimiser les allocations mémoires. Donc là c'est pas vraiment respecté ;)

Qu'est ce qui t'empêche de réutiliser l'instance de ta classe déjà créé ? Pourquoi tu fais pas des getters / setters pour modifier les données de ta classe "monTrace" ?
(au passage, il est généralement conseillé de mettre une majuscule sur la première lettre du nom de ta classe )

Oui, MrDuChnok, visiblement, je me fais des noeuds dans la tête pour rien !!!

Je n'ai qu'une seule activity, dans laquelle se trouve la classe qui dessine (méthode onDraw) et la private class MyLocationListener implements LocationListener avec sa méthode public void onLocationChanged(Location loc)

La classe qui dessine est instanciée une seule fois dans le on create ce qui provoque le dessin avec les données initiales (en dur).
Quand onLocationChanged est activée, les valeurs servant au dessin sont modifiées (dans la méthode onLocationChanged) et le dessin de met à jour ... Plus bête tu meurs ! Enfin, je crois....

Je ne suis pas certain que cette façon de programmer respecte le pur esprit OO et les principes de l'encapsulation, mais, si cela marchait comme cela je pourrais approfondir et trouver une voie plus élégante ...

Il y a un bug connu concernant le simulateur du GPS. Comme il envoie toujours Lat et Lon avec une valeur zéro, la détection de changement de position ne marche qu'une fois .... donc il est difficile d'aller dans les coins pour faire les vérifications.

Dès que je trouve le moyen de contourner le bug je pourrais avancer un peu plus encore ... s'il y en a un qui sait, je suis preneur, of course.

Merci d'avance.

Citation:

---

Envoyé par macRiaz

Il y a un bug connu concernant le simulateur du GPS. Comme il envoie toujours Lat et Lon avec une valeur zéro, la détection de changement de position ne marche qu'une fois .... donc il est difficile d'aller dans les coins pour faire les vérifications.

---

Je sais pas si ça répond a ton problème mais j'avais lu ça sur les blogs java : http://blog.developpez.com/android23...-sdk/#more8494

Tu peux mettre les sources de ton projet ici ?
tu fais un zip de toutes tes sources et tu les postes.
Demain matin je regarde ça et je te poste une refonte plus cohérente si tu veux.

Oui, merci Uther j'avais vu ça, mais j'ai regardé de plus près maintenant que j'en ai vraiment besoin !

Donc ça marche ! Mais il y a quelques bizarrerie notées dans le lien que tu indiques, à savoir une petite différence entre les coordonnées saisies dans le terminal et les coordonnées récupérée par le programme (et que je fais afficher pour contrôle).
Et le rafraîchissement du dessin semble se faire correctement. Maintenant, il n'y a qu'un essai pour de vrai qui peut permettre d'être sûr que cela marche vraiment.

@ MrDuChnok, je n'aurais pas osé demander ! Je zippe le projet et je l'envoie.

Merci encore ...

@ MrDuChnok, voilà la chose ...

Et voilà c'est corrigé, et testé sur mon mobile (android 1.5)

J'ai pas corrigé tous le code, juste réassemblé les classes pour que tu repartes sur quelques choses d'un peu plus sain.
Essaye également de respecté les conventions de nommages des packages, des classes, des attributs, etc, ça facilite grandement la reprise d'un projet ;)

(mais sinon joli dessin pour la boussole :ccool:)

Le Garbage Collector fonctionne très bien, mais il faut faire en sorte qu'il tourne le moins possible. Un passage de GC c'est minimum 100ms, et cela est très perceptible par l'utilisateur si cela arrive pendant une animation ou une action utilisateur.

MrDuChnok, comment dit-t-on merci en JAVA ?

J'ai quelques heures à passer pour comprendre cette re-structuration mais je sens la mine d'or !

Si tu as pu faire l'installation sur ton mobile du devrais pouvoir vérifier si la vitesse et la route suivie, ainsi que la distance et le cap à prendre pour rejoindre l'aérodrome de Cholet (en dur !) sont cohérents avec la réalité.

Ce qui est dessiné n'est pas une boussole, c'est un HSI (Horizontal Situation Indicator), qui est un instrument qui regroupe toutes les informations utiles à la conduite d'une navigation (en avion) ...
La rose (similaire à celle d'un compas) indique la route suivie, la petite aiguille triangulaire, la route à suivre pour rejoindre le Way Point actif et la grande aiguille la direction de la route à suivre (celle entre deux WP ou celle qu'on veut adopter pour arriver sur un WP).
Pour être complet, il faudra ajouter le CDI (Course Deviation Indicator) qui comme son nom le fait supposer, indique l'écart (en distance) que l'on a par rapport à la route théorique.

Voilà, chacun ses vices, moi c'est les petits avions, qui en a entrainé un autre, la programmation des ordinateurs ...!

Citation:

---

Mais il y a quelques bizarrerie notées dans le lien que tu indiques, à savoir une petite différence entre les coordonnées saisies dans le terminal et les coordonnées récupérée par le programme (et que je fais afficher pour contrôle).
Et le rafraîchissement du dessin semble se faire correctement. Maintenant, il n'y a qu'un essai pour de vrai qui peut permettre d'être sûr que cela marche vraiment.

---

Dans le tuto, j'explique comment corriger les différences entre les coordonnées saisies et celles reçues, ainsi que le problème du "un essai".

As tu réussis à suivre le tuto ou bien tu as rencontré des problèmes ?

Bonjour nicodr23,

Oui, ton tuto m'a bien aidé, il m'a surtout décidé et permis d'utiliser les commandes via le terminal ....
Je n'ai pas compris les raisons des petits écarts entre coordonnées envoyées et coordonnées reçues .. mais je n'ai pas creusé ...

Par contre je suis tombé sur une autre anomalie. Quand on envoie une NMEA sentence (avec la commande geo nmea). Elle est parfaitement décodée, mais ça ne marche qu'une fois, l'émulateur reste sourd à toutes les autres sollicitations, y compris geo fix.

A suivre ...

Citation:

---

Je n'ai pas compris les raisons des petits écarts entre coordonnées envoyées et coordonnées reçues .. mais je n'ai pas creusé ...

---

C'est décris. c'est du à un problème de langue sous XP. Faut juste rajouter une options dans le fichier de lancement d'eclipse.

Pour NMEA je sais pas. je regarderai si j'ai le temps et peut être compléter le tuto.

Bonsoir,
Je n'avais pas compris cela. Je pensais que le problème de localisation (, à la place du .) causait l'envoi de coordonnées nulles. Et je ne vois pas le lien qu'il pourrait y avoir avec ces petites erreurs ...
Sous XP on peut tout craindre (!), mais j'ai le même problème avec mon MAC (Snow Léopard) .....