Une activité et tous les autres fragments

Je pense à mettre en place un écran avec Activity et tous les autres écrans avec Fragments et à 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 quand même savoir plus clairement au sujet de cette pensée.

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

Remarque:

S’il vous plaît, ne me donnez pas le lien pour fragment et activité.

MODIFIER:

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

Avantages:

  1. Les fragments doivent ê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éutilisables (besoin de savoir de quelle manière la réutilisation peut être réalisée).
  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 dialogr, il faut faire un long chemin pour le montrer.

Pourquoi devrions-nous utiliser des fragments si nous ne considérons pas les comprimés? Quelle est la différence de temps 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 manière est toujours meilleure que l’autre. La dernière application que j’ai créée a utilisé l’approche de l’ Activity unique et une navigation de style Facebook. Lors de la sélection des éléments de la liste de navigation, je mets à jour un seul conteneur de Fragment pour afficher cette section.

Cela dit, avoir une seule Activity introduit également beaucoup de complexités. Supposons que vous ayez un formulaire d’édition, et 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 startActivityForResult mais avec Fragments il n’y a rien de tel. Vous startActivityForResult par stocker la valeur sur l’ Activity et le fragment d’édition principal vérifie l’ Activity pour voir si les données ont été sélectionnées et doivent être affichées à l’utilisateur.

Ce que dit Aravind sur le fait d’être coincé dans un seul type d’ Activity est également vrai, mais pas vraiment limitatif. Votre activité serait une FragmentActivity et tant que vous n’avez pas besoin de MapView il n’y a pas de réelle limitation. Si vous souhaitez cependant afficher des cartes, vous pouvez le faire, mais vous devrez soit modifier la bibliothèque de compatibilité Android pour que FragmentActivity étende MapActivity soit utiliser les MapActivity android-support-v4-googlemaps disponibles au public .

En fin de compte, la plupart des développeurs que je connais et qui ont suivi la même route d’ Activity sont revenus à plusieurs activités pour simplifier leur code. S’agissant de l’interface utilisateur, sur une tablette, vous êtes parfois bloqué par une seule Activity pour obtenir l’interaction la plus folle de vos concepteurs 🙂

— MODIFIER —

Google a finalement publié MapFragment sur la bibliothèque de compatibilité pour que vous n’ayez plus à utiliser le hack android-support-v4-googlemaps. Lisez à propos de la mise à jour ici: Google Maps Android API v2

– EDIT 2 –

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

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

Avantages

  • L’activité principale est de 700 lignes de code, gérant simplement l’ordre de navigation des fragments.
  • Chaque fragment est bien séparé en sa propre classe, et est relativement petit (quelques centaines de lignes de données d’interface utilisateur).
  • La direction peut dire, “hé, que diriez-vous de 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 une activité 1 écran 1. Toutes ces sous-activités de la mémoire rendraient l’application à court de mémoire, donc je devrais finish() toutes les activités non visibles et faire 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 nous réalisons une application pour tablette, nous aurons plus de facilité à re-factoriser, car tout est déjà bien séparé.

Les inconvénients

  • il faut apprendre à 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 beaucoup d’une activité ou d’un fragment.

Que sont vraiment les activités et les fragments?

  1. 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 complique pas trop. Je dirais que le fait d’introduire un TextView dans une activité ou un fragment est une mauvaise pratique. Il y a une raison pour laquelle les méthodes telles que public View findViewById (int id) sont PUBLIC .

Maintenant, la question devient plus simple: Ai-je besoin d’événements multiples et indépendants du cycle de vie? Si vous pensez oui, utilisez des fragments. Si vous ne pensez jamais, n’utilisez pas de fragments.

En fin de compte, vous pourriez créer votre propre cheminement et votre propre cycle de vie. Mais pourquoi recréer la roue?

EDIT: Pourquoi down vote this? Classes à usage 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 être 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 …) qui leur est propre. En ayant un cycle de vie, les fragments peuvent répondre indépendamment aux événements, enregistrer leur état via onSaveInstanceState et être ramené (par exemple, lors de la reprise après un appel entrant ou lorsque l’utilisateur clique sur le bouton Précédent).

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 bonne idée, comme si vous deviez créer une application où vous souhaitez afficher plusieurs vues. Avec cette idée, vous pourrez voir plusieurs fragments dans une seule vue.

Cela dépend de la conception de votre application. Supposons que si vous utilisez les tabs dans ActionBar dans la structure de conception, dans l’activité unique de l’application, des fragments peuvent être modifiés sur un clic d’onglet. Donc, maintenant vous avez une activité et dites: supposez trois tabs dans la barre d’action et la vue pour les tabs fournis par les fragments, ce qui facilite la gestion et est également réalisable. Donc, tout dépend du schéma de conception de votre application et de la manière dont vous décidez de la construire.

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 basées sur la taille d’écran et l’orientation actuelles 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 sur téléphone ou tablette. 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 de reporter tous les avis sur l’inflation à des fragments pour offrir une meilleure flexibilité. Par exemple, avoir une activité d’atterrissage unique pour une tablette qui regroupe plusieurs fragments et réutilise les mêmes fragments sur un téléphone pour afficher un écran par fragment. Cependant, dans l’implémentation 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 fragmentaire en ce qui concerne l’inflation.

Je pense que c’est une mauvaise idée que l’implémentation du téléphone doive passer à une seule activité d’atterrissage lorsque des tabs ou un menu déroulant sont introduits, car l’onglet ou la navigation dans les menus donne un écran complètement nouveau.

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