Dilemme: quand utiliser Fragments vs Activités:
Je sais que Activities est conçu pour représenter un seul écran de mon application, alors que Fragments est conçu pour être des dispositions d’interface utilisateur réutilisables avec une logique intégrée à l'intérieur.
Il n'y a pas si longtemps, j'ai développé une application car elle disait qu'il fallait la développer. J'ai créé Activity pour représenter un écran de mon application et utilisé Fragments pour ViewPager ou Google Maps. J'ai rarement créé un ListFragment ou une autre interface utilisateur pouvant ê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 un autre est le MainActivity. La présentation de MainActivity contient de nombreux fragments d'interface utilisateur en plein écran masqués et un seul est affiché. Dans la logique Activity, il y a beaucoup de FragmentTransitions entre les différents écrans de l'application.
Ce que j’ai aimé de cette approche, c’est que, parce que l’application utilise un ActionBar, elle reste intacte et ne se déplace pas avec l’animation de changement d’écran, ce qui est le cas avec Activity. Cela donne une sensation plus fluide à ces transitions d'écran.
Donc, je suppose que ce que je demande, c’est de partager votre mode de développement actuel en ce qui concerne ce sujet. Je sais que cela peut ressembler à une question d’opinion au premier abord, mais je le considère comme une question de Android conception et architecture. Pas vraiment une opinion basée.
UPDATE (01.05.2014): Suite à cette présentation de Eric Burke de Square , (je dois dire que c'est une excellente présentation avec beaucoup d'outils utiles pour les développeurs Android. Et je ne suis pas lié à aucun moyen de Square)
http://www.infoq.com/presentations/Android-Design/
D'après mon expérience personnelle au cours des derniers mois, j'ai constaté que la meilleure façon de construire mes applications est de créer des groupes de fragments qui représentent un flux . 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 en tant que nombre de flux. De cette façon, la barre d’action reste intacte sur tous les écrans du flux, mais elle est recréée lors de la modification d’un flux qui a beaucoup de sens. Comme le dit Eric Burke et comme je viens de le comprendre, l’idée d’utiliser le moins possible Activities ne s’applique pas à toutes les situations car elle crée un désordre 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 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 de Fragment ou non.
J'ai trouvé une bonne pratique très utile pour moi. Cela m'est apparu 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 alors utiliser Fragments, car la racine Activity peut contenir tous les éléments dupliqués pour vous faire gagner du temps, 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.
Veillez à ne pas abuser de la boîte. Android Les experts UX conseillent (vous pouvez les trouver sur YouTube) de charger explicitement un autre Activity au lieu d'utiliser un Fragment (comme lorsque vous utilisez le tiroir de navigation qui contient catégories). Une fois que vous êtes à l'aise avec Fragments, vous pouvez regarder toutes leurs vidéos. Encore plus, ils sont obligatoires.
Pouvez-vous maintenant regarder votre interface utilisateur et déterminer si vous avez besoin d'un Activity ou d'un Fragment? Avez-vous eu une nouvelle perspective? Je pense que vous avez fait.
Ma philosophie est la suivante:
Créez une activité uniquement si elle est absolument indispensable. Avec la pile arrière disponible pour la validation de transactions de fragments, j'essaie de créer le moins d'activités possible dans mon application. En outre, la communication entre différents fragments est beaucoup plus facile que l'envoi de données entre activités.
Les transitions d'activité sont chères, non? Du moins, je le crois - puisque l’ancienne activité doit être détruite/mise en pause/arrêtée, placée sur la pile, puis la nouvelle activité doit être créée/démarrée/reprise.
C'est juste ma philosophie depuis que des fragments ont été introduits.
Eh bien, selon les conférences de Google (peut-être ici , je ne m'en souviens pas), vous devriez envisager d'utiliser Fragments dès que possible. , car cela facilite la maintenance et le contrôle de votre code.
Cependant, je pense que dans certains cas, cela peut devenir trop complexe, car l'activité qui héberge les fragments doit pouvoir naviguer/communiquer entre eux.
Je pense que vous devriez décider vous-même de ce qui vous convient le mieux. Ce n'est généralement pas difficile de convertir une activité en fragment et vice-versa.
J'ai créé un article sur ce dillema ici , si vous souhaitez en savoir plus.
Pourquoi je préfère le fragment à l'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 dans
backstack, ses vues sont détruites. Ainsi, vous pouvez empiler beaucoup plus de fragments que d’activités.Backstackmanipulation. AvecFragmentManager, il est facile d'effacer tous les fragments, d'insérer plus que sur des fragments et autres. Mais pour Activity, ce sera un cauchemar de manipuler ces choses.Un bien prévisible cycle de vie. Tant que l'activité de l'hôte n'est pas recyclée. les fragments dans la pile 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 Single-Activity est l'architecture préférée. Utile surtout avec le composant d'architecture de navigation .
A mon avis, ce n'est pas vraiment pertinent. Le facteur clé à considérer est
- combien de fois allez-vous réutiliser des parties de l'interface utilisateur (menus par exemple),
- l'application est-elle aussi pour les tablettes?
La principale utilisation des fragments est de créer des activités à volets multiples, ce qui le rend parfait pour les applications sensibles aux tablettes/téléphones.
N'oubliez pas qu'une activité est un bloc/composant de l'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 votre application ne comporte qu'une tâche, 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 claire et la séparation logique des tâches. Et vous n'avez pas besoin de gérer une activité avec différents paramètres de filtre d'intention 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 ce que vous réalisez, vous devez vous en souvenir, qu'une activité 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 celle en cours. Cela provoque beaucoup de frais généraux. Le meilleur guide que je puisse vous donner est:
** Commencez une nouvelle activité uniquement s'il est judicieux d'ouvrir l'activité principale et celle-ci en même temps (pensez à plusieurs fenêtres).
Google Drive est un bon exemple de la raison pour laquelle 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, ce qui vous permettra de revenir au navigateur sans fermer le document ouvert, voire même d’ouvrir un autre document en parallèle du premier.
Ce que j'ai fait: 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és:
ActionBar& Menu: Lorsque 2 fragments ont un titre différent, menu, que
sera difficile à gérer. Ex: lorsque vous ajoutez un nouveau fragment, vous pouvez changer le titre de la barre d’action, mais lorsqu’il est extrait debackstack, il n’ya aucun moyen de restaurer l’ancien titre. Vous aurez peut-être besoin d'une barre d'outils dans chaque fragment, mais croyez-moi, cela vous fera passer plus de temps.- Lorsque nous avons besoin de
startForResult, l'activité n'a pas 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 seul gros avantage d'une activité fragment est que le code utilisé pour fragment peut être utilisé pour différentes activités. Ainsi, il fournit la possibilité de réutiliser du code dans le développement d'applications.
utilisez une activité par application pour fournir la base pour fragment utiliser fragment pour l'écran, fragments sont poids plume par rapport à activites fragments sont - réutilisable les fragments sont mieux adapté pour les applications prenant en charge les téléphones et les tablettes
Vous êtes libre d'utiliser l'un de ceux-ci.
En gros, vous devez évaluer lequel est le meilleur pour votre application. Réfléchissez à la façon dont vous allez gérer le flux de l'entreprise et à la manière de stocker/gérer les préférences de données.
Pensez à la façon dont les fragments stockent les données de mémoire. Lorsque vous implémentez le fragment, vous avez une racine d'activité à remplir avec le (s) fragment (s). Ainsi, si vous essayez d'implémenter un grand nombre d'activités avec trop de fragments, vous devez prendre en compte les performances de votre application, car vous manipulez (parle grossièrement) le cycle de vie de deux contextes, rappelez-vous la complexité.
Rappelez-vous: dois-je utiliser des fragments? Pourquoi ne devrais-je pas?
cordialement.
J'utilise 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é parent.
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 de ce que vous voulez vraiment construire. Par exemple, le navigation drawer utilise des fragments. Les onglets utilisent également fragments. Une autre bonne implémentation est où vous avez un 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 fragments et fragment dialogs, car c'est plus professionnel. De plus, ils sont manipulés plus facilement en rotation.