Une activité et tous les autres fragments [fermé]

Je pense mettre en œuvre un écran avec Activityet tous les autres écrans avec Fragmentset managing all the fragments thru the activity.

Est-ce que c'est une bonne idée? et ma réponse est NON mais je veux tout de même en savoir plus clairement sur cette pensée.

Quels sont les avantages et les inconvénients de l'idée?

Remarque:

Veuillez ne pas me donner le lien pour le fragment et l'activité.

ÉDITER:

Voici quelque chose sur les fragments et l'activité:

Avantages:

1. Les fragments sont destinés à être utilisés avec des activités en tant que sous-activité.
2. Les fragments ne remplacent pas les activités.
3. Les fragments sont destinés à être réutilisés (besoin de savoir de quelle manière la réutilisabilité peut être obtenue.).
4. Les fragments sont le meilleur moyen d'écrire du code pour prendre en charge les tablettes et les téléphones.

Les inconvénients:

1. Nous devons implémenter l'interface pour obtenir les données des fragments.
2. Pour le dialogue, nous devons faire un long chemin pour le montrer.

Pourquoi utiliser des fragments si nous n'envisageons pas de comprimés? Quelle est la différence d'heure de départ entre l'activité et le fragment?

Cela dépend de l'application que vous créez. J'ai créé plusieurs applications en utilisant les deux approches et je ne peux pas dire qu'une façon est toujours meilleure que l'autre. La dernière application que j'ai créée a utilisé l' Activityapproche unique et une navigation de style Facebook. Lorsque je sélectionne des éléments dans la liste de navigation, je mets à jour un seul Fragmentconteneur pour afficher cette section.

Cela dit, avoir un single Activityintroduit également beaucoup de complexités. Supposons que vous ayez un formulaire d'édition et que pour certains des éléments que l'utilisateur doit sélectionner ou créer, il doit accéder à un nouvel écran. Avec les activités, nous appellerions simplement le nouvel écran avec, startActivityForResultmais Fragmentsil n'y a rien de tel, vous finissez donc par stocker la valeur sur le Activityet demander au fragment d'édition principal de vérifier Activitysi les données ont été sélectionnées et doivent être affichées à l'utilisateur.

Ce que dit Aravind sur le fait d'être collé à un seul Activitytype est également vrai mais pas vraiment limitatif. Votre activité serait une FragmentActivity et tant que vous n'en avez pas besoin, MapViewil n'y a pas de réelles limitations. Si vous souhaitez afficher des cartes, cela peut être fait, mais vous devrez soit modifier la bibliothèque de compatibilité Android pour l' FragmentActivityétendre, MapActivitysoit utiliser les cartes android-support-v4-googlemaps disponibles au public .

En fin de compte, la plupart des développeurs que je connais qui Activityont emprunté la même voie sont revenus à plusieurs activités pour simplifier leur code. En ce qui concerne l'interface utilisateur, sur une tablette, vous êtes parfois coincé en utilisant un seul Activitypour réaliser l'interaction jamais folle que vos concepteurs proposent :)

-- ÉDITER --

Google a enfin publié MapFragmentla bibliothèque de compatibilité afin que vous n'ayez plus à utiliser le hack android-support-v4-googlemaps. En savoir plus sur la mise à jour ici: API Google Maps Android v2

- MODIFIER 2 -

Je viens de lire ce super article sur l'état moderne (2017) des fragments et je me suis souvenu de cette vieille réponse. Je pensais que je partagerais: Fragments: la solution à tous les problèmes d'Android

Je suis sur le point de terminer un projet (5 mois en développement), qui comporte 1 activité et 17 fragments, tous en plein écran. Ceci est mon deuxième projet basé sur des fragments (le précédent était de 4 mois).

Avantages

