Combien activités vs Fragments ?

Question

Intro:

La base des "Fragments Tutoriel" modèle va quelque chose comme ceci:

1. Sur une tablette, une liste sur la gauche, plus de détails sur la droite.
2. Les deux sont Fragments et résident tous les deux dans le même Activity.
3. Sur un téléphone, d'avoir un liste Fragment dans un Activity.
4. Le lancement d'un nouveau Activity avec les détails Fragment.

(par exemple, Android 3.0 Fragments de l'API par Dianne Hackborn et les Fragments de l'API Guide)

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

Sur la Tablette, l'ensemble de l'application est de 1 Activity, sur le téléphone, il y a beaucoup d' Activities.

---

Questions:

• Est-il une raison pour diviser l'application téléphone dans nombre Activities?

Un problème avec cette méthode, c'est que vous dupliquer beaucoup de la logique dans les principaux Tablet Activity, et dans le Téléphone, Activities.

• Ne serait-il pas plus facile de conserver l'1 modèle d'Activité dans les deux cas, en utilisant la même logique de commutation Fragments in et out (juste en utilisant une mise en page différente)?

De cette façon, la plupart de la logique réside dans l' Fragments eux-mêmes, et il n'y a qu'un seul Activity - moins de duplication de code.

Aussi ce que j'ai lu à propos de l' ActionBarSherlock , c'est qu'il semble mieux fonctionner avec Fragments au lieu de Activities (mais je n'ai pas travaillé avec elle pour le moment).

Sont les tutoriels simpliste, ou ai-je raté quelque chose de plus important dans cette approche?

---

Nous avons essayé les deux approches, avec succès, dans le bureau, mais je suis sur le point de commencer un gros projet et que vous voulez rendre les choses plus facile pour moi que possible.

Quelques liens vers des questions connexes:

• Des motifs lors de l'utilisation de l'Activité de Transition vs Dynamique des Fragments
• android - besoin de quelques précisions de fragments vs activités et points de vue
• Des activités ou des fragments dans Android?
• De multiples fragments et des activités de conception de l'interaction
• Alors, quels sont exactement les avantages de Fragments dans Android 3.0?

---

Mise à jour

Commencé bounty sur la question - toujours pas convaincu sur le pourquoi j'ai besoin de dupliquer mon application logique dans ma tablette activité et dans chaque activité du téléphone.

Answer 1

Je suis d'accord que les tutoriels sont très simplifiée. Ils ont juste introduire Fragments mais je ne suis pas d'accord avec le modèle, comme l'a suggéré.

Je suis aussi d'accord que ce n'est pas une bonne idée de dupliquer votre application logique à travers de nombreuses Activités (voir Principe SEC sur wikipédia).

---

Je préfère le modèle utilisé par l' ActionBarSherlock des Fragments de Démonstration de l'application (à télécharger ici et le code source ici). La démo qui se rapproche le plus du tutoriel mentionné dans la question, l'un appelé "Mise en page" dans l'app; ou FragmentLayoutSupport dans le code source.

Dans cette démo, la logique a été déplacé hors de l' Activity et dans l' Fragment. L' TitlesFragment contient en fait la logique de l'évolution des Fragments. De cette façon, chaque Activité est très simple. Pour dupliquer beaucoup de très simple Activités de, où aucune logique est à l'intérieur de la des Activités, il est très simple.

Par mettre de la logique dans les Fragments, il n'y a pas besoin d'écrire du code plus d'une fois; il est disponible à n'importe quelle Activité le Fragment est placé dans. Cela en fait un de plus puissant motif que celui proposé 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 de l' ABS modèle est que vous ne finissent pas avec une Tablette Activité contenant beaucoup de logique, et cela signifie que vous économiser de la mémoire. Le tutoriel modèle peut conduire à une très grande activité principale dans une application plus complexe, puisqu'il doit gérer la logique de tous les fragments qui seront placés en lui à tout moment.

Dans l'ensemble, ne pense pas que ça pouvait être forcé d'utiliser de nombreuses activités. Pense avoir eu la possibilité de fractionner votre code en de nombreux fragments, et la sauvegarde de la mémoire lors de leur utilisation.

Answer 2

Je pense que vous êtes sur la bonne voie. (Et oui, les tutos sont très simplifiée).

Dans une tablette, mise en page, vous pouvez utiliser une seule Activité et de swap dans et hors des Fragments (en plusieurs volets'). Alors que dans un téléphone de mise en page, vous pouvez utiliser une nouvelle Activité pour chaque Fragment.

Comme suit:

Il peut sembler comme beaucoup de travail supplémentaire, mais en utilisant de multiples activités pour les téléphones, vous permettre de base de l'Activité du cycle de vie et l'Intention de passer. Cela permet également le cadre pour gérer toutes les animations et l'arrière de la pile.

Pour aider à réduire le code, vous pouvez utiliser un BaseActivity et d'étendre.

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

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

La partie délicate est de routage d'intentions et autres joyeusetés. *(Edit: voir plus loin).

Je pense que la raison c'est la méthode recommandée est d'économiser de la mémoire et de réduire la complexité et de couplage. Si vous échangez des Fragments, l' FragmentManager maintient une référence à ce Fragment à l'arrière de la pile. Il simplifie également ce qui doit être 'running' pour l'utilisateur. Cette configuration dissocie également les points de vue et la mise en page et de la logique dans le Fragment de l'Activité du cycle de vie. De cette façon, un Fragment peut exister qu'une seule activité, à côté d'un autre fragment (deux panneaux), ou dans les trois volets de l'Activité, etc.

*L'un des avantages d'avoir régulièrement intention de routage, c'est que vous pouvez lancer une Activité explicitement à partir de n'importe où dans le dos de la pile. Un exemple pourrait être dans le cas de résultats de recherche. (MySearchResults.class).

Lire ici pour plus d':

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

Il pourrait être un peu plus avant le travail, car chaque fragment doit bien fonctionner à travers des activités distinctes, mais il rapporte habituellement. Cela signifie que vous pouvez utiliser d'autres modes de mise en page des fichiers qui définissent les combinaisons de différents fragments, garder le fragment de code modulaire, de simplifier la barre d'action de la gestion, et de laisser le système gérer tout l'arrière de la pile de travail.

Answer 3

Un problème avec cette méthode, c'est que vous dupliquer beaucoup de la logique dans le principal de la Tablette de l'Activité, et dans le séparer les Activités de téléphonie.

Dans le maître-détail du motif, il y a deux activités. Une montre à la fois des fragments sur des écrans plus grands et seul le "maître" fragment sur les petits écrans. L'autre montre le "détail" fragment sur les petits écrans.

Votre logique de détails devraient être lié dans le détail fragment. Par conséquent, il n'y a pas de duplication de code lié à une logique de détails entre les activités -- le détail de l'activité ne fait qu'afficher le détail fragment, peut-être en transmettant des données à partir d'un Intent supplémentaire.

Aussi ce que j'ai lu sur le ActionBarSherlock est qu'il semble mieux fonctionner avec des Fragments au lieu d'Activités (mais je n'ai pas travaillé avec elle pour le moment).

ActionBarSherlock a plus rien à faire avec les fragments que le natif de la barre d'action, depuis ActionBarSherlock est purement un rétroportage de la native de la barre d'action.