Discussion :

[Esdrael]

Bonjour à tous

Voila, je suis depuis peu des cours en développement Android, et dans ces cours, nous avons abordé la notion des fragments.

Seulement, je dois avouer que je ne comprends pas très bien, quel est leur intérêt ?
De ce que je me dis pour l'instant, ils sont la pour "fragmenter" l'espace sur la fenêtre, et ainsi permettre d'adapter le contenu de chaque partie selon la résolution de l'appareil que l'on utilise ? Mais dans ce cas, quels peuvent être concrètement les résultats sur une application ?

On nous à également présenté en cours deux manières de les implémenter : directement dans le XML, et directement dans le code .java, mais quelles sont les différences / avantages de chacune de ces solutions ? (Bien que dans le tutoriel de ce site, il semblerait qu'il faille jouer dans les deux codes simultanément ).

Et enfin, en imaginant que l'application que je développe ne soit destinée qu'aux téléphones, est ce qu'il sera réellement utile d'utiliser des fragments ?

Pour l'exemple, il s'agit d'une application d'annuaire, pour lister des contacts, les géolocaliser , et converser ( appels & SMS ), mais en imaginant qu'une tablette ne permette pas (Je crois?) d'appeler, d'envoyer des SMS, les fragments ont-ils vraiment leur place dans une application de ce genre ?


Voila voila, j'espère que mes questions ne sont pas aussi confuses que l'idée que je me fais des fragments :/

Merci à tous

[nicroman]

En fait, les autres me corrigeront si je me trompe, mais le concept des applications Android est totalement différent des applications bureau ou autre.

Pour l'utilisateur, la notion "d'application" n'existe qu'à l'installation (un "package", c'est d'ailleurs le nom qu'on lui donne de manière interne).
Par la suite, la seule que l'utilisateur "connait" ce sont les activités.

Une application peut ainsi fournir une (l'appareil photo par exemple, ou le Scanner de QR code) ou plusieurs activités (galerie par exemple, qui permet de voir un album d'image, ou une image en particulier) à l'utilisateur.


Les activités communiquent entre elles par le biais des Intent.
Dans le meilleur des mondes, le code ne devrait jamais dire au système "je veux que tu lance telle classe d'activité", mais "l'utilisateur veut faire ceci". Dans ce cas, si l'utilisateur a installé plusieurs packages permettant d'effectuer l'opération, le choix lui est offert.
Exemple type: "Je veux partager telle image" => toutes les applications capables de prendre une image en "source" vont répondre.

En découle alors la définition du bouton "back": Annuler l'activité en cours, et revenir à la précédente.


Donc en gros,
un groupe d'applications desktop = un package / application android
une application desktop = une activité



Cependant ce découpage marche assez mal dans certains cas. Je pense en particulier aux boites de dialogue (rares sous Android heureusement) qui pourraient ressembler à des activités à part entière (d'ailleurs au départ elle en étaient, et elles peuvent toujours l'être).
D'autre part la nécessité de supporter diverses plateformes hétéroclites forcent à utiliser des activités "légèrement" différentes en fonction du device (le liste+details qui s'affichent en même temps sur une tablette, mais dans deux activités séparées sur téléphone par exemple), mais qui partagent le même code.
Pour ces raisons ont été introduit les fragments.

Le fragments permettent plus de souplesse qu'un setContentView, ou qu'une manipulation "manuelle" des views, dans le sens ou quand le système doit tuer l'activité (pour une raison ou une autre), le bon fragment est bien recréé quand nécessaire et dans le même état.


Donc grosso modo:
Fragment = partie d'interface partagée entre plusieurs activités (d'une même application), ou utilisée de manière "additionnelle" à l'activité (boites de dialogue, drawers, menus, ...)., ou faisant partie de l'activé (les tabs par exemple).


Voilà voilà....

