Pourquoi utiliser Android Fragments?

Question

J'ai lu la documentation et autres fils de discussion sur ce sujet et je ne me sens pas vraiment convaincu; Je ne vois pas clairement les limites d'utilisation de cette technique.

Les fragments sont désormais considérés comme une meilleure pratique; chaque activité doit être essentiellement un support pour un ou plusieurs fragments et ne pas appeler une mise en page directement.

Des fragments sont créés afin de:

permettre au Activity d'utiliser de nombreux fragments, de basculer entre eux, de réutiliser ces unités ... ==> le Fragment est totalement dépendant du Context d'une activité, donc si j'ai besoin de quelque chose de générique que je peux réutiliser et gérer dans de nombreuses activités, je peux créer mes propres dispositions ou vues personnalisées ... Je ne me soucierai pas de cette couche de développement de complexité supplémentaire que les fragments ajouteraient.
une meilleure prise en charge à une résolution différente ==> OK pour les tablettes/téléphones en cas de long processus que nous pouvons afficher deux (ou plus) fragments dans la même activité dans les tablettes, et un par un dans les téléphones. Mais pourquoi utiliserais-je toujours des fragments ?
gérer les rappels pour naviguer entre les fragments (par exemple: si l'utilisateur est connecté, je montre un fragment, sinon j'en montre un autre). ===> Essayez juste de voir combien de bogues Facebook SDK Log-in ont à cause de cela, pour comprendre que c'est vraiment (?) ...
considérant qu'une application Android est basée sur les activités ... L'ajout d'un autre cycle de vie dans l'activité serait préférable pour concevoir une application ... Je veux dire les modules, les scénarios, la gestion des données et la connectivité serait mieux conçue de cette façon. ===> Ceci est une réponse de quelqu'un qui a l'habitude de voir le Android SDK et Android Framework avec une vision Fragments. Je ne pense pas que ce soit faux, mais je ne suis pas sûr que cela donnera de bons résultats ... Et c'est vraiment abstrait ...

====> Pourquoi devrais-je compliquer ma vie, en codant davantage, en les utilisant toujours? sinon, pourquoi est-ce une meilleure pratique si ce n'est qu'un outil pour certains cas? quels sont ces cas?

Zeus · Accepted Answer

Fragment est une section modulaire d'une activité qui a son propre cycle de vie, reçoit ses propres événements d'entrée, que vous pouvez ajouter ou supprimer pendant que l'activité est en cours d'exécution (un peu comme une "sous-activité" que vous pouvez réutilisation dans différentes activités)

Outre l'avantage évident d'utiliser des fragments, l'optimisation de l'interface utilisateur sur différents écrans, il vous permet de gérer le traitement en arrière-plan de l'activité sans composant d'interface utilisateur visible.

Maintenant...

====> Pourquoi devrais-je compliquer ma vie, en codant plus ... ??

Bien que recommandé, vous n'avez pas besoin de le faire sauf si vous prévoyez de contrôler le cycle de vie des éléments individuels et/ou de réutiliser l'état de la pile ou l'historique des vues précédentes.

Kevin Krumwiede · Answer

S'il existe un cas d'utilisation de "passerelle" pour les sceptiques des fragments, ce sont probablement les dialogues. Les méthodes obsolètes depuis longtemps showDialog(...), onCreateDialog(...), etc., étaient agréables dans la mesure où le cadre les appelait pour détruire et recréer automatiquement vos boîtes de dialogue lorsque l'activité d'hébergement était détruite et recréée. Si vous créez directement vos propres boîtes de dialogue, vous devez gérer tout cela vous-même. Mais si vous utilisez un DialogFragment, vous pouvez à nouveau laisser le framework les gérer pour vous. Dans ce cas, les fragments peuvent grandement simplifier votre codage.

ahmed_khan_89 · Answer

J'ai posé cette question il y a plus d'un an.

J'utilise des fragments tous les jours et je le recommanderais.

Tout d'abord, je veux dire que l'utilisation de fragments n'est qu'une option et sera un réflexe à considérer une fois que vous commencerez à les utiliser.

Avantages:

1/il permet de modulariser le code où vous pouvez avoir un flux complet en une seule Activité, en fragments séparés. Exemple: + liste/grille et détails, + connexion et inscription et oublier le mot de passe, + etc. C'est génial pour obtenir un code réutilisable, que vous pouvez toujours copier et coller dans différents projets.

2/vous avez un nouveau cycle de vie, plein de tracas c'est vrai, mais avec des avantages aussi. Exemple: le fragment d'instance conservé est génial car il résout le problème de l'orientation.

3/vous pouvez gérer le flux de vos fragments par les événements et les auditeurs de l'Activité.

4/une pile de vos fragments dans votre Activité.

5/utilisez la même barre d'action dans de nombreux écrans.

Et plein d'autres...

J'utilise toujours l'activité comme seul conteneur parfois, en particulier pour le boîtier de l'appareil photo. Certaines API Android Android et certaines bibliothèques tierces ne sont pas faciles à implémenter en fragments.

Eh bien, c'est comme n'importe quel outil, vous devez le considérer et juger par vous-même s'il vaut mieux l'utiliser dans un cas ou un autre.

J'espère que cela peut aider !!!