Fragmenter ou ne pas fragmenter – Fragments nesteds contre les activités. Pourquoi devrais-je utiliser plus d’une activité?

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

  • Fragmenter ou ne pas fragmenter
  • Une activité et tous les autres fragments
  • Combien d’activités contre des fragments
  • Utiliser l’activité ou le fragment dans une application Android

La plupart des discussions que j’ai trouvées ont été publiées avant Android 4.2.
Avec Android 4.2, Google a inventé des fragments nesteds .

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 simultanément avec les tablettes et les smartphones .

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


Maintenant, avec les Fragments nesteds, il y a beaucoup d’autres possibilités. Si vous souhaitez utiliser une seule Activity , vous pouvez stocker des informations générales dans l’ Activity et chaque Fragment y aura access.

En outre, les Fragments qui ont nested Fragments , peuvent également stocker des informations pour leurs enfants Fragments .

Avec Fragments je peux facilement réutiliser les Views , je peux afficher plusieurs Fragment en même temps et créer facilement un dialog à partir d’un Fragment . Cela ne me prendrait probablement pas plus que quelques actions de copier / coller.

Si j’utilise les 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 dynamics (une sorte de: Informations du jour – Informations d’hier). A mon avis, les Fragments rendent notre vie plus facile 🙂


Des questions:

  • Pourquoi devrais-je utiliser plus d’une Activity ?

Pourriez-vous donner un bon exemple d’utilisation de plusieurs Activities au lieu d’utiliser des Fragments ?

  • Y a-t-il de bons exemples où vous n’avez pas d’autre choix que d’utiliser les Activities ?

Je pense que la plupart des frameworks plus grands comme Maps , YouTube et co supportent déjà Fragments . Donc, nous ne devons pas compter sur les Activities . Il est également très facile de gérer NavigationBar , TabHosts , ViewPager , ActionBar au cas où vous utiliseriez Fragments .


De Udacity:

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

  1. Complexité accrue
  2. Harder Intent manipulation
  3. Difficile à lire, à entretenir et à tester
  4. Risque de couplage serré
  5. Problèmes de sécurité

Tout d’abord, je suis d’accord avec vous pour dire qu’il est possible d’écrire une énorme application en utilisant une seule activité et des fragments nesteds. C’est l’amusement du logiciel – vous pouvez obtenir les mêmes fonctionnalités en utilisant diverses approches. Pour moi, le choix d’utiliser plusieurs activités se résume à 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 dispose d’un bouton “Synchroniser avec le serveur” et j’ai créé un fragment personnalisé qui utilise les 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 soit 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 envoie au menu principal de cet utilisateur. Ce menu principal pour l’utilisateur est affiché dans une nouvelle activité.

Imaginons maintenant une grande application complexe et une équipe de développeurs chargée de développer cette application. Si l’application peut être divisée en activités distinctes, il est très facile, sur le plan conceptuel, de répartir les tâches. Chaque activité étant son propre bac à sable, le développement parallèle est simple et testable par unité. S’il y a des besoins communs, l’équipe doit toujours développer des fragments et les réutiliser, bien sûr. Je dois append que la réutilisation du code ne se produit pas assez souvent dans le développement de logiciels, mais si cela est fait correctement, il devrait y avoir beaucoup de fragments réutilisables.

Maintenant, supposons qu’il soit temps de tester l’application. Votre équipe de test peut traiter chaque activité comme sa propre boîte noire. Cela est plus facile à tester qu’une application unique qui repose sur une seule activité et des tonnes de fragments nesteds. Ceci est particulièrement important si un bug existe. S’il existe un bogue qui n’est pas évident, au moins je sais que la scope du bogue est limitée à une seule activité parmi tant d’autres.

En résumé, je suppose que vous développez votre application en tant qu’individu et que, par conséquent, vos décisions de développement n’affectent personne d’autre. Vos points de vue changeraient probablement si vous développiez une application avec une équipe plus importante, et j’espère que ma réponse aura beaucoup de sens à cet égard.

Tu as raison. On pourrait faire beaucoup avec des fragments seuls. Cependant, selon la classe d’activité , une activité est une activité 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, voici une situation où plusieurs activités ont du sens. Nos applications ont certaines fonctionnalités qui peuvent être étendues si l’utilisateur se connecte. Cependant, l’utilisateur peut toujours utiliser cette fonctionnalité limitée avant de se connecter. Dites, vous ne pouvez pas commenter les articles sauf lorsque vous êtes connecté. Dans ce cas, notre MainActivity peut afficher toutes les fonctionnalités. Si l’utilisateur veut faire un commentaire, nous lui demandons de se connecter en sauvegardant sa demande et en démarrant une activité LoginActivity qui gère la connexion / l’enregistrement et définit le bon résultat une fois terminé. Dans notre appel Fragment ou Activity, nous vérifions si le résultat est LOGIN_SUCCESS ou si l’utilisateur est actuellement connecté et sert la demande en attente. Ce que j’essaie de dire, c’est que le stream d’action de Login devrait être une activité distincte. Sinon, la manipulation serait probablement foirée. De cette manière, toute action nécessitant une connexion peut appeler startActivityForResult (LOGIN) et s’enregistre en tant qu’Action en attente. Ensuite, après avoir défini le résultat, nous pourrions implémenter la gestion dans le super.onActivityResult. C’est tout à fait théorique bien sûr, on pourrait implémenter Login dans un fragment sans problème. Cependant, le code sera définitivement utilisé.

