Dilemme: quand utiliser Fragments vs Activités:

Je sais qu'ils Activitiessont conçus pour représenter un seul écran de mon application, alors qu'ils Fragmentssont conçus pour être des mises en page d'interface utilisateur réutilisables avec une logique intégrée à l'intérieur.

Jusqu'à il n'y a pas longtemps, j'ai développé une application qui disait qu'il fallait les développer. J'ai créé un Activitypour représenter un écran de mon application et utilisé des fragments pour ViewPagerou Google Maps. J'ai rarement créé une ListFragmentou 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 l' Activitiesun est un SettingsActivityet l'autre est le MainActivity. La disposition du MainActivityest remplie de nombreux fragments d'interface utilisateur en plein écran cachés et un seul est affiché. Dans la Activitylogique il y en a beaucoup FragmentTransitionsentre les différents écrans de l'application.

Ce que j'ai aimé dans cette approche, c'est que parce que l'application utilise un ActionBar, elle reste intacte et ne bouge pas avec l'animation de changement d'écran, ce qui se produit avec le Activitychangement. Cela donne une sensation plus fluide à ces transitions d'écran.

Donc je suppose que ce que je demande, c'est de partager votre manière de développement actuelle sur ce sujet, je sais que cela pourrait ressembler à une question d'opinion à première vue, mais je la vois comme une question de conception et d'architecture Android ... Pas vraiment un basé sur une opinion.

MISE À JOUR (01.05.2014): Suite à cette présentation par Eric Burke de Square , (ce que je dois dire est une excellente présentation avec beaucoup d'outils utiles pour les développeurs Android. Et je n'ai aucun lien avec Square)

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

D'après 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 viennent représenter un flux dans l'application et présenter tous ces fragments en un Activity. Donc, fondamentalement, vous aurez le même nombre de Activitiesdans votre application que le nombre de flux. De cette façon, la barre d'action reste intacte sur tous les écrans du flux, mais est recréée en modifiant un flux, ce qui a beaucoup de sens. Comme le déclare Eric Burke et comme je l'ai compris, la philosophie d'utiliser le moins Activitiespossible n'est pas applicable à toutes les situations car elle crée un gâchis dans ce qu'il appelle l'activité «Dieu».

Les experts vous diront: "Quand je verrai l'interface utilisateur, je saurai s'il faut utiliser un Activityou un Fragment". Au début, cela n'aura aucun sens, mais avec le temps, vous pourrez réellement dire si vous en avez besoin Fragmentou non.

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 boîte? Si vous utilisez une nouvelle boîte, devrez-vous copier plusieurs éléments de la première boîte? Si la réponse est Oui, vous devez utiliser Fragments, car la racine Activitypeut contenir tous les éléments dupliqués pour vous faire gagner du temps dans leur création, et vous pouvez simplement remplacer des parties de la boîte.

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

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

Pouvez-vous dès maintenant regarder votre interface utilisateur et déterminer si vous avez besoin d'un Activityou d'un Fragment? Avez-vous eu une nouvelle perspective? Je pense que oui.

Ma philosophie est la suivante:

Créez une activité uniquement si elle est absolument indispensable. Avec la pile arrière rendue disponible pour valider un tas de transactions de fragments, j'essaie de créer le moins d'activités possible dans mon application. En outre, la communication entre divers fragments est beaucoup plus facile que l'envoi de données entre les activités.

Les transitions d'activité coûtent cher, non? Du moins, je le crois - puisque l'ancienne activité doit être détruite / suspendue / arrêtée, poussée sur la pile, puis la nouvelle activité doit être créée / démarrée / reprise.

C'est juste ma philosophie depuis l'introduction des fragments.

Eh bien, selon les conférences de Google (peut-être ici , je ne me souviens pas), vous devriez envisager d'utiliser des fragments chaque fois que cela 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 de ce qui vous convient le mieux. Il n'est généralement pas si difficile de convertir une activité en un fragment et vice versa.

J'ai créé un article sur ce dillema ici , si vous souhaitez en lire plus.

Pourquoi je préfère le fragment à l'activité dans TOUS LES CAS.

