Au fil des ans, j'ai vu différentes implémentations du modèle de navigation Android. Certaines applications utilisaient uniquement des activités, tandis que d'autres activités étaient mélangées avec des extraits de code et / ou des vues personnalisées ( Affichages personnalisés ).

L'une de mes implémentations de modèle de fragment préférées est basée sur la philosophie 'One-Activity-Multiple-Fragments' (' Une-activité-plusieurs-fragments ”), Ou simplement le modèle de navigation de fragment ( Modèle de navigation de fragment ), où chaque écran de l'application est un fragment plein écran et la totalité ou la plupart de ces fragments se trouvent dans une activité.

Cette approche simplifie non seulement la mise en œuvre de la navigation, mais offre également de meilleures performances et vous offre donc une meilleure expérience utilisateur.

Dans cet article, nous explorerons certaines implémentations de modèles de navigation courants sur Android, puis présenterons le modèle de navigation basé sur des extraits de code. Un exemple d'application qui implémente ce modèle se trouve dans GitHub .

Un monde d'activités

Une application Android typique qui n'utilise que des activités est organisée dans une structure de type Tree (précisément dans un graphe orienté) où l'activité principale est initiée par le lanceur . Lors de la navigation dans l'application, un message ' pile arrière ”De l'activité qui est maintenue grâce au système d'exploitation.

Un exemple simple est illustré dans le diagramme suivant:

L'activité A1 est le point d'entrée de notre application (par exemple, elle représente un écran initial ou un menu principal) et à partir de ce point l'utilisateur peut naviguer vers A2 ou A3. Lorsque vous avez besoin de communiquer entre les activités, vous pouvez utiliser startActivityForResult () Ou vous pouvez partager un objet logique métier globalement accessible entre les deux activités.

Lorsque vous devez ajouter une nouvelle activité, vous devez suivre les étapes suivantes:

• Définir la nouvelle activité
• Enregistrez-le dans AndroidManifest.xml
• Ouvrez-le avec un startActivity () d'une autre activité

Bien que ce diagramme de navigation soit une approche assez simplifiée; mais cela peut devenir très compliqué quand vous avez besoin manipuler de pile arrière ou lorsque vous devez réutiliser plusieurs fois la même activité, par exemple lorsque vous souhaitez que l'utilisateur navigue dans différents écrans du didacticiel mais que chaque écran utilise la même activité comme base.

Heureusement, nous avons des outils pour ces cas appelés corvées et quelques guides pour un navigation de pile arrière approprié .

programmes c++ pour débutants

Puis, avec l'API niveau 11, les fragments sont arrivés ...

Un monde de fragments

