Fragmenter ou ne pas fragmenter - Fragments imbriqués contre des activités. Pourquoi devrais-je utiliser plus d'une activité?

Question

Il y a beaucoup de discussions pour savoir si vous devriez utiliser Activities ou Fragments. Par exemple:

La plupart des discussions que j'ai trouvées ont été publiées avant Android 4.2.
Avec Android 4.2, Google inventa Fragments imbriqués .

Par conséquent, je ne vois plus aucune raison d'utiliser plus d'une Activity.

Au début de Fragments, ils étaient censés être utilisés dans Apps pour prendre en charge Tablets et Smartphones de manière confortable en même temps.

Ainsi, par exemple, vous avez une ListView qui peut ouvrir un détail View en cliquant sur un élément. Sur un smartphone, nous remplacerions la ListView et montrerions la View détaillée à la place. Alors que Tablet au lieu de remplacer la liste par la vue détaillée peut afficher les deux Views en même temps.

Maintenant, avec Fragments imbriqué, il y a beaucoup d'autres possibilités. Si vous voulez utiliser une seule Activity, vous pouvez stocker des informations générales dans la Activity et chaque Fragment y aurait accès.

De plus, Fragments qui ont imbriqué Fragments, peuvent également stocker des informations sur leurs enfants Fragments.

Avec Fragments je peux facilement réutiliser la Views, je peux afficher plusieurs Fragment à la fois et je peux facilement former un dialogue à partir de Fragment. Tout cela ne me prendrait probablement pas plus que quelques actions copier-coller.

Si j'utilise plutôt Activities, je dois sérieusement changer beaucoup pour que cela soit fait.

J'ai récemment implémenté une Application où je pouvais facilement utiliser deux Fragment-ViewPager pour obtenir des choses vraiment belles et dynamiques (Une sorte de: Informations du jour - Informations du jour). À mon avis, Fragments rendre notre vie plus facile :)

Des questions:

Pourquoi devrais-je utiliser plus d'une Activity?

Pourriez-vous donner un bon exemple dans lequel l'utilisation de plusieurs Activities a plus de sens au lieu d'utiliser Fragments?

Existe-t-il de bons exemples où vous n'avez d'autre choix que d'utiliser Activities?

Je pense que la plupart des cadres plus importants tels que Maps, YouTube et co prennent déjà en charge Fragments. Nous n’avons donc pas à compter sur Activities. Est-il également assez facile de traiter NavigationBar, TabHosts, ViewPager, ActionBar au cas où vous utiliseriez Fragments.

De Udacity:

Pourquoi ne pas toujours créer une activité avec beaucoup de fragments?

Complexité accrue
Manipulation d'intention plus difficile
Difficile à lire, maintenir et tester
Risque de couplage serré
Préoccupations de sécurité

Steven · Accepted Answer

Tout d'abord, je conviens avec vous qu'il est possible d'écrire une énorme application en utilisant une seule activité et des fragments imbriqués. C'est le plaisir des logiciels: vous pouvez obtenir la même fonctionnalité en utilisant diverses approches. Pour moi, le choix d'utiliser plusieurs activités dépend de mes préférences personnelles en matière d'encapsulation, de réutilisation et de testabilité.

Si j'ai un widget qui peut être réutilisé dans d'autres applications, j'en fais un fragment. Par exemple, mon application comporte un bouton "Synchroniser avec le serveur" et j'ai créé un fragment personnalisé qui utilise des barres de progression pour afficher visuellement le processus de synchronisation. Il est facile d'imaginer qu'une autre application puisse utiliser ce widget, c'est pourquoi je l'ai développé en tant que fragment.

Si je change de tâche dans mon application, de sorte que la nouvelle tâche est conceptuellement indépendante de la tâche précédente, j'utilise une nouvelle activité. Par exemple, la première page de mon application vous demande de sélectionner un utilisateur. Une fois que vous avez cliqué sur un utilisateur, je vous renvoie au menu principal de cet utilisateur. Ce menu principal pour l'utilisateur est affiché dans une nouvelle activité.

Imaginons maintenant une application volumineuse et complexe et une équipe de développeurs chargés de la développer. Si l'application peut être divisée en activités distinctes, il est très facile conceptuellement de diviser les tâches. Chaque activité étant son propre bac à sable, le développement en parallèle est simple et peut être testé en unité. S'il existe des besoins communs, l'équipe doit tout de même développer des fragments et les réutiliser, bien sûr. Je devrais ajouter que la réutilisation de code ne se produit pas assez souvent dans le développement logiciel, mais si elle est bien faite, il devrait y avoir beaucoup de fragments réutilisables.

