Modèle - Navigation entre les activités

Bonjour à tous,

Cela fait un bout de temps que je cherche réponse à ma question (peut être la réponse est déjà présente dans le forum et a été formulée autrement, auquel cas, je m'en excuse d'avance).

En fait, cette question est plutôt une question "Best practice" dans la navigation entre les activités et non pas forcément technique.

Dans la plupart des documentations, j'ai bien compris que la solution la plus commune (au sujet de la navigation entre les activités) était d'appeler une activité à partir de la précédente dans l'ordre visuel de l'application.
Par exemple : LaPage1.java appelle LaPage2.java, LaPage2.java appelle LaPage3.java, LaPage3.java appelle LaPage4.java etc. (Bien entendu, j'ai bien compris aussi que LaPage2.java peut appeler LaPage2a.java et LaPage2b.java par exemple).

Selon mon expérience (et pas forcément la meilleure :p) dans le développement applicatif, j'imaginais plutôt le modèle suivant : Je crée une sorte de ActivityManager.java permettant de gérer la navigation entre les différentes activités.
Je m'explique (à partir de l'exemple précédent) : L'application démarre en appelant l'ActivityManager.java, l'ActivityManager.java appelle directement (sans intervention de l'utilisateur) LaPage1.java.
Lorsque l'utilisateur veut passer à LaPage2.java, LaPaga1.java appelle ActivityManager.java qui à son tour appelle LaPage2a.java (et ainsi de suite pour les autres pages).
Selon moi, cette conception offre l'avantage suivant : Toutes les navigations sont regroupés dans un seul et même endroit (ici ActivityManager.java).
Cela permet de rendre l'application plus flexible au niveau du code puisque si je veux rajouter ou enlever un maillon de la chaîne d'activités, il me suffit de modifier cette classe, de plus, il y a une meilleure visibilité de l’enchaînement des activités de l'application puisque tout le chaînage est finalement explicité dans ActivityManager.java (je n'ai pas besoin d'aller d'activités en activités pour voir qui appelle quoi).

Ma question est donc la suivante : Etant donné que je n'ai pas réussi à rencontrer cette pratique sur le web, je suppose qu'il y a plusieurs inconvénients qui m'empêchent d'utiliser cette solution (même si en pratique c'est faisable, je l'ai testée). Donc, quelles sont les inconvénients de ce procédé ? Il y a-t-il un procédé viable et équivalent à celui que je viens de proposer ? Il y a peut être quelque chose que je n'ai pas saisi dans le cycle de vie d'une activité... ?

Je vous remercie de tout cœur, d'avoir pris le temps de lire mon post !
Bonne semaine à tous !

Le problème c'est surtout de confondre "page" (donc "views" j'imagine) et activité...

Une activité est comme son nom l'indique une activité... Quand on appuie sur back, on en sort et on revient à l'activité précédente.
On peut y arriver directement (Intent public) ou non (Intent privé)

Perso, c'est comme cela que je concois une application:

J'ai des données... Que peut-on faire sur ces données ?
Créer/Modifier ? => bim une EditActivity
Lister/Choisir ? => bim une ListActivity
etc...

Prenons un exemple simple: j'ai X serveurs avec des listes de messages que je peux "voir":

