Comme je l'ai commencé à adopter des fragments de plus en mieux, mais aussi comme la fonctionnalité des fragments est augmentée (fragments dans des fragments, MAPFRAGments) Je commence à atteindre un point où j'ai besoin de définir quand je devrais faire une nouvelle vue / action comme un fragment ou une activité?
Une activité est définie comme suit:
Une activité est une seule chose ciblée que l'utilisateur peut faire.
Mais un fragments ont un peu pris cette définition comme décrit dans la DOCS:
Par exemple, une application de nouvelles peut utiliser un fragment pour afficher une liste de articles à gauche et un autre fragment pour afficher un article sur le Les deux fragments à droite apparaissent dans une activité
Ceci est deux choses que l'utilisateur peut faire dans une activité avec deux fragments.
Je voudrais donc que certaines entrées / aident à déterminer quelle est la meilleure approche pour décider si je devrais faire une nouvelle action / vue comme un fragment ou une activité?
3 Réponses :
La réponse dépend de vous et de vos pratiques de développement (ou celles de votre entreprise). Cependant, mon opinion est la suivante: au minimum, si vous pensez que la fonctionnalité développée pourrait être utilisée dans plusieurs activités, ou si elle pourrait être utilisée dans une activité à côté d'une autre vue (comme sur une tablette), alors vous devriez le faire un fragment.
Nous avons récemment adopté la philosophie de créer des fragments dans tous les cas. Nos activités ne sont maintenant que des coordinateurs de haut niveau, fondamentalement la colle qui apporte des choses ensemble. Cela permet une architecture cohérente et flexible. Cela est important pour nous car nous avons de nombreux ingénieurs dans quelques endroits travaillant sur le code.
Créer des fragments dans tous les cas a également été ma philosophie mais parfois vous avez simplement ces énormes cas qui vous font me demander si c'est une bonne pratique orientée objet ...
Oui, nous en avons aussi. Cependant, lorsque j'ai besoin d'éditer un autre code de développeurs, je connais le modèle et cela facilite l'analyse du code. Le retour sur investissement de ce modèle fonctionne pour nous. Vous devez le demander si cela fonctionne pour vous.
Il existe d'autres options pour garder les activités plus légères et avoir pour leur donner deux rôles comme 1) être un fragment de converse et 2) un coordinateur de la logique de l'UI des fragments. Cela conduira à un manque de cohésion et de couplage rendra plus difficile de réutiliser des fragments. Vous pouvez envisager d'utiliser un bus d'événement pour coordonner des fragments tels que Eventbus ou Otto.
Je développe à Android depuis 1,5 ans, je me développe donc de nombreuses activités de temps et récemment fragments.
Des fragments assez souvent laissés avec un goût acide dans ma bouche ... Un exemple était quand j'avais besoin d'une sorte de tableau de bord paginé avec des boutons. Pour cela, j'ai utilisé un fragment d'affichage + 1 fragment par bouton. J'ai eu toutes sortes de problèmes car avant que Android 4.2 Les fragments ne puissent être niités.
Un autre problème était le mode asynchrone de la fonction des fragments que lorsque le nécessaire pour être déplacé d'un endroit à l'autre assez rapidement, il avait toutes sortes de malfaisants.
Ne pensez pas que tout était mauvais ... dans des cas plus simples, l'utilisation de fragments a fonctionné assez bien.
Donc, à mon avis, chaque fois que vous avez une zone autonome, qui n'est pas déplacé fréquemment sur les points de vue, qui peuvent être réutilisés dans plusieurs écrans et que vous soutiens également les comprimés (ou mon avenir), Utilisez-le.
Si vous avez besoin de fragments imbriqués, des vues qui sont réorganisées assez fréquemment ou que le code ne sera pas réutilisé, n'est pas.
Une activité est définie comme suit: "Une activité est une seule chose ciblée que l'utilisateur peut faire"
C'est plus un problème de la documentation datée que toute autre chose.
Activité a cette même définition ... lorsque nous sommes sur une taille d'écran plus petite (par exemple, téléphone). Lorsque vous passez à des écrans plus volumineux, les chances d'une activité étant plus complexe que "une seule chose ciblée" augmente.Je voudrais donc que certaines entrées / aident à déterminer quelle est la meilleure approche pour décider si je devrais faire une nouvelle action / vue comme un fragment ou une activité?
Voici mon heuristique généraliste:
Si vous prévoyez que la pièce d'interface utilisateur de ce type pourrait exister sur un écran de taille d'un téléphone, mais être utilisée en tandem avec quelque chose d'autre sur un écran de taille comprimé, faites-en un fragment.
Si vous prévoyez que la pièce d'interface utilisateur de ce type existera toujours autonome, créez simplement une activité simple.
Si vous prévoyez que votre capacité à anticiper n'est pas si bonne, err depuis le côté de faire plus de fragments. Par exemple, vous pourriez dire: «Bien, l'aide n'aura jamais besoin d'être à côté d'autre» et de faire une activité. Ensuite, si vous réalisez que d'autres pièces d'interface utilisateur pourrait bénéficier de l'aide côte à côte avec eux plutôt que de désactiver le sien - afin que l'utilisateur puisse lire les documents et effectuer les actions à En même temps, vous regretterez de ne pas avoir fait de l'aide Soyez un fragment, car vous devrez faire du nouveau travail.
Si une partie de l'interface utilisateur de ce type n'existe jamais autonome - en d'autres termes, si cela ressemble plus à un widget unique qu'une activité complète - et que vous prévoyez de l'utiliser sur plusieurs projets, faites-la. être un widget unique, sous la forme d'une vue personnalisée
ougroupe de vue .Mais, comme l'indique Jsmith, il n'y a pas de bonne réponse universelle ou mauvaise. BTW, Afaac, la réponse de Jsmith est la bonne ici, mais j'allais être beaucoup trop ver que pour un commentaire sur sa réponse ...: -)
Esprit expliquant ce que sont les nouvelles vues? Cela dépend vraiment de ce que vous allez faire avec ce nouveau point de vue / action
Comme aller d'une liste aux détails etc.
Mais disons que nous avons une activité d'onglet avec des listes dans chaque onglet et des éléments de barre d'action qui contient également du contenu à afficher.
Les fragments sont généralement utiles lorsque vous attachez plusieurs types de vues / fonctionnalités. Dans votre cas, il semble que vous souhaitiez avoir un fragment pour votre liste et un fragment pour vos détails. Cela vous donne la possibilité de réutiliser votre fragment où vous voulez, placer le fragment où vous avez besoin, remplaçant vos fragments à la volée .. etc. etc. Beaucoup d'avantages à des fragments
@dymmeh je suis d'accord, c'est pourquoi je l'ai adopté fortement. Mais je viens d'avoir un projet avec une activité principale sur de nombreuses lignes de code ne faisant rien d'autre que de communiquer entre des fragments de démarrage / remplacement de fragments, etc. C'est ce que c'est juste la voie à suivre ou que je manque quelque chose?
Je connais le sentiment de faire ça. Malheureusement, pour permettre la communication entre fragments qui est la voie à suivre. Combien de fragments avez-vous généralement à l'écran? Que passez-vous entre eux?
@dymmeh souvent, je n'ai souvent que 1 fragment et je suis généralement en train de passer des informations qui doivent être utilisées pour ouvrir un nouveau fragment, etc.
1 fragment devrait être assez trivial pour gérer je penserais? Peut-être que vous pouvez nous montrer ce que vous faites et nous pouvons vous aider à la réduire
@DYMMMEH Je ne cherche pas une réponse basée sur une affaire :) Je cherche une idée / approche de la façon dont je devrais l'aborder. J'utilise peut-être déjà le meilleur moyen, mais si quelqu'un a eu une bonne idée, j'aimerais l'entendre.