Supposons maintenant qu'il est temps de tester l'application. Votre équipe de test peut traiter chaque activité comme sa propre boîte noire. C’est plus facile à tester qu’une simple application géante reposant sur une seule activité et des tonnes de fragments imbriqués. Ceci est particulièrement important si un bogue existe. S'il existe un bogue qui ne soit pas évident, je sais au moins que sa portée est limitée à une seule activité.

En résumé, je suppose que vous développez votre application en tant qu'individu et que vos décisions en matière de développement ne concernent donc personne. Vos perspectives changeraient probablement si vous développiez une application avec une équipe plus grande, et j'espère que ma réponse aura beaucoup de sens à cet égard.

Sherif elKhatib · Answer

Tu as raison. On pourrait faire beaucoup avec des fragments seuls. Cependant, selon la classe d'activité , une activité est une tâche unique et ciblée que l'utilisateur peut effectuer. J'ai toujours tendance à compartimenter mon application en activités de haut niveau et en fragments.

Par exemple, il existe une situation où plusieurs activités ont un sens. Nos applications disposent d'une certaine fonctionnalité qui peut être étendue si l'utilisateur se connecte. Cependant, l'utilisateur peut toujours utiliser cette fonctionnalité limitée avant de se connecter. Par exemple, vous ne pouvez pas commenter d'éléments, sauf si vous êtes connecté. Dans ce cas, notre MainActivity peut afficher l’ensemble des fonctionnalités. Si l'utilisateur souhaite commenter, nous lui demandons de se connecter en enregistrant sa demande et en démarrant une activité LoginActivity qui gère la connexion/l'enregistrement et définit le bon résultat à la fin. Dans notre fragment ou activité appelant, nous vérifions si le résultat est LOGIN_SUCCESS ou si l'utilisateur est actuellement connecté et répondons à la demande en attente. Ce que j'essaie de dire, c'est que le flux d'actions de Login doit être une activité distincte. Sinon, la manipulation serait probablement gâchée. De cette manière, toute action nécessitant une connexion peut appeler startActivityForResult (LOGIN) et s’enregistrer elle-même en tant qu’attente. Ensuite, après avoir défini le résultat, nous pourrions implémenter le traitement dans super.onActivityResult. Tout cela est bien sûr théorique, on pourrait implémenter Login dans un fragment sans problème. Cependant, le code se révélera définitivement être FUed.

Une autre situation où vous avez besoin d'une activité est lorsque votre activité fournit un service exporté. Par exemple, supposons que vous développiez un "File Uploader" et que vous receviez l'intention de télécharger des fichiers. Dans ce cas, il est très pratique de créer une activité pouvant consommer des requêtes de téléchargement de fichier.

Pourtant, avec les mises à jour actuelles, les fonctionnalités de Fragments couvrent la plupart des fonctionnalités des applications Android et peuvent donc être utilisées seules avec une seule activité hôte pour répondre aux exigences d'une application.

Cependant, toute votre "activité hôte" avec des données est plutôt faible. Activités et étroitement Fragments a tout le cycle de vie qui inclut l'instance de sauvegarde/restauration via des bundles. Une activité hôte unique peut durer longtemps et héberger plusieurs fragments pouvant être recyclés plusieurs fois au cours d'une même vie d'activité. Il est donc hautement probable qu'une activité contenant toutes ces instances au fil du temps dépasse son budget de ressources. Il incombe au développeur de conserver les données dans un contexte partagé lorsqu'elles sont réellement partagées entre plusieurs objets. C'est un inconvénient de cette approche. Dans notre exemple, il n’a pas de sens que MainActivity consomme un octet supplémentaire de données car elle a hébergé les fragments de login alors qu’elle aurait pu dormir et libéré sa mémoire si nécessaire.

En fin de compte, un bon programmeur peut faire la même chose de la même manière.

Huy Tower · Answer

Tu as complètement raison!

Pourquoi devrais-je utiliser plus d'une activité?

Pourriez-vous donner un bon exemple dans lequel l'utilisation de plusieurs activités est plus logique que l'utilisation de fragments?