A: Voir message est une activité (pas d'activité liée).

B: Lister les messages du serveur est une activité. Cliquer sur un message d'une activité permet de voir le message (A), ou de changer de serveur (bouton 'serveur')=> (D)

C: Modifier / Ajouter un serveur est une activité (pas d'activité liée)

D: Lister les serveurs est une activité, cette activité permet de lister les messages du serveur (B), ou d'éditer/supprimer ceux-ci (appui long), ou d'en rajouter (bouton +) (C)


Comment faire un "ActivityManager" dans ce cas ?
Maintenant je veux rajouter une option d'édition des message (depuis A ou B) comment fait-on ?

Si je rajoute un raccourci vers un serveur (intent public vers B) sir me bureau, que fait l'activity-manager ?

Dans ce type de cas, la gestion du bouton "back" est assez compliquée.

Cas typique : un ViewPager (ou assimilé) avec 2 pages. Le premier peut avoir une navigation en profondeur (i.e. : ouvrir d'autres fragments/activité le remplaçant), le second non.

Cas trivial, mais ici, on commence a gérer le bouton retour, et ça commence à devenir un peu moche/compliqué.

Sur un véritable cas avec pas mal de vues et des gestions/profondeurs qui s'appellent et se rappellent, ce n'est en rien trivial, et ça devient très très vite bordélique.

Bon, c'est gérable, et en faisant LA bonne archi, c'est aussi relativement facile. Par contre, c'est une vraie boîte de Pandore, pouvant facilement devenir spaghettis et un cauchemar à gérer (et pour toi, et pour les personnes reprenant ton code... surtout pour elles, en fait).

Tout d'abord, je vous remercie nicroman et Hizin d'avoir pris la peine de tenter de résoudre mon problème.

--- Pour nicroman ------------------------------

Comme tu le dis si bien nicroman, je pense faire trop de rapprochement entre la "page" et l'activité. En effet, travaillant avec des API Android 7, j'ai tendance à utiliser un layout par activité (les fragments n'étant pas encore présents). Du coup, pour moi, une activité = un layout (ce qui est loin d'être vrai, je le conçoit parfaitement).

Selon moi, le mécanisme est simple : l' "ActivityManager" réalise exclusivement des appels d'activités avec startActivityForResult(Intent, REQUEST_CODE). L'Intent contient les données à transférer à la prochaine activité à afficher, le REQUEST_CODE représente pour moi l'id de l'activité appelée.
[Pour faire une relation id<=>activité facile à comprendre, je réalise préalablement une énumération listant toutes les activités].
Je pense que tu l'as deviné, je reçoit le result avec onActivityResult(int requestCode, int resultCode, Intent data). où :
requestCode reste toujours l' id de l'activité préalablement appelée
resultCode est un code de sortie correspondant à l'action à entreprendre (exemple : 0 pour quitter, 1 pour passer à la page 1, 2 pour passer à la page 2)
data l'intent généré dans le code de l'activité

Avec ce méchanisme, la structure que tu m'as proposé est tout à fait envisageable. Sans compter l'action du back pour chaque activité, l'activité B et D contiendront 2 result différents.
Et si je veux faire une relation à partir de A ou B, rien de plus simple : je rajoute un nouveau result à l'activité, et, dans l'ActivityManager je pointerai ce resultCode vers la nouvelle activité d'édition de message (et l'intent contiendra bien entendu toutes les données nécessaire à l'identification du message concerné). L'avantage aussi de l'ActivityManager c'est qu'il peut contenir des variables privées communes aux activités de l'application (comme la variable currentMessage par exemple).
Et pour le raccourci vers le serveur, il suffit de faire la redirection nécessaire au premier chargement de l'ActivityManager.

Attention, je ne prétend pas avoir la science infuse, peut être que je vois les choses un peu trop simplement, auquel cas, n'hésitez pas à reprendre ce que j'ai dit :).

--- Pour Hizin ------------------------------
Je crois que tu as touché le point sensible de ce modèle : le bouton Back.
En effet, onBackPressed doit être systématiquement géré (sinon, si j'appuie sur le bouton Back, j'arrive sur l'ActivityManager et c'est moche...).
J'ai d'ailleurs volontairement contourné cette explication dans la réponse envoyée à nicroman...
C'est surtout cette question que je me posais au niveau performance : étant donné que j'appelle systématiquement des activity avec le bouton back, je créé forcément des activités supplémentaires (activités doublons) qui bouffent d'avantage de mémoire vive.

Exemple :

- Avec un modèle traditionnel entre activité1 et activité2:
activité1 démarre
*L'utilisateur demande activité2*
activité1 appelle activité2.
*L'utilisateur appui sur le bouton Back.*
activité 1 réapparait.

- Avec le modèle proposé :
ActivityManager démarre
ActivityManager appelle tout de suite activité1
*L'utilisateur demande activité2*
On retourne à ActivityManager
ActivityManager appelle activité2
*L'utilisateur appui sur le bouton Back.*
On retourne à ActivityManager
ActivityManager appelle une nouvelle instance d'activité1 (C'est là le problème... enfin peut être :) ).

