Discussion :

[alvandar]

Bonjour à tous,

Etant en grande discussion et en désaccord avec mes partenaires sur ce point, j'aimerais votre avis.
Je ne vois aucun intérêt d'appliquer le modèle de conception MVC pour une petite application android (5 classes à tout casser avec 2 activités). Je trouve que cela alourdi le code et dans la mesure ou on peut gérer les événements directement dans les activités il faut s'en passer. Une classe qui s'écoute, je ne vois pas ou est l'hérésie
Eux me soutiennent qu'il FAUT une classe controler pour gérer tous les événements.
Perso je trouve ça absurde. Avec deux activités, c'est encore gérable je pense, mais avec 6 ou 7 ca risque vite d'être une monumentale usine à gaz, non ?

Vous en pensez quoi ? Comment faites vous au quotidien ? Et pourquoi faites vous ces choix ?
Merci beaucoup.

[Hizin]

Je n'aime pas que les Fragment ou Activity implémentent un listener de toucher, donc je préfère créer une classe interne anonyme, ou une classe réelle si la même logique est utilisée et factorisable ou si la classe interne est trop longue/complexe.
Je trouve que ce n'est de la responsabilité de la classe, mais du composant réagissant à l'événement (bien sûr, dans le cas de vue custom, c'est différent). Après, je n'aime pas, mais ça ne me choque pas non plus.
Les listeners mal foutus long comme des bras avec des tests de "qui m'a appelé et qui doit recevoir la suite" sont une abomination sans nom.

Un seul contrôleur pour toute une application, par contre, je trouve que c'est un défaut de conception, et que ça va même à l'encontre de la volonté du MVC. Un Design Pattern (dans ce cas, un méta pattern d'ailleurs) est un guide pour donner des pistes, absolument pas une Sainte Pratique à Suivre À La Lettre.

J'ai repris une application utilisant à foison les fragments et avec une activité servant de contrôleur général... ce qui a résulté en de gros problèmes d'abstraction, un couplage abominable entre Fragment et Activité, des trucs immondes comme des suites de "instanceof" pour savoir ce qu'il fallait faire (et là, c'était facilement évitable) et des responsabilités uniquement mises dans ce "contrôleur", résultant en de gros problèmes lors des réceptions des WS.

Il est possible de factoriser des contrôleurs pour des vues relativement similaires... mais pour des vues bien différentes tapant des modèles différents... ça revient, pour moi, à tout mettre en global.

Après... beaucoup de prototype, PoC et de "petites applications" ont rencontrés un franc succès et sont ensuite devenus des mastodontes dont la refonte pour clean le code a toujours été remise à plus tard... s'il est possible d'éviter ce genre de chose assez facilement en ne perdant pas de temps, autant le faire, à mon sens.

[CrikTeCroque]

Je plussoie Hizin sur le fait que les modèles ou pathern sont surtout des façons de faire reconnues comme solide, cela ne doit pas devenir pour autant une obsession.

L'avantage de se baser sur MVC (puisqu'il s'agit de lui ici) c'est que cela guidera ta conception, car tu seras toujours en train de te demander est ce que cette classe ci a un pouvoir de décision/action? (et si oui, est ce bien ce que je veux?). Est-ce que l'utilisateur peut interagir avec elle? Est-ce que je vais m'en servir à plusieurs endroits? etc, bien sûr

Tu parles d'un listener sur un Activity. Ce n'est pas du tout incompatible avec MVC. Ton activité est bien le contrôleur, c'est elle qui charge la vue et l'affiche.
Le listener apporte à l'activité les méthodes nécessaires à l'écoute de la vue, mais ce que tu fais des différents évènements est défini dans ton activité.

Tu peux aussi implémenter un pathern Observer sans sortir du cadre de MVC...

En tout cas si tu essayes de respecter une logique MVC, ton code sera plus clair et surtout comme l'a dit Hizin, il pourra grandir par la suite sans que ça devienne fouillis

[atha2]

Sur ma dernière application pour le coeur de l'application (j'ai d'autre Activity pour des trucs annexes (gestion de préférence, wizard de création)), j'ai utilisé une seule Activty et peut-être une 20aine de Fragments que j'affiche en même temps ou que je replace par un autre en fonction des choix de l'utilisateur.
Chaque Fragment, fonctionne comme contrôleur (l'Activity étant le contrôleur principale) :

• créer la vue (à partir du XML)
• réagit on événement de l'UI
• met à jour le modèle qui peut-être selon les cas un ensemble de variables d'instance du Fragment, un objet Model variable d'instance du Fragment, le modèle de l'Activity, le modèle d'un autre Fragment

Pour le changement de vue, je me suis créé une classes Routeur qui pour un id (<=> url) affiche un nouveau Fragment.


Le couplace entre l'Activity et les Fragments (et surtout entre les Fragments) peut en effet poser problème. Pour résoudre ça j'utilise un bus d’événement (Otto) commun à tous les Fragments et à l'Activity.
Le Fragment/Activity s'enregistre auprès du bus dans le onCreate, se des-enregistre dans le onDestroy (au passage ou évite tout problème de fuite de mémoire).
Si un Fragment est intéressé par disons l'historique des scores de de l'utilisateur, on ajoute au Fragment :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
@Subsribe
public void onScoreHistorique(ScoreHistorique scoreHistorique){
//affichage de l'hisorique des scores.
}

et ailleurs (n'importe où dans le code (Service, Activity, Thread, Fragment)) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ScoreHistorique scoreHistorique = PreferenceManager.loadScoreHistorique();
bus.post(scoreHistorique);

et c'est tout !

Pour revenir à ma gestion du switch de fragment, dans mon code, j'ai juste à écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
bus.post(FragmentId.Score);

et directement mon Routeur change la vue.

A noter que dans mon cas j'ai était obligé de modifier Otto parce que voulais que, quelque soit le thread du "posteur", que l’événement arrive dans processus de l'Activity. Ce qui n'est pas le cas de base avec Otto.

PS : et j'ai pas de instanceof dans mon code et les seuls listeners que j'ai sont des listeners de composants graphiques donc j'ai pas vraiment le choix.

[alvandar]

Excusez mon ignorance en matière d'android car je débute (en fait nous débutons tous dans notre formation) mais qu'est ce que les fragments ? Le prof a peut être omit de nous expliquer un truc important ?

Merci de vos réponses en tout cas. J'en retire que le modèle MVC n'est pas à appliquer forcément à toutes les applis que l'on crée, ce qui a été le cas tout au long de la formation ( le prof ne jure que par ça) que ce soit en J2SE, J2EE et certains pro que je connais m'ont dit que certes le mvc est utile mais que c'est une "connerie" de l'adapter à tout.

Edit : J'en profite pour poser une autre question : Quel est le moyen le plus simple pour sérialser / désérialiser un objet sous Android ? Parcelable ? ou XMLSerializer ? Si des fois vous avez des tutos clairs la dessus je suis preneur Merci !

[Hizin]

Les Fragments sont devenus incontournables depuis Android 4.0, soit bientôt deux ans. Ils sont disponibles dans la bibliothèque de support et sont disponibles jusqu'en Android 1.6 (bon... cibler 1.6 de nos jour, c'est du masochisme à mon sens).

Ce sont des bouts de vues permettant de gérer plus facilement le multi-écran, et permettant un "meilleur" découpage des responsabilités.

Pour la sérialisation, celle de Java fonctionne. Le moyen préconisé par Google est le Parcelable, lourd à implémenter (des aides automatisées existent : plugin IDEA, http://devk.it/proj/parcelabler/ ...).

[nicroman]

Je vais y aller de mon grain de sel


MVC est un modèle adapté parfois à certaines architectures, mais pas de partout, loin de là. Il reste que dans la "philisophie" de découpage, il est toujours valide: M=données, V=présentation des données, C=gestion des actions de l'utilisateur.
Même en J2EE il est intéressant d'avoir: une couche d'accès aux données (Sérialisation, DAOs, ...), un layer "API" qui ne fait aucune présentation (sauf de formatage) et donne accès aux données mais aussi aux "fonctions" possibles sur ces données... un layer "présentation" qui fait une présentation HTML des données de l'API, et envoie à l'API les commandes de l'utilisateur.

Sous Android, le point d'entrée d'une application est toujours l'activité.
Mais contrairement à d'autres OS, les applications fonctionnent "ensemble"... Par exemple, un logiciel de traitement d'image ou de partage de photos peut certes avoir une activité de "capture" (directement depuis l'appareil), mais se *doit* aussi de répondre à l'action de partage sur des photos. Ainsi, l'application pourra être lancée indifféremment depuis l'appareil photo, la galerie, ou tout autre application ayant des images à disposition !

C'est ce qui fait la force d'Android.

Et c'est pourquoi je suis un peu dubitatif à "une seule activité" et 40 "fragments".
L'intérêt des fragments c'est d'être partagés entre plusieurs activités... Si un fragment n'a de sens que dans une seule activité, le fragment EST une activité. D'autant que refaire la gestion du back/home devient assez rapidement complexe !

[atha2]

Et c'est pourquoi je suis un peu dubitatif à "une seule activité" et 40 "fragments".
L'intérêt des fragments c'est d'être partagés entre plusieurs activités... Si un fragment n'a de sens que dans une seule activité, le fragment EST une activité.

Pour moi l’intérêt est de découper mon problème en problème plus simple, je me sert des fragments comme sous contrôleur.
Après il y a peut-être des moyens plus propre mais comment gérerais-tu un application :
-qui as plusieurs écrans tous des listView
-dont les actions sur chaque items ne sont jamais les mêmes selon les écrans
-où la listView peux-être MAJ (CRUD) à n'importe qu'elle moment (réponse du WS reçue...).

?

Je ne sais pas si les fragments sont réellement prévus pour ça mais dans mon cas ça m'a permit de simplifier le développement de mon appli

D'autant que refaire la gestion du back/home devient assez rapidement complexe !

J'avoue un peu avoir galéré à gérer le Back (je débutais avec les fragments). Mais un fois mis en place, c'est générique (je peux ajouter autant d'écrans que je veux sans modifier la gestion du Back). Pour le Home, que veux-tu gérer exactement ?

[nicroman]

Il y a deux navigations parallèles dans Android:
* Le "back" (bouton retour hardware ou non).
* Le "up" (dans l'action bar l'icône).

Le multiplexage des deux est compliqué si on n'utilise pas le code "par défaut".

Pour moi l’intérêt est de découper mon problème en problème plus simple, je me sert des fragments comme sous contrôleur.
Après il y a peut-être des moyens plus propre mais comment gérerais-tu un application :
-qui as plusieurs écrans tous des listView

Dans ce cas, probablement une simple activité de liste.

-dont les actions sur chaque items ne sont jamais les mêmes selon les écrans
-où la listView peux-être MAJ (CRUD) à n'importe qu'elle moment (réponse du WS reçue...).

Héritages d'une activité de base... ou paramètres dans le bundle de création etc....

N'ayant pas les détails je ne sais pas ce qu'il vaut mieux... Mais ce qui est sur c'est que le fragments ont été faits pour être partagés entre plusieurs activités (et ainsi éviter de réécrire le même code dans plusieurs activités).

[atha2]

Il y a deux navigations parallèles dans Android:
* Le "back" (bouton retour hardware ou non).
* Le "up" (dans l'action bar l'icône).

Le multiplexage des deux est compliqué si on n'utilise pas le code "par défaut".

J'ai bien lu le guide pour la navigation qui explique la différence entre back et up, mais l'appli GMail n'en tiens pas compte. Elle le faisait à un moment, mais la dernière fois que j'ai vérifié dans GMail back <=> up, donc bon...
De toute façon, dans mon appli back fait toujours up , la navigation est un parcours d'arbre dans lequel on ne peux pas accéder aux frères sans passer par le parent.
J'en prend note pour une prochaine appli.

Dans ce cas, probablement une simple activité de liste.

Héritages d'une activité de base... ou paramètres dans le bundle de création etc....

J'ai besoin d'avoir des données communes entre chaque fragment donc c'est pratique de pouvoir faire getActivity().donnéeDeMonActivity dans mes fragments (je pourrai utiliser la classe Application, mais elle contient déjà des données dont la portée est plus globale que celle de l'Activity).
En plus, mon Activity contient 3 onglets. Le premier est celui où j'affiche toutes les écrans, le 2ème et 3ème étant l'Help et l'About (je sais ça semble foireux d'utiliser des onglets pour ces écran mais je n'ai pas le choix). Donc utiliser des Activity pour chaque écran me forcerait à recréer à chaque fois tabhost+viewpager. Ça ne me paraissait pas forcément une bonne idée.