Discussion :

[Minicalion]

Bonsoir tout le monde,

Dans l'application que je développe, j'ai:
- Un model, basé sur le DP Singleton
- Une vue, représente le model, et écoute aussi le/les changements du model
- Un objet héritant de AsyncTask<...> travaillant avec le modèle.

Mon modèle permet, par le biais de méthode, de modifier son contenue, et chaque modification entraine l'appel au méthode d'écoute. Or, vue que l'AsyncTask modifie le contenue, celui-ci va aussi faire appelle au méthode d'écoute, et de ce fait appelle à des méthodes réservé au Thread UI, et ça ce n'est pas permis .

Je pense que ce problème découle d'une mauvaise conception de ma part, j'essaye de mettre en place un DP MVC simplifié, il n'y a que le modèle et la vue, la vue se charge des contrôles. Je pense que mon implémentation de ce DP m'a fait aboutir à une mauvaise méthode de synchronisation entre ma vue et mon modèle.

Dans le fichier word mis en pièce jointe, c'est un schéma représentant un exemple d'interaction entre les objets qui posent problème, cela peut vous aider à comprendre.

Je cherche donc un moyen de contourner ce problème.

Merci d'avance pour votre aide!

[Feanorin]

Bonjour

Or, vue que l'AsyncTask modifie le contenue, celui-ci va aussi faire appelle au méthode d'écoute, et de ce fait appelle à des méthodes réservé au Thread UI, et ça ce n'est pas permis .

réservé ?

J'ai un peu de mal a voir toutes les interactions, je comprends le principe, et surtout ce qui te pose problème. Est ce que tu aurais un exemple ?

[Minicalion]

Bonjour Feanorin,

En fait, de manière plus simple, mon application aboutit à l'appelle de View.invalidate(), par le biais de mon AsyncTask, Or selon la documentation :

Invalidate the whole view. If the view is visible, onDraw(android.graphics.Canvas) will be called at some point in the future. This must be called from a UI thread.

Mais si j'avais lu jusqu'au bout, j'aurais vue:

To call from a non-UI thread, call postInvalidate().

Donc voila, lecture trop rapide de ma part, mais problème résolue en utilisant postInvalidate() en lieu et place de invalidate().

Merci!

[Feanorin]

Ou passer par un runOnUiThread ou par un Hanlde (message) également.

Personnellement je préfère l'Handle car par cette méthode on peut centraliser toutes les modifications de l'UI depuis le Thread UI et non pas un peu dans chaque Thread

[Minicalion]

Je pouvais effectivement utiliser runOnUiThread, mais cela ne me plaisait pas trop dans l'idée car l'affichage de ma vue ce fait dans le Thread UI, mais mon objet AsyncTask représente un niveau logique indépendant de la vue (c'est un solveur de sudoku) donc pour moi il fallait que les deux soit bien distinct.

Concernant l'Handle, il permet en effet d'envoyer des messages, mais entre thread seulement si j'ai bien compris? Et du coup, là encore dans mon esprit la synchronisation/mise à jour des donnés ne devais se faire qu'entre mon modèle et ma vue. Ce n'est pas au solveur d'informer la vue que des données ont été modifié (Principe de la responsabilité unique je crois ).

Et dans les fait, ce n'est pas vraiment une modification de l'UI que je fait, mais une simple mise à jour des données à afficher (en l’occurrence les chiffres au sein de ma grille de sudoku pendant la résolution). Et cette partie sera par la suite optimisé en ne mettant à jour uniquement ce qui est nécessaire.

Donc cette méthode m'a semblé la plus adaptée. Je te remercie pour ses informations Feanorin, qui pourront m'être utile dans mes futurs développement .

[Feanorin]

Et dans les fait, ce n'est pas vraiment une modification de l'UI que je fait, mais une simple mise à jour des données à afficher

Donc c'est bien une modification de l'UI.

pour le Handler on aurait pu aussi le faire avec un Listener ce qui serait plus propre vu ta demande.

Après le postInvalidate() fais le boulot .

[Minicalion]

Oui le postInvalidate() fait le boulot, mais tu m'intéresse là!

Si j'ai bien compris, il est possible de gérer le Handle au sein de mon modèle, ainsi à chaque modification le modèle envoie le/les message(s), et du coup chaque thread voulant écouter le modèle n'auront plus qu'à gérer leur propre liste de message.

En effet, cela me paraît bien mieux, et surtout plus en adéquation avec les principes de la P.O.O que la simple utilisation de "callback".

De plus, mon modèle est à instance unique, donc les threads auront toujours accès à la version à jour, et afin d'éviter que l'UI ne se mettent à jour quand c'est inutile, possible accumulation de message si deux ou trois thread modifient le modèle avant la maj UI, il suffit que je vide la queue à chaque mise à jour de l'UI.

Bon ok, faut bien l'admettre, bien que l'on reste dans une problématique similaire à celle de départ, on commence à s'écarter de ma question initiale, d'autant plus qu'elle est résolue, mais là je dois avouer que tes idées/remarques sont extrêmements intéressantes!!
D'ailleurs, si tu en as d'autre, n'hésite surtout pas!!!!

En tout cas, merci beaucoup Feanorin!!

[Feanorin]

Si j'ai bien compris, il est possible de gérer le Handle au sein de mon modèle, ainsi à chaque modification le modèle envoie le/les message(s), et du coup chaque thread voulant écouter le modèle n'auront plus qu'à gérer leur propre liste de message.

Exactement, tu as un tutoriel sur les Handlers :
http://mathias-seguy.developpez.com/...async_memleak/

Pour les listener
http://rom.developpez.com/java-listeners/

En effet, cela me paraît bien mieux, et surtout plus en adéquation avec les principes de la P.O.O que la simple utilisation de "callback".

De plus, mon modèle est à instance unique, donc les threads auront toujours accès à la version à jour, et afin d'éviter que l'UI ne se mettent à jour quand c'est inutile, possible accumulation de message si deux ou trois thread modifient le modèle avant la maj UI, il suffit que je vide la queue à chaque mise à jour de l'UI.

Yep . A toi de savoir si cela est pertinent de louper des messages. Après au pire tu peux faire x Listener ou Handler.

les Observeable sont également intéressant :
http://developer.android.com/referen...bservable.html

Observable is used to notify a group of Observer objects when a change occurs. On creation, the set of observers is empty. After a change occurred, the application can call the notifyObservers() method. This will cause the invocation of the update() method of all registered Observers. The order of invocation is not specified. This implementation will call the Observers in the order they registered. Subclasses are completely free in what order they call the update methods.

[Minicalion]

Bonjour Feanorin,

Encore merci pour toutes ses informations, je n'ai pas mit en place l'Handler pour le moment, mon développement doit avancer, je compte le présenter demain à des personnes pour un emploi, du coup j'essaye d'avancer un maximum, histoire d'avoir quelques choses de potable à montrer .

En tout cas, cette méthode sera implémenter par la suite, lorsque j'aurais un peu plus de temps pour bien tout comprendre et la mettre en place correctement.

Encore merci, je suis content d'avoir posté, j'ai appris plein de choses .

Bonne journée!!