Android introduit des extraits dans Android 3.0 (niveau d'API 11), principalement pour prendre en charge des dispositions d'interface utilisateur plus dynamiques et flexibles sur de grands écrans tels que les tablettes. Étant donné que l'écran d'une tablette est beaucoup plus grand que celui d'un téléphone, il y a plus d'espace pour mélanger et assortir les composants de l'interface utilisateur. Les extraits de code prennent en charge ces dispositions sans que vous ayez à gérer des modifications complexes de la hiérarchie des vues. En divisant la conception d'une activité en segments, vous pouvez modifier l'apparence de l'activité au moment de l'exécution et conserver ces modifications dans une pile d'activités gérée par l'activité. - citation de Google Guide API pour les fragments .

Ce nouveau jouet a permis aux développeurs de créer une interface utilisateur à plusieurs panneaux et de pouvoir réutiliser les composants dans d'autres activités. Certains développeurs adorent cela tandis que d'autres pas autant . L'utilisation ou non d'extraits de code est un débat populaire, mais je pense que tout le monde conviendra que les extraits de code ont apporté une complexité supplémentaire et que les développeurs doivent les comprendre correctement pour les utiliser.

Le cauchemar du fragment plein écran sur Android

J'ai commencé à voir de plus en plus d'exemples où les extraits ne représentaient pas seulement une partie de l'écran, mais l'écran entier était un extrait au sein d'une activité. Il fut un temps où j'ai vu une mise en page où chaque activité avait exactement un extrait de code en plein écran et rien d'autre, et la seule raison pour laquelle ces activités existaient était de stocker les extraits. Outre le défaut de conception, il y a un autre problème avec cette approche. Jetez un œil au diagramme ci-dessous:

Comment A1 peut-il communiquer avec F1? Ce qui se passe, c'est que A1 a un contrôle total sur F1, car il a créé F1. A1 pourrait passer un package, par exemple, dans la création de F1 ou il peut invoquer ses méthodes publiques. Comment la F1 peut-elle communiquer avec A1? Eh bien, c'est plus compliqué, cela peut être résolu avec un modèle de rappel / observateur où A1 souscrit à F1 et F1 notifie A1.

Mais comment A1 et A2 peuvent-ils communiquer? Comme expliqué ci-dessus, ils pourraient communiquer via startActivityForResult () .

Et maintenant la vraie question: comment la F1 et la F2 peuvent-elles communiquer? Même dans ce cas, nous pouvons avoir un composant de logique métier qui est globalement accessible et peut être utilisé pour transmettre des données. Mais ce composant n'équivaut pas toujours à un design sophistiqué. Et si F2 avait besoin de transmettre des informations à F1 plus directement? Dans un tel cas, avec un motif rappeler F2 peut notifier A2, puis A2 se retrouve avec un résultat et ce résultat peut être stocké par A1 qui peut notifier F1.

Cette approche nécessite beaucoup de code passe-partout et devient rapidement une source de Bugs , douleur et colère.

Et si nous pouvions nous débarrasser de toutes les activités et n'en conserver qu'une seule qui gardera le reste des fragments?

où coder c++

Modèle de navigation de fragment

Au fil du temps, j'ai commencé à utiliser le modèle 'One-Activity-Multiple-Fragments' dans la plupart de mes applications et je l'utilise toujours. Il y a beaucoup de discussions sur cette approche ou cette philosophie, par exemple ici Oui ici . Ce que j'ai manqué, c'est un exemple spécifique que je peux voir et tester par moi-même.

Regardons le diagramme suivant pendant un moment:

Maintenant, nous n'avons qu'une seule activité de conteneur et nous avons plusieurs fragments qui sont à nouveau dans une structure de type Tree. La navigation entre eux est gérée par le FragmentManager , cela a son pile arrière .

Linux est distribué sous quelle licence ?

Vous vous rendrez compte que maintenant nous n'avons pas le startActivityForResult () mais nous pouvons implémenter le modèle rappel / observateur . Voyons maintenant quelques avantages et inconvénients de cette approche:

Avantages:

1. Plus propre et plus facile à entretenir AndroidManifest.xml

Maintenant que nous n'avons qu'une seule activité, nous n'avons plus besoin de mettre à jour le manifeste à chaque fois que nous ajoutons un nouvel écran. Contrairement aux activités, nous n'avons pas à déclarer les fragments.

Cela peut sembler insignifiant, mais pour les applications plus volumineuses avec plus de 50 activités, cela pourrait améliorer considérablement la lisibilité du AndroidManifest.xml fichier.

Regardez le fichier manifeste de l'exemple d'application, qui comporte plusieurs écrans. Le fichier manifeste est très simple.

package='com.exarlabs.android.fragmentnavigationdemo.ui' >

2. Gestion centralisée de la navigation

Dans mon exemple de code, vous remarquerez que j'utilise NavigationManager qui dans mon cas, est injecté à chacun des fragments. Ce gestionnaire peut être utilisé comme lieu central pour le enregistrement , la gestion pile arrière entre autres, les comportements de navigation sont donc découplés du reste de la logique métier et ne sont pas répartis sur les implémentations de différents écrans.

Imaginons une situation dans laquelle nous voulons démarrer un écran, où l'utilisateur peut sélectionner certains éléments dans une liste de personnes. Vous souhaitez également transmettre certains arguments de filtrage, tels que l'âge, la profession et le sexe.

Dans le cas des activités, vous écririez:

Intent intent = new Intent(); intent.putExtra('age', 40); intent.putExtra('occupation', 'developer'); intent.putExtra('gender', 'female'); startActivityForResult(intent, 100);

Ensuite, vous devez définir onActivityResult quelque part vers le bas et gérer le résultat.

@Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); }

Mon problème personnel avec cette approche est que ces arguments sont des 'extras' et ne sont pas obligatoires, donc je dois m'assurer que l'activité de réception gère les différents cas, lorsqu'un extra est manquant. Ensuite, lorsqu'un refactoring est effectué et que le supplément, par exemple 'age' n'est plus nécessaire, alors je dois parcourir tout le code où cette activité a commencé et m'assurer que tous les extras sont corrects.