Après, pour la clarté du code, si tu faits une correspondance id <=> activité avec une énumération et que tu commentes en début d'activité les correspondance entre l'action et le codeResult, je pense que tu peux t'y retrouver.

Merci encore !
J'attends vos critiques et/ou vos arguments :)

Pour être honnête, j'ai eu a reprendre deux applications fonctionnant de cette manière : une "activité maître" gérant beaucoup de chose.

Dans les deux cas : code non-commenté, un brin spaghetti par endroit, une foule de "instanceof", le bouton "retour" en véritable cauchemar, des activités intermédiaire lancé "pour faire une liaison" ne servant qu'à lancer un autre intent, des profondeurs de vues faisant planter l'application, une gestion de la stack des vues très... particulières, et une gestion de la stack mémoire très particulière aussi.

La (re)création n'est pas un problème (à mon avis), puisque c'est plus ou moins de cette manière qu'Android fonctionne. Par contre, avoir une activité générale implique qu'elle doive non seulement gérer les activités, les retour, la pile... mais aussi les références sur les activités qu'elle a déjà lancée, pour pouvoir facilement y revenir si l'application est quittée.

Le cas "toute les activités sont potentiellement un point d'entrée pour l'application" me semble problématique pour ce cas-là. Il est possible de le résoudre en faisant de l'activité maître l'activité à lancer obligatoirement, mais quid du sauvegarde du cheminement de l'usager ? quid de l'état des activités ?

Je pense voir où tu veux en venir Hizin.

Je pense avoir trop regarder l'application Android comme une application sur client lourd, au point d'en oublier l'essentiel : Une application téléphone est fortement sensible à être interrompu ou éteinte volontairement ou involontairement. La prise en compte d'une pile n'est pas forcément contraignante pour un pc (on s'attend facilement à devoir "tout recommencer" en cas de l'extinction soudaine de l'application) mais pour un smartphone ce n'est pratiquement pas envisageable. Si l'on applique un modèle tel que le mien on peut arriver à des comportements incohérents.

Néanmoins, je pense que le modèle peut être envisageable pour une application simple/linéaire (du genre "step by step" où les activités s'enchaînes de l'une à l'autre). Si l'on sait que notre application (ou ce module de l'application) gardera cette allure, ça ne posera pas de problème majeur.

J'en conclu donc que ce modèle peut être appliqué sur des applications ayant un fonctionnement particulier (et où l'on peut s'assurrer qu'il sera toujours identique dans le futur).
Dans la plupart des cas, et pour conserver une flexibilité maximale, il est préférable de garder un enchaînement d'activités de manière "traditionnelle" de cette forme-ci : http://developer.android.com/training/design-navigation/screen-planning.html
.
Ce design navigation est adapté aux cas les plus complexes.
J'en profite pour mettre aussi un deuxième lien traitant sur l'échange d'informations entre les activités (il me paraissait très complet et pourrait servir à ceux qui passent par ici) : http://www.vogella.com/articles/Andr...t/article.html

Je vous remercie pour les informations que vous m'avez apporté ! Bien entendu, même si le sujet est résolu, la discussion reste ouverte (on ne sait jamais, peut être que j'ai compris vos explications de travers ou, peut-être que finalement, si on fignole un peu ce design navigation, on peut arriver à quelque chose de convenable.

Enfin je vous remercie de m'avoir un peu plus ouvert l'esprit :ccool:. A très bientôt.