Question Dilemme: quand utiliser Fragments vs Activités:


je le sais Activities sont conçus pour représenter un seul écran de mon application, tandis que Fragments sont conçus pour être des mises en page UI réutilisables avec une logique intégrée à l'intérieur d'eux.

Il n'y a pas si longtemps, j'ai développé une application qui disait qu'ils devaient être développés. J'ai créé un Activity pour représenter un écran de ma demande et utilisé Fragments pour ViewPager ou Google Maps. J'ai rarement créé un ListFragment ou une autre interface utilisateur qui peut être réutilisée plusieurs fois.

Récemment je suis tombé sur un projet qui ne contient que 2 Activities on est un SettingsActivity et l'autre est le MainActivity. La disposition de la MainActivity est rempli de nombreux fragments d'interface utilisateur cachés en plein écran et un seul est affiché. dans le Acitivty la logique, il y a beaucoup FragmentTransitions entre les différents écrans de l'application.

Ce que j'ai aimé de cette approche, c'est parce que l'application utilise un ActionBar, il reste intact et ne bouge pas avec l'animation de commutation d'écran, ce qui arrive avec Activity commutation. Cela donne une sensation plus fluide à ces transitions d'écran.

Donc je suppose que ce que je demande est de partager votre mode de développement actuel sur ce sujet, je sais que ça pourrait ressembler à une question basée sur l'opinion au premier abord mais je la considère comme une question de design et d'architecture Android ... basé sur l'opinion.