• L'activité principale est de 700 lignes de code, juste bien gérer l'ordre de navigation des fragments.
• Chaque fragment est joliment séparé dans sa propre classe et est relativement petit (~ quelques centaines de lignes de trucs d'interface utilisateur).
• La direction peut dire: "hé, pourquoi ne pas changer l'ordre de ces écrans", et je peux le faire très facilement, car ces fragments ne dépendent pas les uns des autres, ils communiquent tous à travers l'activité. Je n'ai pas à fouiller dans les activités individuelles, pour trouver où ils s'appellent.
• mon application est très graphique et ne fonctionnerait jamais comme activité 1 écran 1. Toutes ces sous-activités dans la mémoire rendraient l'application à court de mémoire tout le temps, donc je devrais finish()toutes les activités non visibles et créer la même logique de contrôle pour la navigation, comme je le ferais avec des fragments. Autant le faire avec des fragments juste à cause de cela.
• si jamais nous faisons une application pour tablette, nous aurons plus de facilité à re-factoriser les choses, car tout est déjà bien séparé.

Les inconvénients

• vous devez apprendre, comment utiliser des fragments

Tout d'abord, quoi que vous fassiez, assurez-vous d'avoir une conception modulaire utilisant un modèle, une vue, un présentateur qui ne dépend pas fortement d'une activité ou d'un fragment.

Que fournissent réellement les activités et les fragments?

1. Événements du cycle de vie et backstack
2. Contexte et ressources

Par conséquent, utilisez-les UNIQUEMENT pour cela . Ils ont suffisamment de responsabilités, ne les compliquez pas trop. Je dirais que même introduire un TextView dans une activité ou un fragment est une mauvaise pratique. Il y a une raison pour laquelle des méthodes telles que Public View findViewById (int id) sont PUBLIC .

Maintenant, la question devient plus simple: ai-je besoin de plusieurs événements et backstacks indépendants du cycle de vie? Si vous pensez que oui peut-être, utilisez des fragments. Si vous ne pensez jamais jamais, n'utilisez pas de fragments.

En fin de compte, vous pouvez créer votre propre backstack et cycles de vie. Mais pourquoi recréer la roue?

EDIT: Pourquoi voter contre cela? Gens de classes à but unique! Chaque activité ou fragment doit pouvoir instancier un présentateur qui instancie une vue. Le présentateur et la vue sont un module qui peut être interchangé. Pourquoi une activité ou un fragment devrait-il avoir la responsabilité d'un présentateur?

Avantages

Vous pouvez contrôler vos fragments à partir d'une seule activité, car tous les fragments sont indépendants les uns des autres. Les fragments ont un cycle de vie ( onPause, onCreate, onStart...) de leur propre. En ayant un cycle de vie, les fragments peuvent répondre indépendamment aux événements, enregistrer leur état onSaveInstanceStateet être ramenés (par exemple lors de la reprise après un appel entrant ou lorsque l'utilisateur clique sur le bouton retour).

Les inconvénients

1. Créez de la complexité dans votre code d'activité.
2. Vous devez gérer l'ordre des fragments.

Néanmoins, c'est une très bonne idée, comme si vous deviez créer une application, dans laquelle vous souhaitez afficher plusieurs vues. Grâce à cette idée, vous serez en mesure de visualiser plusieurs fragments dans une seule vue.

Cela dépend de la disposition de conception de votre application. Supposons que si vous utilisez des onglets dans ActionBar dans la mise en page de conception, dans l'activité unique de l'application, des fragments peuvent être modifiés lors d'un clic sur l'onglet. Alors maintenant, vous avez une activité et supposons que trois onglets dans l'ActionBar et la vue des onglets fournis par les fragments, ce qui le rend facile à gérer, est également faisable. Donc, tout dépend du schéma de conception de votre application et de la manière dont vous prenez la décision de la créer.

Avantages:

• Peut être utilisé pour créer une interface unique utilisable par plusieurs tailles d'écran et orientations via des mises en page XML.

Les inconvénients:

• Nécessite un code plus complexe dans votre activité.

Je pense que c'est une bonne idée, car l'utilisation de différentes mises en page XML en fonction de la taille et de l'orientation actuelles de l'écran peut rendre l'application plus utilisable et réduire le besoin de publier plusieurs versions de votre application si vous prévoyez de publier votre application pour les téléphones et les tablettes. Si votre application ne sera jamais utilisée par les tablettes et les téléphones, cela ne vaut probablement pas la peine.

Je suis partisan du report de toute vue sur l'inflation à des fragments pour offrir une meilleure flexibilité. Par exemple, avoir une seule activité d'atterrissage pour une tablette qui regroupe plusieurs fragments et réutiliser les mêmes fragments sur un téléphone pour afficher un écran par fragment. Cependant, dans la mise en œuvre du téléphone, j'aurais une activité distincte pour chaque écran. Les activités n'auraient pas trop de code car elles s'en remettraient immédiatement à leur homologue fragmenté pour voir l'inflation.

Je pense que c'est une mauvaise idée que la mise en œuvre du téléphone doive passer à une seule activité d'atterrissage lorsque des onglets ou un menu coulissant sont introduits, car la navigation dans les onglets ou les menus se traduit simplement par un écran complètement nouveau.

La raison la plus importante que je donnerais pour ne pas utiliser l'approche par activité unique est de tirer parti du cycle de vie de l'activité. Les activités contiennent le comportement contextuel d'une certaine partie de l'application et des fragments complètent ce comportement. Avoir la possibilité de tirer parti des étapes remplaçables du cycle de vie de l'activité permet de séparer le comportement d'une activité d'une autre avec des méthodes telles que onPauseet onResume. Ce cycle de vie vous permet également de revenir au contexte précédent. Avec l'approche par activité unique, une fois que vous laissez un fragment, vous devez créer un mécanisme pour y revenir.