Existe-t-il de bons exemples où vous n'avez d'autre choix que d'utiliser Activités?

Je pense que la plupart des cadres plus importants tels que Google Maps, YouTube et ses partenaires prennent déjà en charge Fragments. Nous n’avons donc pas besoin d’Activités. De plus, il est assez facile de traiter avec NavigationBar, TabHosts, ViewPager, ActionBar au cas où vous utiliseriez des fragments.

Toujours utiliser Fragments n’est pas bon pour gonfler les données dans l’UI, surtout dans le cas où

ConnectionTimeOut (ou Internet bas) car il a fallu beaucoup de temps pour initialiser les données . Donc, parfois, utiliser chaque activité pour gonfler quelques données est meilleur que chaque fragment.
Ou pour utiliser la méthode onActivityResult pour plus de souplesse, utiliser l'activité est également meilleur que. Ex. Vous pouvez appeler FileDialogChooser dans votre application. _

C'est quelques cas,

Merci,

phemt.latd · Answer

Pour vos questions, je peux seulement dire que parfois, avec une expérience utilisateur complexe ou une application complexe qui doit utiliser un composant matériel différent, vous devez utiliser une activité au lieu de fragmenter.

Par exemple, si vous devez créer une application avec un formulaire comportant une étape qui prend une photo, puis utilisez cette photo pour une tâche de mémoire dure (détection de visage par exemple) qui utilise la mémoire, vous devez séparer cette tâche de la tâche principale. tâche et personnalisez l’autorisation sur le manifeste pour utiliser plus de mémoire uniquement pour cette activité.

Un autre exemple est si vous souhaitez utiliser une activité de mémoire faible (dans manifest, vous pouvez définir des propriétés telles que vider la pile d'activités et forcer le collecteur de déchets à nettoyer la mémoire à la fin de l'activité).

L'expérience utilisateur de l'application est probablement la situation qui nécessite le plus d'activité et de fragmentation. Si vous avez besoin d'une personnalisation de tiroir droite contenant un menu et que chaque fragment du menu contient un listView et que chaque vue de liste doit aller dans un détail. Vous pouvez faire beaucoup d’astuces pour masquer le bon tiroir et créer une animation permettant de glisser d’un fragment au détail, mais la meilleure et la plus simple consiste à créer une nouvelle activité pour le détail et à la gérer avec une logique/cycle de vie séparé du cycle principal. activité avec le tiroir. Je l'ai fait dans deux de mes applications:

iMeal - https://play.google.com/store/apps/details?id=it.fullsix.chiccopappe

GGRugby - https://play.google.com/store/apps/details?id=it.f6.template

Dans cette application, le tiroir se trouve dans l'activité du fragment principal, chaque menu modifie le fragment de contenu . La vue liste dans le fragment de contenu modifie le contexte de l'activité avec intention et passe à une autre activité.

Enfin, il existe certaines situations dans lesquelles vous devriez travailler avec plus d’un fragmentActivity ... mais c’est un modèle de travail, vous pouvez probablement trouver une astuce ou un moyen de faire quelque chose avec seulement une activité et un fragment.

Penguin Blues · Answer

Je sais que je suis trop tard pour ça, mais Square a son opinion sur les fragments. Voici le résumé de l'article:

Fragments: leçons apprises

Malgré leurs inconvénients, des fragments nous ont appris des leçons précieuses que nous pouvons maintenant appliquer à nouveau lors de la création d'applications:

Interface d'activité unique: il n'est pas nécessaire d'utiliser une activité pour chaque écran. Nous pouvons diviser notre application en widgets découplés et les assembler à notre guise. Cela facilite l'animation et le cycle de vie. Nous pouvons diviser nos widgets en code d'affichage et en code de contrôleur.

Le backstack n’est pas une notion spécifique à une activité; vous pouvez implémenter un backstack dans une activité.

De nouvelles API ne sont pas nécessaires. Tout ce dont nous avions besoin était là depuis le début: activités, vues et mise en page.

Vous n'êtes pas obligé d'utiliser plus d'une activité et vous n'avez pas besoin d'utiliser des fragments. Vous pouvez simplement utiliser des vues personnalisées avec leurs présentateurs.

Vous pouvez le lire ici: https://corner.squareup.com/2014/10/advocating-against-Android-fragments.html .

Vous pouvez également trouver la bibliothèque de mortier de Square ici: https://github.com/square/mortar