• L'activité coûte cher. Dans Fragment, les vues et les états de propriété sont séparés - chaque fois qu'un fragment se trouve backstack, ses vues sont détruites. Vous pouvez donc empiler beaucoup plus de fragments que d'activité.

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

• Un cycle de vie bien prévisible . Tant que l'activité hôte n'est pas recyclée. les fragments du sac à dos ne seront pas recyclés. Il est donc possible d'utiliser FragmentManager::getFragments()pour trouver un fragment spécifique (non recommandé).

Depuis Jetpack , l' application à activité unique est l'architecture préférée. Utile en particulier avec le composant Architecture de navigation .

la source

À 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. l'application est-elle également pour les tablettes?

L'utilisation principale des fragments est de créer des activités à volets multiples, ce qui le rend parfait pour les applications réactives pour tablette / téléphone.

N'oubliez pas qu'une activité est un bloc / composant d'application qui peut être partagé et démarré via 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 seule 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 une autre tâche. 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 au stade de la conception du processus de développement en fonction des besoins.

Il y a plus que vous ne le réalisez, vous devez vous rappeler qu'une activité qui est lancée ne détruit pas implicitement l'activité appelante. Bien sûr, vous pouvez le configurer de telle sorte que votre utilisateur clique sur un bouton pour accéder à une page, vous démarrez l'activité de cette page et détruisez celle en cours. Cela entraîne beaucoup de frais généraux. Le meilleur guide que je puisse vous donner est:

** Commencez une nouvelle activité uniquement 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 excellent exemple de cas où il est logique 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 d'ouvrir un autre document en parallèle au premier.

Chose que j'ai faite: Utiliser moins de fragments lorsque cela 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é:

• ActionBar& Menu: Lorsque 2 fragments ont un titre, un menu différent, cela
  sera difficile à gérer. Ex: lors de l'ajout d'un nouveau fragment, vous pouvez modifier le titre de la barre d'action, mais lorsque vous le faites apparaître, il backstackn'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 croyez-moi, cela vous passera plus de temps.
• Lorsque nous en avons besoin startForResult, l'activité n'a pas de fragment.
• Ne pas avoir d'animation de transition par défaut

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

Le gros avantage d'une fragmentsuractivité est que le code utilisé pour le fragment peut être utilisé pour différentes activités, donc il permet la réutilisation du code dans le développement d'applications.

utiliser une activité par application pour fournir une base à fragment utiliser fragmentpour l'écran, fragmentssont légers par rapport aux activites fragments sont des fragments réutilisables sont mieux adaptés pour une application qui prend en charge à la fois le téléphone et la tablette

Vous êtes libre d'en utiliser un.
Fondamentalement, vous devez évaluer la meilleure solution pour votre application. Réfléchissez à la façon dont vous gérerez le flux commercial et à la façon de stocker / gérer les préférences de données.

Pensez à la façon dont les fragments stockent les données de déchets. Lorsque vous implémentez le fragment, vous avez une racine d'activité à remplir avec des fragments. Donc, si vous essayez d'implémenter beaucoup d'activités avec trop de fragments, vous devez considérer les performances de votre application, car vous manipulez (parle grossièrement) le cycle de vie de deux contextes, souvenez-vous de la complexité.

Rappelez-vous: dois-je utiliser des fragments? Pourquoi pas?

Cordialement.

J'utilise des fragments pour une meilleure expérience utilisateur. Par exemple, si vous avez un bouton et que vous souhaitez 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 deuxièmement, je préfère les fragments parce que vous pouvez les manipuler facilement pendant la rotation.

Cela dépend vraiment de ce que vous voulez construire. Par exemple, navigation drawerutilise des fragments. Les onglets sont également utilisés fragments. Une autre bonne implémentation est celle où vous avez listview. Lorsque vous faites pivoter le téléphone et cliquez sur une ligne, l'activité est affichée dans la moitié restante de l'écran. Personnellement, j'utilise fragmentset fragment dialogs, comme c'est plus professionnel. De plus, ils sont manipulés plus facilement en rotation.