MISE À JOUR (01.05.2014): Suite à cette présentation de Eric Burke de Carré, (que je dois dire est une excellente présentation avec beaucoup d'outils utiles pour les développeurs Android. Et je ne suis pas du tout lié à Square)

http://www.infoq.com/presentations/Android-Design/

De mon expérience personnelle au cours des derniers mois, j'ai trouvé que la meilleure façon de construire mes applications est de créer des groupes de fragments qui représentent un couler dans l'application et présenter tous ces fragments dans un Activity. Donc, fondamentalement, vous aurez le même nombre de Activities dans votre application comme le nombre de flux. De cette façon, la barre d'action reste intacte sur tous les écrans du flux, mais elle est recréée en changeant un flux qui a beaucoup de sens. Comme l'affirme Eric Burke et comme je l'ai compris, la philosophie de l'utilisation de Activities comme possible n'est pas applicable à toutes les situations, car il crée un gâchis dans ce qu'il appelle l'activité "Dieu".


650
2017-11-30 21:53


origine


Réponses:


Les experts vous diront: "Quand je verrai l'interface utilisateur, je saurai si Activity ou un Fragment"Au début, cela n'aura aucun sens, mais avec le temps, vous serez en mesure de dire si vous avez besoin Fragment ou pas.

Il y a une bonne pratique que j'ai trouvée très utile pour moi. Cela m'est venu à l'esprit alors que j'essayais d'expliquer quelque chose à ma fille.

À savoir, imaginez une boîte qui représente un écran. Pouvez-vous charger un autre écran dans cette case? Si vous utilisez une nouvelle boîte, devrez-vous copier plusieurs éléments de la première case? Si la réponse est Oui, alors vous devriez utiliser Fragments, parce que la racine Activity peut contenir tous les éléments dupliqués pour vous faire gagner du temps en les créant, et vous pouvez simplement remplacer des parties de la boîte.

Mais n'oublie pas que vous avez toujours besoin d'un conteneur (Activity) ou vos parties seront dispersées. Donc une boîte avec des pièces à l'intérieur.

Veillez à ne pas abuser de la boîte. Les experts Android UX conseillent (vous pouvez les trouver sur YouTube) quand nous devrions charger explicitement un autre Activity, au lieu d'utiliser un Fragment (comme quand nous traitons avec le tiroir de navigation qui a des catégories). Une fois que vous vous sentez confortable avec Fragments, vous pouvez regarder toutes leurs vidéos. Encore plus, ils sont obligatoires.

Pouvez-vous maintenant regarder votre interface utilisateur et comprendre si vous avez besoin d'un Activity ou un Fragment? Avez-vous eu une nouvelle perspective? Je pense que tu l'as fait.


216
2017-09-23 10:42



Ma philosophie est la suivante:

Créez une activité seulement si c'est absolument nécessaire. Avec le backstack disponible pour commettre des transactions fragmentées, j'essaye de créer le minimum d'activités dans mon application comme possible. En outre, la communication entre divers fragments est beaucoup plus facile plutôt que d'envoyer des données entre les activités.

Les transitions d'activité sont chères, non? Au moins, je le crois - puisque l'ancienne activité doit être détruite / mise en pause / arrêtée, poussée sur la pile et ensuite la nouvelle activité doit être créée / démarrée / reprise.

C'est juste ma philosophie puisque des fragments ont été introduits.


100
2017-11-30 23:02



Eh bien, selon les conférences de Google (peut-être ici, Je ne me souviens pas), vous devriez envisager d'utiliser Fragments chaque fois que c'est possible, car cela rend votre code plus facile à maintenir et à contrôler.

Cependant, je pense que dans certains cas cela peut devenir trop complexe, car l'activité qui héberge les fragments doit naviguer / communiquer entre eux.

Je pense que vous devriez décider par vous-même ce qui est le mieux pour vous. Il n'est généralement pas difficile de convertir une activité en fragment et vice versa.

J'ai créé un post à propos de ce dillema ici, si vous souhaitez en lire plus.


45
2017-11-30 22:16



Pourquoi je préfère Fragment plutôt que Activité dans TOUS LES CAS.

  • L'activité est chère. Dans Fragment, les vues et les états de propriété sont séparés: chaque fois qu'un fragment est en backstack, ses vues seront détruites. Vous pouvez donc empiler plus de Fragments que d'Activité.

  • Backstack manipulation. Avec FragmentManager, il est facile d'effacer tous les Fragments, d'en insérer plus que sur les Fragments et etc. Mais pour Activity, ce sera un cauchemar de manipuler ces choses.

  • Un beaucoup prévisible cycle de la vie. Tant que l'activité de l'hôte n'est pas recyclée. les fragments dans le backstack ne seront pas recyclés. Donc, il est possible d'utiliser FragmentManager::getFragments() trouver un fragment spécifique (non encouragé).


19
2017-12-03 12:47



À mon avis, ce n'est pas vraiment pertinent. Le facteur clé à considérer est

  1. à quelle fréquence allez-vous réutiliser des parties de l'interface utilisateur (menus par exemple),
  2. est l'application aussi pour les tablettes?

L'utilisation principale de fragments est de construire des activités multipaires, ce qui le rend parfait pour les applications sensibles aux tablettes / téléphones.


9
2018-03-12 22:41



Il y a plus à cela que vous ne le pensez, vous devez vous rappeler qu'une activité qui est lancée ne détruit pas implicitement l'activité d'appel. Bien sûr, vous pouvez le configurer de sorte que votre utilisateur clique sur un bouton pour aller à une page, vous démarrez l'activité de cette page et détruisez l'actuelle. Cela provoque beaucoup de frais généraux. Le meilleur guide que je peux vous donner est:

** Commencer une nouvelle activité seulement s'il est logique d'avoir l'activité principale et celle-ci ouverte en même temps (pensez à plusieurs fenêtres).

Google Drive est un bon exemple de cas où il est judicieux d'avoir plusieurs activités. L'activité principale fournit un explorateur de fichiers. Lorsqu'un fichier est ouvert, une nouvelle activité est lancée pour afficher ce fichier. Vous pouvez appuyer sur le bouton des applications récentes qui vous permettra de revenir au navigateur sans fermer le document ouvert, puis peut-être même ouvrir un autre document en parallèle au premier.


7
2017-08-05 14:27



N'oubliez pas qu'une activité est le bloc / composant de l'application qui peut être partagé et démarré par Intent! Ainsi, chaque activité de votre application ne devrait résoudre qu'un seul type de tâche. Si vous n'avez qu'une seule tâche dans votre application, je pense que vous n'avez besoin que d'une activité et de plusieurs fragments si nécessaire. Bien sûr, vous pouvez réutiliser des fragments dans des activités futures qui résolvent d'autres tâches. Cette approche sera une séparation claire et logique des tâches. Et vous n'avez pas besoin de maintenir une activité avec des paramètres de filtre d'intention différents pour différents ensembles de fragments. Vous définissez les tâches à l'étape de conception du processus de développement en fonction des besoins.


6
2018-02-02 16:15



Ce que j'ai fait: Utiliser moins de fragments quand c'est possible. Malheureusement, c'est possible dans presque tous les cas. Donc, je me retrouve avec beaucoup de fragments et un peu d'activités. Quelques inconvénients que j'ai réalisés:

  • ActionBar & Menu: Quand 2 fragment a un titre différent, un menu,
       sera difficile à gérer. Ex: lors de l'ajout d'un nouveau fragment, vous pouvez changer le titre de la barre d'action backstack il n'y a aucun moyen de restaurer l'ancien titre. Vous pouvez avoir besoin d'une barre d'outils dans chaque fragment pour ce cas, mais laissez-moi croire, cela vous prendra plus de temps.
  • Quand nous avons besoin startForResult, l'activité a mais le fragment n'a pas.
  • Ne pas avoir d'animation de transition par défaut

Ma solution pour cela est d'utiliser une activité pour emballage un fragment à l'intérieur. Nous avons donc une barre d'action séparée, menu, startActivityForResult, animation, ...


5
2017-11-18 03:01



Le grand avantage d'un fragment sur l'activité est que, le code qui est utilisé pour fragment peut être utilisé pour différentes activités.so, il fournit réutilisabilité de code dans le développement d'applications.


2
2018-06-09 19:38



J'utilise Fragments pour une meilleure expérience utilisateur. Par exemple, si vous avez un bouton et que vous voulez exécuter disons un service Web lorsque vous cliquez dessus, j'attache un fragment à l'activité parente.

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

De cette façon, l'utilisateur n'aura pas à se déplacer dans une autre activité.

Et d'autre part, je préfère les Fragments parce que vous pouvez les manipuler facilement pendant la rotation.


0
2018-05-29 08:37