En outre, ne serait-il pas préférable que le résultat (liste des personnes) se présente sous la forme _List_ et non sous une forme série qui doit ensuite être désérialisée?

Dans le cas de la navigation basée sur des extraits de code, tout est plus simple. Tout ce que vous avez à faire est d'écrire une méthode dans le NavigationManager appelé startPersonSelectorFragment () avec les arguments nécessaires et avec une implémentation rappeler .

moyen le plus rapide d'apprendre le c++

mNavigationManager.startPersonSelectorFragment(40, 'developer', 'female', new PersonSelectorFragment.OnPersonSelectedListener() { @Override public boolean onPersonsSelected(List selection) { [do something] return false; } });

Ou avec RetroLambda

mNavigationManager.startPersonSelectorFragment(40, 'developer', 'female', selection -> [do something]);

3. De meilleurs moyens de communication entre les écrans

Entre les activités, nous ne pouvons partager qu'un package contenant des données primitives ou sérialisées. Maintenant, avec des fragments, nous pouvons implémenter un modèle rappeler où, par exemple, F1 peut écouter F2 passer des objets arbitraires. Veuillez consulter les exemples de mise en œuvre précédents de rappeler , qui renvoie une _List_.

4. Créer des fragments coûte moins cher que créer des activités

Cela devient évident lorsque vous utilisez un tiroir qui a par exemple 5 éléments de menu et sur chaque page, le tiroir doit être affiché à nouveau.

En cas de navigation pure activité, chaque page doit gonfler et démarrer le tiroir, mais bien sûr cela coûte cher.

Dans le diagramme présenté, vous pouvez voir plusieurs fragments de racine ou fragments de racine (FR *) qui sont les fragments d'écran accessibles directement depuis le tiroir, et le tiroir n'est également accessible que lorsque ces fragments sont affichés. Tout ce qui se trouve à droite de la ligne marquée dans le diagramme est là comme exemple de schéma de navigation arbitraire.

Comme l'activité contenant contient le tiroir, nous n'avons qu'une seule instance du tiroir, donc chaque étape de navigation où le tiroir doit être visible tu n'as pas à recommencer . Vous n'êtes toujours pas convaincu du fonctionnement de tout? Jetez un œil à mon exemple d'application où l'utilisation des tiroirs est démontrée.

Les inconvénients

Ma grande peur a toujours été que si j'utilise le modèle de navigation des fragments dans un projet, je rencontre à un moment donné un problème inconnu qui sera difficile à résoudre autour de la complexité des fragments, des bibliothèques tierces et des différentes versions de System Opérationnel. Et si je devais réfracter tout ce que j'ai fait jusqu'à présent?

En fait, vous auriez à résoudre les problèmes avec fragments imbriqués , des bibliothèques tierces qui utilisent des extraits comme Contrôles Shinobi , ViewPagers Oui FragmentStatePagerAdapters .

J'admets qu'acquérir suffisamment d'expérience avec les extraits de code pour résoudre ces problèmes a été un long processus. Mais dans chaque cas, le problème n'était pas que la philosophie soit mauvaise, mais qu'il ne comprenait pas assez les fragments. Mais si vous comprenez mieux les fragments que moi à l'époque, vous n'aurez aucun problème.

Le seul inconvénient que je peux mentionner maintenant est que nous pouvons trouver des problèmes qui ne sont pas triviaux à résoudre, car il n'y a pas de bibliothèque mature qui montre tous les scénarios complexes d'une application complexe avec une navigation basée sur des fragments.

conclusion

Dans cet article, nous avons vu une alternative pour implémenter la navigation dans une application Android . Le modèle a été comparé à la philosophie de navigation traditionnelle qui utilise des activités et nous avons vu de très bonnes raisons pour lesquelles il est avantageux d'utiliser des fragments au lieu de l'approche traditionnelle.

Au cas où vous ne l'avez pas encore vérifié, consultez l'application de démonstration dans le déploiement GitHub . N'ayez pas peur de fournir de bons exemples qui pourraient mieux démontrer son utilisation.

En relation: Top 10 des erreurs les plus courantes commises par les développeurs Android