Donc grosso modo:
Application sous android on oublie (c'est juste un fourre-tout avec manifests et déclarations)
Activity = opération désirée par l'utilisateur.
Fragment = partie d'UI d'une activity.

[Esdrael]

Donc en fait, si j'ai bien compris

Le package / application englobe la totalité de ce qui tournera au lancement

L'activité représente ce que veut faire l'utilisateur

Et le fragment est la pour afficher une fenêtre "moins importante " sans prendre trop de place, et en conservant l'activité comme fenêtre principale ?

[nicroman]

Le package / application englobe la totalité de ce qui tournera au lancement

Pas au lancement, non,
Mais la totalité de ce qui sera connu du système et des interactions entre le système/l'utilisateur et ce contenu.

L'activité représente ce que veut faire l'utilisateur

Absoluement. En général c'est limité à un truc simple: "jouer une partie", "prendre une photo", "partager une musique", "envoyer un message", ....
A noter que "lancer depuis le 'launcher'" fait partie des trucs en question

Ensuite entre l'action voulue (l'intent), et ce qui est affiché (l'activité) il n'y a pas de limite... plusieurs activités peuvent être proposées pour la même action (le choix sera mis entre les mains de l'utilisateur), une activité peut répondre à plusieurs intent ("afficher une galerie d'image", "lancer depuis le launcher" et "choisir une image" par exemple iront tous trois vers l'activité de présentation d'image en mode album, avec quelques subtilités en fonction de l'intent).

Et le fragment est la pour afficher une fenêtre "moins importante " sans prendre trop de place, et en conservant l'activité comme fenêtre principale ?

Oui, ou pour partager du code facilement entre plusieurs activités.
Ou encore pour proposer une "navigation" dans l'application qui ne se limite pas à une suite d'activités.

[grunk]

Donc en gros,
un groupe d'applications desktop = un package / application android
une application desktop = une activité

Je suis pas tout à fait d'accord avec ça.
Dans la plus part des applications que je réalise les activités ne sont pas atteignables par d'autre applications. Mais j'ai tout de même besoin de plusieurs activités pour séparer les différentes parties de mon applications.
Par exemple je peux avoir une activité me permettant de creer quelques chose et une activité me permettant d'utiliser ses quelques choses. Sur une appli desktop ca se matérialisera par des fenêtres différentes au sein d'une même appli et pas des applis différentes.

Pour moi une activité = une fonctionnalité.
On peut ensuite fragmenter cette fonctionnalité en fragment pour diverses raison.

Les deux principales raisons d'utiliser des fragments sont pour moi :
- La réutilisation : Faire apparaître une fonctionnalité dans divers endroit sans avoir à réeecrire quoi que ce soit.
- L'interface graphique : L'exemple le plus typique est l'utilisation d'un side panel sur une tablette (sélection dans une liste à gauche et détail à droite) alors que sur le téléphone on aura 2 écrans successif. C'est ce qui se passe dans les paramètres android par exemple.

Après les fragments ne sont pas forcément simple à appréhender et ne sont pas indispensables (mais pratique).

Pour l'exemple, il s'agit d'une application d'annuaire, pour lister des contacts, les géolocaliser , et converser ( appels & SMS ), mais en imaginant qu'une tablette ne permette pas (Je crois?) d'appeler, d'envoyer des SMS, les fragments ont-ils vraiment leur place dans une application de ce genre ?

Des tablettes peuvent être équiper d'une carte SIM. Donc les SMS à priori pas de problème , les appels à partir du moment ou elle dispose d'un micro pas de problème non plus. On à juste l'air d'un con à téléphoner avec une tablette
Sans oublier que certains téléphone peuvent être considéré comme des tablettes. C'était arrivé avec les premie galaxy note par exemple.

[MathiasSeguy]

+1 pour grunk
Ca sert à ne pas avoir tout son code dans son activité et du coup on extraie le code spécifique à la vue, ce qui fait que l'activité est plus petite et donc plus claire.
Et puis, ça c'est très vrai:

Les deux principales raisons d'utiliser des fragments sont pour moi :
- La réutilisation : Faire apparaître une fonctionnalité dans divers endroit sans avoir à réeecrire quoi que ce soit.
- L'interface graphique : L'exemple le plus typique est l'utilisation d'un side panel sur une tablette (sélection dans une liste à gauche et détail à droite) alors que sur le téléphone on aura 2 écrans successif. C'est ce qui se passe dans les paramètres android par exemple.

Et aussi, dans mon article, j'explique les deux contextes, dynamique et statique, il ne faut pas faire les deux, il faut choisir l'un ou l'autre. Lequel choisir ? Tu commences par le statique et quand t'en peux plus de déclarer des activités pour afficher un fragment tu passes au dynamique parce que "putain fait chier de créer des classes pour rien..." grosso modo.
Et sinon, si de nos jours tu n'utilises pas les fragments, même pour une application triviale, tu fais une erreur, c'est ainsi qu'on code les applications, cela fait partie des bonnes pratiques actuelles (depuis 2011...).

[nicroman]

Ben voilà, je savais que tout le monde ne serait pas d'accord (et tant mieux).

Par exemple je peux avoir une activité me permettant de creer quelques chose et une activité me permettant d'utiliser ses quelques choses. Sur une appli desktop ca se matérialisera par des fenêtres différentes au sein d'une même appli et pas des applis différentes.

Oui... ACTION_VIEW mon.data.type et ACTION_EDIT mon.data.type

Pour moi une activité = une fonctionnalité.

Ouais c'est ça... en bon français... une activité = ... une activité quoi !

Les deux principales raisons d'utiliser des fragments sont pour moi :
- La réutilisation : Faire apparaître une fonctionnalité dans divers endroit sans avoir à réeecrire quoi que ce soit.
- L'interface graphique : L'exemple le plus typique est l'utilisation d'un side panel sur une tablette (sélection dans une liste à gauche et détail à droite) alors que sur le téléphone on aura 2 écrans successif. C'est ce qui se passe dans les paramètres android par exemple.

C'est aussi ce que je disais... mais le cas le plus fréquent d'utilisation des fragments (hors navigations dynamiques, et tabs) est encore les boites de dialogue.