Une autre situation dans laquelle vous avez besoin d’une activité est lorsque votre activité fournit un service exporté. Par exemple, disons que vous êtes un développeur d’un “File Uploader” et que vous recevez des tentatives pour télécharger des fichiers. Dans ce cas, il est très pratique de créer une activité pouvant consumr des demandes de téléchargement de fichier.

Cependant, 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, l’ensemble de votre “hôte d’activité unique” avec des données est plutôt une défense faible. Activités et étroitement Fragments a le cycle de vie complet qui inclut l’instance de sauvegarde / restauration via des ensembles. Une activité hôte unique peut durer longtemps et héberger plusieurs fragments pouvant être recyclés plusieurs fois au cours d’une seule vie de leur activité. Il est donc hautement probable qu’une activité détenant tous ces cas au fil du temps dépasse son budget de ressources. Le développeur a la responsabilité de conserver les données dans un contexte partagé lorsqu’elles sont réellement partagées entre plusieurs objects. Ceci est un inconvénient de cette approche. Dans notre exemple, il n’est pas logique que MainActivity consum un octet de données supplémentaire car il hébergeait les fragments de connexion lorsqu’il aurait pu dormir et libérait sa mémoire si nécessaire.

Au bout du compte, un bon programmeur peut également faire la même chose.

Tu as complètement raison!

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

Pourriez-vous donner un bon exemple d’utilisation de plusieurs activités au lieu d’utiliser des fragments?

Y a-t-il de bons exemples où vous n’avez pas d’autre choix que d’utiliser les activités?

Je pense que la plupart des frameworks plus grands comme Maps, YouTube et co supportent déjà Fragments. Donc, nous ne devons pas compter sur les activités. Il est également très facile de gérer NavigationBar, TabHosts, ViewPager, ActionBar au cas où vous utiliseriez Fragments.

Toujours utiliser Fragments n’est pas bon pour gonfler les données sur l’interface utilisateur, 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 peu de données est préférable à chaque fragment.

  • Ou pour utiliser la méthode onActivityResult pour plus de souplesse, l’utilisation de l’activité est également meilleure que. Ex. Vous pouvez appeler FileDialogChooser dans votre application.

C’est des cas,

Merci,

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 l’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 utiliser cette photo pour certaines tâches de mémoire de travail (détection de visage par exemple) qui utilisent de la mémoire, vous devez séparer cette tâche de la principale. activité de tâche et personnaliser l’autorisation sur manifeste pour utiliser plus de mémoire uniquement sur cette activité.

Un autre exemple est si vous souhaitez utiliser une activité de mémoire faible (dans le manifeste, vous pouvez définir des propriétés qui effacent la stack d’activités et obligent le récupérateur de place à 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és et de fragments. Si vous avez besoin d’un tiroir de droite personnalisé qui contient un menu et chaque fragment du menu contient un listView et chaque vue de liste doit aller dans un détail. Vous pouvez faire beaucoup de truc pour masquer le bon tiroir et créer une animation qui va du fragment au détail, mais le moyen le plus simple et le plus simple est de créer une nouvelle activité pour le détail et de la gérer avec une logique / un cycle de vie distinct. activité avec le tiroir. J’ai fait cela 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 est dans l’activité de fragment principal, chaque menu modifie le fragment de contenu. La vue de liste dans le fragment de contenu modifie le contexte d’activité avec l’intention et entre dans une autre activité.

Enfin, il y a une situation dans laquelle je pense que vous devriez travailler avec plus d’un fragmentActivity … mais ceci est mon mode de travail, vous pouvez probablement trouver un truc / une manière ou une scope pour faire quelque chose avec une activité et un fragment.

Je sais que je suis trop tard pour ça, mais Square a une opinion sur les fragments. Voici l’essentiel de l’article:

Fragments: leçons apsockets

Malgré leurs inconvénients, les fragments nous ont appris des leçons inestimables que nous pouvons maintenant réappliquer lors de l’écriture 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 de vue et en code de contrôleur.
  • Le backstack n’est pas une notion d’activité spécifique; vous pouvez implémenter un backstack dans une activité.
  • Il n’y a pas besoin de nouvelles API; Tout ce dont nous avions besoin était là depuis le début: activités, vues et inflatateurs de mise en page.

Vous n’avez pas à utiliser plus d’une activité et vous n’avez pas à utiliser de 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