Dilemme: quand utiliser les Fragments par rapport aux activités:

les Experts vous diront: "quand je vois L'UI, je saurai s'il faut utiliser un Activity ou un Fragment ". Au début, cela n'aura aucun sens, mais avec le temps, vous pourrez dire si vous avez besoin de Fragment ou non.

il y a une bonne pratique que j'ai trouvé très utile pour moi. Il 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 articles de la première boîte? Si la réponse est oui, alors vous devez utiliser Fragments , parce que la racine Activity peut 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.

veillez à ne pas abuser de la boîte. Les experts D'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 à l'aise avec Fragments , vous pouvez regarder toutes leurs vidéos. Même plus, ils sont obligatoires matériel.

pouvez-vous maintenant regarder votre UI et de comprendre si vous avez besoin d'un Activity ou un Fragment ? Avez-vous un nouveau point de vue? Je pense que vous avez fait.

ma philosophie est celle-ci:

ne Créer une activité que si elle est absolument nécessaire. Avec le backstack mis à disposition pour commettre un tas de transactions de fragments, j'essaie de créer un minimum d'activités dans mon application que possible. De plus, il est beaucoup plus facile de communiquer entre divers fragments plutôt que d'envoyer des données d'une activité à l'autre.

les transitions D'activité sont chères, non? Au moins je le crois - depuis le ancienne activité à détruire/arrêter/arrêter, poussée sur la pile et puis la nouvelle activité doit être créée/commencée / reprise.

c'est juste ma philosophie depuis que les fragments ont été introduits.

Eh bien , selon les cours de Google (peut-être ici , Je ne me souviens pas), vous devriez envisager D'utiliser des Fragments chaque fois que c'est possible, car il 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 si difficile de convertir une activité en fragment et vice versa.

j'ai créé un billet 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é est coûteuse. Dans Fragment, les vues et les états de propriété sont séparés - chaque fois qu'un fragment est dans backstack , ses vues seront détruites. Donc vous pouvez empiler beaucoup plus de Fragments que D'activité.

• Backstack la manipulation. Avec FragmentManager , il est facile de nettoyer tous les Fragments, insérer plus que sur les Fragments et etcs. Mais pour l'Activité, ce sera un cauchemar pour manipuler ces trucs.

• beaucoup prévisible cycle de vie . Tant que l'activité hôte n'est pas recyclée. les Fragments dans le dos ne seront pas recyclés. Il est donc possible d'utiliser FragmentManager::getFragments() pour trouver un Fragment spécifique (non encouragé).

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

1. combien de fois allez-vous réutiliser des parties de L'UI (menus par exemple),
2. est l'application aussi pour les comprimés?

l'utilisation principale de fragments est de construire des activités multipane, ce qui le rend parfait pour les applications sensibles tablette/téléphone.

il y a plus que ce que vous réalisez, vous devez vous rappeler qu'une activité qui est lancée ne détruit pas implicitement l'activité appelant. 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 de détruire l'actuelle. Cela entraîne beaucoup de frais généraux. Le meilleur guide que je puisse vous donner est:

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

Google Drive est un bon exemple de ce qui est logique lorsqu'il y a plusieurs activités. L'activité principale fournit un explorateur de fichier. Lorsqu'un fichier est ouvert, une nouvelle activité est lancé pour afficher ce fichier. Vous pouvez appuyer sur le bouton 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 à la première.

N'oubliez pas qu'une activité est le bloc/composant d'une demande qui peut être partagé et commencé par intention! Ainsi, chaque activité de votre application doit résoudre un seul type de tâche. Si vous n'avez qu'une seule tâche dans votre application, alors je pense que vous avez besoin d'une seule activité et de nombreux 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 besoin de maintenir 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 exigences.

chose que j'ai fait: utiliser moins de fragments quand c'est possible. Malheureusement, c'est possible dans presque cas. Donc, je finis avec beaucoup de fragments et un peu d'activités. Je me suis rendu compte de certains inconvénients:

• ActionBar & Menu: Quand 2 fragment a un titre différent, menu, que
  
  sera difficile à gérer. Ex: lors de l'ajout d'un nouveau fragment, vous pouvez changer le titre de la barre d'action, mais quand pop il de backstack il n'y a aucun moyen de restaurer l'ancien intitulé. Vous pouvez avoir besoin d'une barre D'outils dans chaque fragment pour cette affaire, mais laissez-moi croire, qui vous passerez plus de temps.
• quand on a besoin de startForResult , l'activité a mais pas le fragment.
• ne pas avoir d'animation de transition par défaut

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

le grand avantage d'un fragment par rapport à l'activité est que le code utilisé pour les fragments peut être utilisé pour différentes activités.ainsi, il fournit réutilisable de code dans le développement d'application.

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 de 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 construire vraiment. Par exemple le navigation drawer utilise des fragments. Les onglets utilisent aussi fragments . Une autre bonne mise en œuvre,est où vous avez un listview . Lorsque vous faites pivoter le téléphone et cliquez sur une ligne, l'activité est montré dans l'autre moitié 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.

utiliser une activité par application pour fournir une base pour fragment utilisez fragment pour l'écran , fragments sont poids léger par rapport à activites les fragments sont réutilisable les fragments sont mieux adapté pour l'application qui soutiennent à la fois le téléphone et la tablette

vous êtes libre d'en utiliser un.

Fondamentalement, vous devez évaluer qui est le meilleur pour votre application. Pensez à la façon dont vous allez gérer le flux d'affaires et comment stocker/gérer les préférences de données.

pensez à la façon dont les Fragments emmagasinent les données sur les ordures. Lorsque vous implémentez le fragment, vous avez une racine d'activité à remplir avec le(s) fragment (s). Donc, si vous essayez de mettre en œuvre beaucoup d'activités avec trop de fragments, vous devez considérer performance sur votre application, car vous manipulez (grossièrement parle) deux cycle de vie de contexte, rappelez-vous la complexité.

rappelez - vous: dois-je utiliser des fragments? Pourquoi ne devrais-je pas?

cordialement.