Pourquoi utiliser des fragments ?

Question

Quel est l'avantage d'utiliser Fragment plutôt que d'utiliser des View qui sont réutilisés dans différentes mises en page ?

Dans le article de blog original présentant les fragments Dianne Hackborn dit que

Les fragments permettent aux développeurs d'écrire plus facilement des applications qui peuvent s'adapter à différentes tailles d'écran. sur une grande variété de tailles d'écran, au-delà des facilités déjà disponibles dans la plate-forme.

Elle poursuit en expliquant Fragments dans le contexte de la création d'une mise en page pour tablette d'une application qui combine l'interface utilisateur de deux activités de la version téléphone de la même application.

Mais il semble que la même réutilisation pourrait être obtenue en utilisant des vues personnalisées. La principale différence entre les fragments et les vues semble être qu'ils ont des cycles de vie différents...

Le site Fragment le cycle de vie est :

onAttach() , onCreate() , onCreateView() , onActivityCreated() , onStart() , onResume() , onPause() , onStop() , onDestroyView() , onDestroy() , onDetatch() .

Le site View le cycle de vie est :

ctor , onFinishInflate() , onAttachedToWindow() , onMeasure() , onLayout() , onDetatchedFromWindow()

J'aimerais que les développeurs ayant de l'expérience dans l'écriture de grandes applications me disent quels sont les avantages (s'il y en a) de l'utilisation de Fragments par rapport aux Vues personnalisées pour diviser l'interface utilisateur en éléments réutilisables.

Answer 1

La raison principale est que Les fragments sont plus réutilisables que les vues personnalisées.

Parfois, vous ne pouvez pas créer un composant d'interface utilisateur entièrement encapsulé en vous appuyant uniquement sur les vues. Cela est dû au fait qu'il y a des choses que vous voudriez mettre dans votre vue mais que vous ne pouvez pas car seule une activité peut les gérer, ce qui oblige à un couplage étroit entre une activité et une vue.

Voici un exemple de ce type. Supposons que vous souhaitiez créer un composant d'interface utilisateur réutilisable qui, parmi de nombreuses autres choses, souhaite capturer une photo et faire quelque chose avec. Traditionnellement, vous déclenchez une intention qui démarre l'appareil photo et revient avec l'image capturée.

Notez que votre composant d'interface utilisateur personnalisé ne peut pas encapsuler entièrement cette fonctionnalité, car il devra s'appuyer sur le composant d'hébergement Activity startActivityForResult parce que les vues n'acceptent pas les résultats des activités (elles peuvent indirectement déclencher une intention par le biais du contexte).

Si vous souhaitez réutiliser votre composant d'interface utilisateur personnalisé dans différentes activités, vous devrez répéter le code de Activity.startActivityForResult.

Fragment, par contre, résout proprement ce problème.

De même, votre fragment peut ajouter des éléments à votre menu d'options, ce que seule une activité pouvait traditionnellement faire. Encore une fois, cela pourrait être important si l'état de votre vue personnalisée dicte ce qui va dans le menu.

Answer 2

Un fragment est bien plus qu'une simple vue. En fait, il peut même être totalement dépourvu de vue. Il peut contenir toutes sortes de choses, y compris des AsyncTasks, divers Listeners, des accès à des fichiers et à des bases de données, et ainsi de suite.

Pensez-y comme à une petite activité, mais vous pouvez en avoir plusieurs à l'écran et travailler avec elles toutes, y compris communiquer entre elles pendant qu'elles sont visibles.

Par exemple, vous pourriez avoir une liste de caddies affichée dans un fragment et le caddie actuellement sélectionné en détail dans un autre fragment. Vous modifiez ensuite la quantité d'un article dans la vue détaillée et la vue de la liste peut en être informée et mettre à jour le prix total dans la vue de la liste. Il est tout à fait possible d'orchestrer des interactions de ce type tout en conservant, par exemple, une seule des deux vues visibles sur un écran plus petit.

J'ai remanié une grande application d'entreprise (>15 activités) pour passer des activités aux fragments afin d'obtenir un bon support pour les tablettes et je ne commencerai jamais une nouvelle application sans fragments.

Answer 3

Une certaine description :

Imaginez Activity comme une assiette qui contient un gros gâteau. Fragment serait un conteneur qui découpe le même gâteau en morceaux. Chaque tranche contient ses propres logiques (listeners, etc). Et au total, elles ne sont presque pas différentes de l'unique gros gâteau.

L'avantage :

1. Quand votre assiette ne peut pas contenir un gros gâteau. (L'écran est petit) Vous pouvez facilement utiliser quelques assiettes (Activité) pour contenir chacun d'entre eux SANS avoir besoin de déplacer vos logiques dans la nouvelle activité.

2. Une meilleure réutilisation. Dans certains cas, je peux réutiliser entièrement un fragment dans une autre application. Vous pourriez prétendre qu'une vue personnalisée pourrait le faire aussi. Mais si l'on se réfère au point 1, je pourrais le réutiliser avec seulement quelques lignes de modifications de la mise en page, mais pour une vue personnalisée, il faut trouver un moyen de l'intégrer à la fois dans la mise en page et dans le code.

3. Il s'agit, dans un certain sens, d'une façon plus OO d'organiser vos logiques d'interface utilisateur dans la programmation Android. Lorsque vous avez une fonctionnalité (une nouvelle partition sur l'écran par exemple), vous créez une nouvelle classe Fragment, avec une modification mineure de la classe activité existante. Cependant, si vous ne programmez qu'avec des activités, vous devrez ajouter des logiques et apporter des modifications importantes à la classe testée.

Juste mes deux centimes :)

Answer 4

Les méthodes du cycle de vie sont probablement votre plus grand indice. Si vous y réfléchissez, elles sont en étroite corrélation avec le cycle de vie des activités (avec quelques crochets dans l'activité et les vues). En fait, dans l'article que vous avez lié, Hackborn dit :

D'une certaine manière, vous pouvez considérer un fragment comme une mini-activité.

Comme pour beaucoup de choses dans la conception/développement de logiciels, il existe une multitude de façons de faire les choses. Il existe de nombreux endroits différents où vous pouvez placer votre code. Oui, vous pourriez probablement mettre beaucoup de choses dans une vue, mais garder des préoccupations différentes séparées dans des classes différentes est une bonne chose. Le modèle classique est MVC et il s'applique dans ce scénario. Vous ne voulez pas incorporer trop de logique de contrôleur dans votre vue. Il est préférable de la garder dans des classes de type contrôleur qui sont l'activité et maintenant le fragment. C'est pourquoi le cycle de vie du fragment ressemble plus à celui de l'activité qu'à celui de la vue - il a été conçu pour faciliter ce type d'organisation.

Answer 5

J'ai touché aux Fragments une fois et je les ai trouvés peu utiles (cf. ce poste ). D'après ce que j'ai lu, Un fragment est en fait un terme sophistiqué pour désigner un objet ayant accès au contexte d'activité. . J'aime ignorer les fragments dans mon travail et créer moi-même ces objets. J'ai créé des applications très grandes et très exigeantes en passant un objet Activity aux constructeurs, au lieu de Context . Toutefois, l'un des principaux avantages de l'utilisation des fragments est qu'ils sont pris en charge par le système de mise en page View. Vous pouvez donc facilement les ajouter à Android xml (si vous l'utilisez pour vos mises en page).