Séparation de la vue et du contrôleur #55
Jep
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Actuellement aucune réflexion de design n'a été faite.
Seule la partie modèle est séparé par la force des choses avec la base de données.
Mais la logique du jeu (le contrôleur) et la vue (activité, bouton, fragment) sont mélangés.
Plusieurs information nécessite une séparation.
Un objet Story qui contient la logique de l'histoire (takeLead etc.) et qui accède à la base de données elle même.
Un objet (À réfléchir encore) pour contenir les données du MainUser, son username récupéré partout inutilement etc.
La vue ne peut utiliser le modèle directement que pour lire les données. Voir MVC modèle:
https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur
Après ce commit la gestion de la Story est pas mal.
Toute la story est chargée et on dispose d'une bonne callback où faire les mise à jour de la vue à chaque changement. L'objet Story encapsule l'objet DbStory et la logique de la Story (exemple takeALead)
Ce qui reste à voir est la gestion des sentences.
Par exemple pour éditer une sentence, il faut en deux temps, récupérer la sentence, puis la set. Les get posent problèmes car demande une requête serveur et la gestion d'un listenner. Voir si on peut faire plus simple et déléguer un maximum de chose à la Story.
Il faut créer le même type d'objet pour la sentence. Elle peut être créée et renvoyée par la Story ou pas. Pour l'édition on disposerait ainsi de la callback comme pour la story pour faire les traitement à la mise à jour. Voir comment arrêter l'abonnement à la callback.
Les fonctions qui font un seul set dans la base de données sont maintenant faciles à utiliser et à créer.
Le problème n'est pas résolu pour pushSentenceQuery qui non seulement fait plusieurs set mais fait aussi des lectures. Le StoryHelper.setSentence ne peut pas retourner un Task (firestore) facilement en tout cas.
pushSentenceQuery allait trop loin dans le traitement, c'était à Story de le faire.
Factorisation de la classe Task pour utiliser la même dans Story et Sentence.
Création d'une classe mère pour Story et Sentence, Model.
Solution pour le get, en asynchrone, qui permet de récupérer la task de l'initialisation seulement.
Question postée sur stack overflow par Jep:
https://stackoverflow.com/questions/67829118/how-to-use-a-callback-in-specific-thread-in-order-to-wait-for-it-in-the-main-thr/67847276#67847276