web-dev-qa-db-fra.com

Combien d'activités par rapport aux fragments?

Intro:

Le motif de base "Fragments Tutorial" ressemble à ceci:

  1. Sur une tablette, une liste à gauche et des détails à droite.
  2. Les deux sont Fragments et tous deux résident dans le même Activity.
  3. Sur un téléphone, ayez une liste Fragment dans un Activity.
  4. Lancez un nouveau Activity avec les détails Fragment.

(exemple: API de fragments Android 3.0 par Dianne Hackborn et le Guide de l'API de fragments )

Sur les deux appareils, la fonctionnalité est dans le Fragments. (simple)

Sur la tablette , l'application entière est 1 Activity, sur le téléphone , il y a plusieurs Activities.

Des questions:

  • Existe-t-il une raison de diviser l'application téléphonique en plusieurs Activities?

Un problème avec cette méthode, est que vous dupliquez beaucoup de la logique dans la tablette principale Activity et dans le téléphone séparé Activities.

  • Ne serait-il pas plus facile de conserver le modèle 1 Activité dans les deux cas, en utilisant la même logique de commutation de Fragments avant et arrière (en utilisant simplement une présentation différente)? ​​

De cette façon, la plupart de la logique réside dans les Fragments eux-mêmes, et il n’ya qu’une seule duplication de code Activity.

De plus, ce que j'ai lu à propos de ActionBarSherlock, c'est que cela semble mieux fonctionner avec Fragments au lieu de Activities (mais je n'ai pas encore travaillé avec).

Les tutoriels sont-ils trop simplifiés ou ai-je oublié quelque chose d'important dans cette approche?

Nous avons essayé les deux approches avec succès au bureau - mais je suis sur le point de démarrer un projet plus important et je souhaite simplifier au maximum les choses pour moi.

Quelques liens vers des questions connexes:

Mises à jour

Commencé prime sur question - toujours pas convaincu de la raison pour laquelle je dois dupliquer la logique de mon application dans l'activité de ma tablette et dans chaque activité téléphonique.

Également trouvé un article intéressant par les gars à Square, qui vaut la peine d'être lu:

androidandroid-fragmentsandroid-listfragment
184
Richard Le Mesurier

Je conviens que les tutoriels sont très simplifiés. Ils introduisent simplement Fragments mais je ne suis pas d'accord avec le modèle suggéré.

Je conviens également que ce n'est pas une bonne idée de dupliquer la logique de votre application à travers de nombreuses activités (voir Principe de DRY sur wikipedia ).

Je préfère le modèle utilisé par l'application ActionBarSherlock Fragments Demo ( téléchargez ici et code source ici ). La démo qui correspond le mieux au didacticiel mentionné dans la question est celle appelée "Layout" dans l'application; ou FragmentLayoutSupport dans le code source.

Dans cette démo, la logique a été déplacée du Activity vers le Fragment. Le TitlesFragment contient en fait la logique pour changer les fragments. De cette manière, chaque activité est très simple. La duplication de nombreuses activités très simples, où aucune logique n’est à l’intérieur des activités, le rend très simple.

En mettant la logique dans les fragments, il n’est pas nécessaire d’écrire le code plus d’une fois ; il est disponible quelle que soit l'activité dans laquelle le fragment est placé. Cela en fait un modèle plus puissant que celui suggéré par le tutoriel de base.

    /**
    * Helper function to show the details of a selected item, either by
    * displaying a fragment in-place in the current UI, or starting a
    * whole new activity in which it is displayed.
    */
    void showDetails(int index)
    {
        mCurCheckPosition = index;

        if (mDualPane)
        {
            // We can display everything in-place with fragments, so update
            // the list to highlight the selected item and show the data.
            getListView().setItemChecked(index, true);

            // Check what fragment is currently shown, replace if needed.
            DetailsFragment details = (DetailsFragment) getFragmentManager()
                .findFragmentById(R.id.details);
            if (details == null || details.getShownIndex() != index)
            {
                // Make new fragment to show this selection.
                details = DetailsFragment.newInstance(index);

                // Execute a transaction, replacing any existing fragment
                // with this one inside the frame.
                FragmentTransaction ft = getFragmentManager()
                    .beginTransaction();
                ft.replace(R.id.details, details);
                ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
                ft.commit();
            }

        }
        else
        {
            // Otherwise we need to launch a new activity to display
            // the dialog fragment with selected text.
            Intent intent = new Intent();
            intent.setClass(getActivity(), DetailsActivity.class);
            intent.putExtra("index", index);
            startActivity(intent);
        }
    }

Un autre avantage du modèle ABS est que vous ne vous retrouvez pas avec une activité de tablette contenant beaucoup de logique, ce qui signifie que vous économisez de la mémoire. Le modèle de didacticiel peut conduire à une très grande activité principale dans une application plus complexe. car il doit gérer la logique de tous les fragments qui y sont placés à tout moment.

Dans l’ensemble, ne pensez pas que cela soit forcé d’utiliser beaucoup d’activités. Considérez-le comme une possibilité de scinder votre code en plusieurs fragments et d’économiser de la mémoire lors de son utilisation.

41
Stephen Asherson

Je pense que vous êtes sur la bonne voie. (Et oui, les tutoriels sont trop simplifiés).

Dans une présentation de tablette, vous pouvez utiliser une seule activité et échanger des fragments (dans plusieurs "volets"). Dans une configuration de téléphone, vous pouvez utiliser une nouvelle activité pour chaque fragment.

Ainsi:

enter image description here

Cela peut sembler une charge de travail supplémentaire, mais en utilisant plusieurs activités pour les téléphones, vous activez le cycle de vie de l'activité de base et le transfert d'intention. Cela permet également au framework de gérer toutes les animations et le back-stack.

Pour aider à réduire le code, vous pouvez utiliser un BaseActivity et l'étendre à partir de cela.

Donc, si l'utilisateur a une tablette, vous utiliserez MyMultiPaneFragActivity ou quelque chose de similaire. Cette activité est responsable de la gestion des rappels à partir des fragments et des intentions de routage vers le bon fragment (comme une intention de recherche).

Si l'utilisateur a un téléphone, vous pouvez utiliser une activité normale avec très peu de code et le faire prolonger MyBaseSingleFragActivity ou quelque chose de similaire. Ces activités pourraient être très simples, 5 à 10 lignes de code (peut-être même moins).

La partie la plus délicate concerne les intentions de routage et tout le reste. * (Edit: voir plus ci-dessous).

Je pense que la raison pour laquelle c'est la méthode recommandée est d'économiser de la mémoire et de réduire la complexité et le couplage. Si vous permutez des fragments, le FragmentManager conserve une référence à ce fragment pour la pile arrière. Cela simplifie également ce qui devrait être "en cours d'exécution" pour l'utilisateur. Cette configuration permet également de découpler les vues, la présentation et la logique du cycle de vie Fragment from the Activity. De cette façon, un fragment peut exister dans une seule activité, à côté d'un autre fragment (à deux volets), ou dans une activité à trois volets, etc.

* L'un des avantages d'un routage d'intention régulier est que vous pouvez lancer une activité de manière explicite à partir de n'importe où dans la pile arrière. Un exemple pourrait être dans le cas des résultats de recherche. (MySearchResults.class).

Ayez une lecture ici pour plus:

http://Android-developers.blogspot.com/2011/09/preparing-for-handsets.html

Ce sera peut-être un peu plus de travail initial, car chaque fragment doit bien fonctionner dans des activités distinctes, mais il est généralement rentable. Cela signifie que vous pouvez utiliser d'autres fichiers de présentation qui définissent différentes combinaisons de fragments, garder le code de fragment modulaire, simplifier la gestion des barres d'actions et laisser le système gérer tout le travail en pile arrière.

17
pjco

Voici la réponse de Reto Meier concernant la même chose, tirée de cette vidéo de dacity's Android Cours de base .

Il y a plusieurs raisons pour lesquelles vous feriez mieux de diviser votre application en différentes activités.

  • Avoir une seule activité monolithique augmente la complexité de votre code, ce qui en rend la lecture, le test et la maintenance difficiles.
  • Rend la création et la gestion des filtres d’intention beaucoup plus difficile.
  • Augmente le risque de coupler étroitement des composants indépendants.
  • Il est beaucoup plus probable d’introduire des risques de sécurité si la seule activité inclut à la fois des informations sensibles et des informations qu’il est sans danger de partager.

Une bonne règle est de créer une nouvelle activité chaque fois que le contexte change. Par exemple, afficher un type de données différent et passer de la visualisation à la saisie de données.

6
Aditya Naique

Un problème avec cette méthode est que vous dupliquez beaucoup de la logique dans l'activité principale de la tablette et dans les activités téléphoniques distinctes.

Dans le modèle maître-détail, il y a deux activités. On montre les deux fragments sur des écrans plus grands et seulement le fragment "maître" sur des écrans plus petits. L'autre montre le fragment "détail" sur des écrans plus petits.

Votre logique de détail doit être liée au fragment de détail. Par conséquent, il n'y a pas de duplication de code liée à la logique de détail entre les activités - l'activité de détail affiche simplement le fragment de détail, peut-être en transmettant les données d'un Intent extra.

De plus, ce que j'ai lu sur ActionBarSherlock, c'est qu'il semble mieux fonctionner avec des fragments que des activités (mais je n'ai pas encore travaillé avec).

ActionBarSherlock n'a pas plus à voir avec les fragments que la barre d'action native, car ActionBarSherlock est uniquement un backport de la barre d'action native.

4
CommonsWare

En vous référant à la 1ère question de "Existe-t-il une raison de diviser l'application téléphonique en plusieurs activités?" - Oui. cela se résume simplement à l'espace disponible, une tablette laisse plus de place aux développeurs, leur permettant ainsi de mettre plus sur un seul écran. Android nous indique que Les activités peuvent fournir un écran . Donc, ce que vous pouvez faire avec un grand écran sur une tablette est quelque chose qui peut devoir être réparti sur plusieurs écrans sur un téléphone, car il n'y a pas assez de place pour tous les fragments.

0
EFlisio