Tutoriel Android : tout comprendre sur les Fragments

L'interface graphique du fragment se définit dans un fichier xml. Il n'y a aucune différence entre un fichier xml de layout (avant HoneyComb) pour une activité et un fichier xml de layout pour un fragment. Vous pouvez utiliser les mêmes composants graphiques, les mêmes layouts, la syntaxe est identique. Il n'y a pas de différence.

<LinearLayout 
    android:layout_width="wrap_content"
    android:layout_height=" fill_parent">

    <TextView 
    android:id="@+id/name"
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content"
    android:text="@string/hello" />

    <ListView 
    android:id="@+id/myListView"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"/>

</LinearLayout>

Votre classe Fragment (MyFragment par exemple) étend simplement Fragment et la seule chose obligatoire est de surcharger la méthode onCreateView.

@Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
     View view = inflater.inflate(R.layout.speaker_detail, container, false);
     //Instancier vos composants graphiques ici (faites vos findViewById)
     return view; }

Le point important se produit lors du gonflage de la vue inflater.inflate(R.layout.speaker_detail, container, false). En effet, le dernier paramètre est à false . Ce paramètre spécifie si la vue doit être automatiquement attachée à son container parent. Dans le cas d'un fragment, cette liaison doit être laissée au système qui se charge de la rattacher comme il se doit à l'activité.

C'est dans cette classe que vous allez coder votre comportement, faire vos findViewById et tout le code que vous auriez mis dans votre activité. Il suffit de coder « comme avant », directement dans votre fragment.

Pour qu'une activité utilise un fragment statique, il suffit de déclarer le fragment en tant qu'objet graphique au sein du fichier de layout de votre activité.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent"android:layout_height="fill_parent"
android:orientation="vertical" >

    <fragment
        android:id="@+id/list" 
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:name="com.android2ee.tuto.fragment.sample1.ListFragment"
        android:orientation="horizontal" >
    </fragment>

</LinearLayout>

Les points importants sont :

• La balise fragment (en minuscule je vous prie) ;
• la balise android:name qui permet de spécifier quelle est la classe qui prend en charge l'implémentation du fragment ;
• La balise android:id (resp. android:tag qui permet de spécifier un identifiant entier (resp. de type String) unique au fragment, ce qui est très important lors de la manipulation dynamique des fragments ;
• Et bien sûr, la manière dont le fragment remplit l'espace via les balises layout_width et layout_height.

Et voilà, c'est terminé, la méthode onCreate de votre activité ressemble à ça :

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    //Définissez votre vue, rien de plus. Tout sera pris en charge par le fragment qui affiche les données
    setContentView(R.layout.activity_main);
    //Retrouvez votre fragment en utilisant son identifiant (si besoin)
    MainFragmentHC mainFragment=(MainFragmentHC)findViewById(R.id.list_fragment);
}

Vous pouvez lancer votre application, elle s'exécutera.

Le plus efficace pour positionner les fragments est d'utiliser la balise weight qui permet de répartir l'espace libre entre les composants graphiques affichés au sein d'un LinearLayout. Cela va vous permettre de les positionner où vous le souhaitez dans l'espace tout en leur donnant leur proportion les uns par rapport aux autres.

Ainsi, vous souhaitez que le fragment A prenne 1/3 de l'espace en largeur et le fragment B 2/3, il vous suffit de les déclarer de la manière suivante :

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="match_parent">

    <fragment android:name="com.example.news.FragmentA"
    android:id="@+id/list"
    android:layout_weight="1"
    android:layout_width="0dp"
    android:layout_height="match_parent" />

    <fragment android:name="com.example.news.FragmentB"
    android:id="@+id/viewer"
    android:layout_weight="2"
    android:layout_width="0dp"
    android:layout_height="match_parent" />

</LinearLayout>

L'astuce, ici, est de demander une taille de 0dp aux fragments. L'espace libre restant correspond à la largeur complète du layout. La balise weight redistribue cet espace libre à chacun des composants 1/3 pour le fragment A qui pèse 1 (car 1+2=3 et vaut le poids total) et 2/3 pour le fragment B qui pèse 2.

En fait le principe est le suivant :

L'activité A connait les fragments qu'elle contient. Les fragments ne connaissent pas leur conteneur, mais uniquement les CallBack que l'activité A implémente.

L'activité se charge l'orchestration de ses fragments, elle les écoute et les met à jour. C'est à elle de passer l'information de l'un à l'autre, de lancer une activité paire pour afficher le second (cas statique) ou de changer les fragments (cas dynamique).

Ainsi, dans l'exemple de Google, le fragment A appelle l'activité A (via le onItemSelected de l'interface FragmentACallBack). L'activité A doit alors connaitre son contexte ; si elle affiche deux fragments, elle doit mettre le second fragment à jour, si elle n'affiche qu'un fragment, elle doit lancer l'activité B.

En code cela donne :

//Quelque part dans ActivityA extends Activity
// Cas statique
public void onItemSelected(String id) {
    // Si deux panels sont visibles,
    if (mTwoPane) {
        ItemDetailFragment fragment = getSupportFragmentManager().getFragmentByTag(itemDetailTag);
                  fragment.setItem(id)
    } else {
        // Lancement de l'activité B : Définition de l'Intent
                    Intent detailIntent = new Intent(this, ItemDetailActivity.class);
        // Ajout des paramètres d'initialisation de l'activité
                    detailIntent.putExtra(ItemDetailFragment.ARG_ITEM_ID, id);
        // Lancement de l'activité
                    startActivity(detailIntent);
        }
    }

Le projet ci-contre implique la structure suivante:

• src

  • ActivityA (extends Activity implements FragmentACallBack, FragmentBCallBack)
  • ActivityB (extends Activity implements FragmentBCallBack)
  • FragmentA (extends Fragment)
  • FragmentACallBack
  • FragmentB (extends Fragment)
  • FragmentBCallBack

• res\layout

  • activity_a_layout
  • activity_b_layout
  • fragment_a_layout
  • fragment_b_layout

• res\layout-port||res\layout-large||res\layout-xlarge

  • activity_a_layout

L'un des éléments les plus importants lorsque l'on développe une application Android est de ne pas perdre le contexte utilisateur quand celui-ci tourne son écran (entre autres). Ainsi quand l'application est détruite pour être immédiatement recréée, il nous faut sauvegarder puis restaurer ce contexte ; cela peut être les valeurs contenues dans les EditText, les choix des cases à cocher, l'item de la liste sélectionné, la valeur de la scrollView…

Pour mettre en place cette restauration, l'activité utilise les méthodes onRestoreInstanceState et onSaveInstanceState qui permettent de stocker dans un Bundle (une HashMap typée) les différents champs primitifs ou parcelables que l'on souhaite passer de l'activité mourante à l'activité recréée.

Un exemple de l'utilisation de ces méthodes dans une activité :

/*******************************************************************/
/** Managing Rotation change ***************************************/
/*******************************************************************/
/* * (non Javadoc)
 *  * @see android.app.Activity#onRestoreInstanceState(android.os.Bundle)
 */
@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
    super.onRestoreInstanceState(savedInstanceState);
    // Restauration des données du contexte utilisateur
    edtMessage.setText(savedInstanceState.getString(EDT));
    for (Parcelable human : savedInstanceState.getParcelableArrayList(LIST)) {
        messages.add((Human) human);
    }
}

/*
 * (non Javadoc)
 * 
 * @see android.app.Activity#onSaveInstanceState(android.os.Bundle)
 */
@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    // Sauvegarde des données du contexte utilisateur
    outState.putString(EDT, edtMessage.getText().toString());
    outState.putParcelableArrayList(LIST, messages);
}

Dans cet exemple, nous stockons et restaurons la chaîne de caractères contenue dans l'EditText edtMessage ainsi que la liste des objets (ici, des humains) affichés par la listView.

La méthode onSaveInstanceState possède pour paramètre le bundle (outState) qui sera renvoyé en paramètre de la méthode onRestoreInstanceState (savedInstanceState). Ainsi, dans la méthode onSaveInstanceState on stocke les données à sauvegarder dans ce bundle et dans la méthode onRestoreInstanceState on les restaure à partir de ce bundle.

Ces méthodes sont appelées dans le cycle de vie de l'activité de la manière suivante :

E/MainActivity(10447): MainActivityHC Launched
E/MainActivityHC(10447): onCreate called
E/MainActivityHC(10447): onStart called
E/MainActivityHC(10447): onResume called
<-- Rotation de l'écran-->
E/MainActivityHC(10447): onPause called
E/MainActivityHC(10447): onSaveInstanceState called
E/MainActivityHC(10447): onStop called
E/MainActivityHC(10447): onDestroy called
E/MainActivityHC(10447): onCreate called
E/MainActivityHC(10447): onStart called
E/MainActivityHC(10447): onRestoreInstanceState called
E/MainActivityHC(10447): onResume called

III-B-4-a. Mise en place de la restauration avec les fragments▲

public void onActivityCreated(Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);
    if (savedInstanceState != null) {
        // Restauration des données du contexte utilisateur
        mCurCheckPosition = savedInstanceState.getInt("curChoice", 0);
    }
}

public void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    // Sauvegarde des données du contexte utilisateur
    outState.putInt("curChoice", mCurCheckPosition);
}

Tant qu'à être dans la problématique de la sauvegarde et de la restauration des données lors d'un changement de configuration de l'appareil (cas de la rotation de l'écran), penchons-nous sur le problème de la rétention d'objets qui ne peuvent être ni parcelables, ni primitifs, ni serializables.

L'exemple typique est la gestion des Threads (qui, si vous avez une bonne architecture, ne devrait jamais arriver). Vous souhaitez retenir l'instance de la Thread si votre activité est détruite pour être immédiatement reconstruite. Avant, vous utilisiez la méthode onRetainConfigurationInstance de la classe activité. Cette méthode est dépréciée depuis HoneyComb.

En effet, depuis HoneyComb, il est préconisé d'utiliser des fragments sans I.H.M. à qui on demande de ne pas mourir lors du processus de destruction/recréation de l'activité qui les contient. Ainsi vous créez un fragment sans I.H.M. (une vraie classe par exemple, MyWorkingFragment extends Fragment).

Pour qu'un fragment ne soit pas détruit lorsque l'activité est détruite pour être recréée, il suffit d'appeler la méthode setRetainInstance(true) sur ce fragment.

III-B-5-a. setRetainInstance▲

III-B-5-b. Exemple▲

private static final String WORKER_FRAGMENT_TAG="WORKER_FRAGMENT_TAG";

// Quelque part dans votre code
workerFragment.setRetainInstance(true);

//****************/
// Ailleurs dans votre code (dans onCreate, onResume ou onStart)
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft=fm.beginTransaction();
ft.add(workerFragment, WORKER_FRAGMENT_TAG);
ft.commit();
//****************/

//Ailleurs dans le code
//Pour récupérer votre working fragment
WorkerFragment workerFragment=(workerFragment)fm.findFragmentByTag(WORKER_FRAGMENT_TAG);

Un élément à bien comprendre dans l'utilisation des fragments. L'objectif d'un fragment est d'être utilisé par plusieurs activités. De ce fait, le fragment ne peut pas connaître l'activité qui le contient. Mais alors comment communique-t-il avec elle ? L'idée est simple, toute activité qui souhaite contenir un fragment implémente une interface qui sera utilisée par le fragment pour communiquer avec son conteneur.

Inversement, une activité connait les fragments qu'elle contient, elle peut donc pointer directement sur eux.

Ce principe se résume ainsi :

Un exemple :

L'interface :

public interface MainFragmentCallBack {
    /**
    * Un item a été sélectionné dans le fragment
    * En tant que CallBack du fragment, vous devriez faire quelque chose avec cette information
    * @param itemId
    */
    public void onItemSelected(int itemId);
}

La classe de l'activité :

public class MainActivityHC extends Activity implements MainFragmentCallBack {
/*Some code*/

    /* * (non Javadoc)
     *
     * @see com.android2ee.tuto.fragment.fragmentstatic.tuto.view.honeycomb.main.MainFragmentCallBack#onItemSelected(int)
     */
    @Override
    public void onItemSelected(int itemId) {
    //Faîtes votre traitement ici
    }
}

La classe du fragment :

public class MainFragmentHC extends Fragment {
    /**
     * Le parent du fragment (son callback/sonactivité contenante)
     */
    private MainFragmentCallBack parent;

    /*
     * (non Javadoc)
     * 
     * @see android.app.Fragment#onAttach(android.app.Activity)
     */
    @Override
    public void onAttach(Activity activity) {
        Log.w("MainFragmentHC", "onAttach called");
        super.onAttach(activity);
        // Utilisez cette méthode pour lier votre fragment avec son callback
        parent = (MainFragmentCallBack) activity;
    }

    /**
     * Un item a été sélectionné, notifier le changement
     * @param position of the item
     */
    public void onItemSelected(int position) {
        //Notifiez le parent qu'un item a été sélectionné
        parent.onItemSelected(position);
        //Faîtes d'autres traitements ici au besoin
    }
}

Ce pattern est obligatoire dès lors qu'un fragment est contenu par plus d'une activité ; il est recommandé dans tous les cas.

Inversement, vous pouvez, dans vos fragments, appeler la méthode getActivity pour récupérer le contexte si vous en avez besoin. Il vous faut alors n'utiliser que les méthodes de la classe activité (pas de méthode spécifique).

Il est naturel que les fragments souhaitent rajouter des MenuItem quand ils sont actifs. En effet, ils doivent porter les actions associées aux éléments qu'ils affichent.

Pour cela, vous devez dans le fragment :

• invoquer setHasOptionMenu(true) dans la méthode onCreate du fragment ;
• Surcharger les méthodes onCreateOptionsMenu et onOptionsItemSelected, comme pour les activités.

Dans l'activité :

• Surcharger les méthodes onCreateOptionsMenu et onOptionsItemSelected, comme d'habitude et rajouter dans le default un appel au super pour que les menus des fragments soient pris en compte.

Ainsi :

Le code de l'activité :

public boolean onCreateOptionsMenu(Menu menu) {
    //Appelez le super pour collecter les menu items de vos fragments
    super.onCreateOptionsMenu(menu);
    //Construisez le menu de l'activité
    getMenuInflater().inflate(R.menu.activity_menu, menu);
    //et voilà
    return true;
}
@Override
public boolean onOptionsItemSelected(MenuItem item) {
    switch (item.getItemId()) {
    case R.id.menu_activity_item1:
        // Faire un truc, ce menu item appartient à l'activité, c'est à elle de le traiter
        return true;
    default:
        //Appelez vos fragments pour qu'ils vérifient si ce menu item n'est pas sous leur responsabilité
        return super.onOptionsItemSelected(item);
}}

Le code du fragment :

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setHasOptionsMenu(true);
}
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
    inflater.inflate(R.menu.fragment_menu, menu);
    super.onCreateOptionsMenu(menu);
}
public boolean onOptionsItemSelected(MenuItem item) {
    switch (item.getItemId()) {
    case R.id.fragment_menu_item1:
        // Faîtes un truc, ce menu item appartient au fragment, c'est à lui de le traiter
        return true;
    default:
        //Continuez à chercher quelqu'un qui va gérer ce menu 
        return super.onOptionsItemSelected(item);
}}

Vous verrez qu'un élément fondamental dans vos gestions des fragments est de répondre à la question suivante « Combien de fragments suis-je en train d'afficher ? ». Certains font des calculs complexes ou demandent aux fragments de dire à l'activité qu'ils sont visibles ou je ne sais quel algorithme tordu.

Restez simple et efficace, utilisez les ressources !

Tout d'abord, vous allez définir vos fichiers de layouts dans le dossier res\layout (et pas de suffixe). Là vous allez définir vos fichiers main_activity_two_panes.xml, main_activity_one_pane.xml (et d'autres à 3, 4 ou plus de fragments, si vous en avez besoin). Ainsi tous vos fichiers de description des I.H.M. sont au même endroit.

Maintenant, votre activité va charger le fichier main_activity.xml (qui n'existe pas, on est bien d'accord) :

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    //Construisez la vue de l'activité, rien de plus. Le fragment prend en charge le reste.
    setContentView(R.layout.main_activity);
}

Et là vous allez utiliser les redirections dans vos ressources :

Pour cela, vous allez créer les dossiers values-large, values-land, values-large-land et dans chacun de ces dossiers vous allez créer le fichier refs.xml (vous auriez pu l'appeler toto.xml, mais refs possède une sémantique plus claire). Ce fichier refs.xml est le suivant :

<resources>
<item name="main_activity" type="layout">@layout/activity_two_panes</item>
<bool name="twoPane">true</bool>
</resources>

D'une part il redirige le layout main_activity.xml vers le layout activity_two_pane et d'autre part il spécifie le booléen twoPane à true, car le layout activity_two_panes possède bien deux fragments (two panes signifiant deux panneaux).

Si vous souhaitiez que dans cette configuration, le layout ne possède qu'un seul fragment, il suffisait de rediriger vers activity_one_pane :

<resources>
<item name="activity_main" type="layout">@layout/main_activity_one_pane</item>
<bool name="twoPane">false</bool>
</resources>

Enfin, vous auriez pu remplacer le booléen twoPane par un entier :

<resources>
<item name="activity_main" type="layout">@layout/main_activity_one_pane</item>
<int name="fragmentNumber">3</int>
</resources>

Dans votre activité, ou n'importe où dans votre code, pour connaitre ce nombre de fragments, ou le booléen twoPane, il vous suffit de faire l'appel suivant :

//Récupérez le nombre de fragments affichés 
boolean twoPane = getResources().getBoolean(R.bool.twoPane);

Vous avez ainsi accompli deux choses :

• Pas de duplication inutile des fichiers de layout (factorisation et redirection) ;
• Parfaite connaissance du nombre de fragments affichés (contexte des fragments).

Et le projet, votre équipe et l'équipe de maintenance vous en remercient.

Votre projet est structuré de la manière suivante :

Remarque importante : La LauncherActivity finit son code par un appel à finish(), c'est essentiel. Cela signifie à l'activité qu'elle doit mourir et surtout ne pas se placer dans la backstack. En effet, si on oublie cette ligne, quand la nouvelle activité est lancée, LauncherActivity se place dans la backstack. Quand l'utilisateur quitte l'activité Main (post ou pré-HoneyComb, cela n'a pas d'importance), cela relancera alors automatiquement LauncherActivity (car on dépile la backstack). Et comme LauncherActivity relance MainActivity, votre utilisateur ne pourra pas sortir de MainActivity…

1. Commencez par coder l'activité post-HoneyComb.
2. Créez votre activité pré-HoneyComb, que nous appellerons ActivityLegacy. Copiez/collez le code de l'activité post-HoneyComb dans l'activité que vous venez de créer.
3. Modifier ActivityLegacy pour qu'elle hérite de FragmentActivity (et non plus d'Activity). Vous pouvez aussi hériter de ActionBarActivity si vous souhaitez faire apparaître l'action bar quelle que soit la version de l'appareil (mais c'est encore une autre histoire que je ne vous conterai pas dans cet article).
4. Puis, supprimez tous les imports de la classe ActivityLegacy et remplacez-les par ceux de la support-library.

Voilà, vous avez fini.

import android.support.v4.app.FragmentActivity;

public class ItemListActivity extends FragmentActivity {
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_item_list);
    FragmentManager fm=getSupportFragmentManager() ;
    .... blabla ....}
    }

Un dernier détail, la récupération du FragmentManager s'effectue via la méthode getSupportFragmentManager (et non plus par getFragmentManager).

Pour migrer un fragment natif en fragment de la support-library, rien de plus simple, vous copiez/collez la classe du fragment natif (celui codé pour les versions post-HoneyComb). Vous supprimez ces imports et vous les remplacez par ceux de la support-library.

Pour instancier un fragment en lui passant des paramètres, il suffit d'utiliser la méthode setArguments.

Bundle arguments = new Bundle();
arguments.putString(ItemDetailFragment.ARG_ITEM_ID, id);
ItemDetailFragment fragment = new ItemDetailFragment();
fragment.setArguments(arguments);

Le fragment n'a plu qu'à appeler la méthode getArguments (n'importe où dans son code) pour récupérer le bundle associé à sa création.

if (getArguments().containsKey(ARG_ITEM_ID)) {
mItem = DummyContent.ITEM_MAP.get(getArguments().getString(ARG_ITEM_ID));
    }

Pour information, avec une activité on utilise le setExtras et le getIntent().getExtras.

Le corollaire de cette restauration automatique des fragments lors de la destruction/recréation de l'activité est la bonne pratique suivante :

Tous vos layouts déclinés en mode landscape-portrait doivent avoir les mêmes layout containers même s'ils ne sont pas utilisés.

En d'autres termes, votre activité affiche deux fragments dans le mode landscape et un seul en mode portrait (ou vice-versa), vous devez déclarer les 2 LinearLayouts pour recevoir les deux fragments dans les deux fichiers xml de layout de l'activité. C'est-à-dire :

res\layout\main_layout.xml

(Un seul fragment)

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
... blabla ...>
    <FrameLayout android:id="@+id/item_list_container"
        android:layout_width="0dp"
        android:layout_height="match_parent"/>

    <FrameLayout android:id="@+id/item_detail_container"
        android:layout_width="0dp"
        android:layout_height="match_parent"
        android:visibility="gone" />
</LinearLayout>

res\layout-land\main_layout.xml

(Deux fragments)

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
... blabla ...>
    <FrameLayout android:id="@+id/item_list_container"
        android:layout_width="0dp"
        android:layout_height="match_parent"/>

    <FrameLayout android:id="@+id/item_detail_container"
        android:layout_width="0dp"
        android:layout_height="match_parent"
/>
</LinearLayout>

Si vous ne faites pas ça, vous ne restaurerez pas le second fragment dans le cas de la destruction/recréation de votre activité deux fois de suite :

Deux rotations de l'appareil : land -> port -> land (2° fragment non restauré).

Notez que cette bonne pratique ne s'applique quasiment qu'au cas landscape/portrait. En effet, il est rare de changer la taille ou la densité d'un appareil au run-time.

En fait le, principe est le suivant :

L'activité A connait les fragments qu'elle contient. Les fragments ne connaissent pas leur conteneur, mais uniquement leur CallBack. Ces callbacks ne sont plus implémentés par l'activité elle-même, mais par une classe FragmentSwitcher dans laquelle on a déporté le code de gestion des fragments.

Le FragmentSwitcher a en charge l'orchestration de ses fragments, elle les écoute, les met à jour, les supprime et les crée. C'est à elle de passer l'information de l'un à l'autre ou de changer les fragments (cas dynamique).

Ainsi dans l'exemple de Google, le fragment A appelle l'activité A (via le onItemSelected de l'interface FragmentACallBack). L'activité A doit alors connaitre son contexte ; si elle affiche deux fragments, elle doit mettre le second fragment à jour, si elle n'affiche qu'un fragment, elle doit afficher le fragment B (et donc le créer).

En code cela donne :

/***********************************************************************/
/** OnItemSelection Management *******************************************/
/**********************************************************************/
/* * (non Javadoc) * 
 * @see com.android2ee.tuto.fragment.fragment.dynamic.tuto.view.callback.MainFragmentCallBack#
 * onItemSelected(int) */
@Override
public void onItemSelected(int itemId) {
    // OK le moment du choix
    //En fonction du nombre de fragments affichés, soit detailFragment doit être mis à jour, soit il faut changer le fragment affiché dans le premier layout par detailFragment
    if (twoPanes) {
        onItemSelectedTwoPanes(itemId);
    } else {
        onItemSelectedOnePane(itemId);
    }
}
/**
 * OnPane Management 
 * Gestion du cas où il n'y a qu'un layout
 * @param itemIdthe item to display
 */
public void onItemSelectedOnePane(int itemId) {
    // Ne conservez jamais une référence vers un fragment en vue de le réinstancier
    // (DetailFragmentHC) fm.findFragmentByTag (detailFragmentFPTag) devrait être nul
    // Nous avons besoin de le créer puis de l'ajouter au layout
    // En effet Soit il n'a pas été créé (première création)
    // Soit il a été détruit (créé puis backstack.popup appelé)
    // Dans tous les cas, il n'existe plus

    // Trouver le gestionnaire de fragment
    FragmentManager fm = activity.getFragmentManager();
    DetailFragmentHC detailFragmentFirstPane = (DetailFragmentHC)     fm.findFragmentByTag(detailFragmentFPTag);
    if (null == detailFragmentFirstPane) {
        //Comportement normal
        detailFragmentFirstPane = new DetailFragmentHC();
        //Ajoutez la position de l'item en argument de création du fragment
        //Utilisez le pattern de l'argument
        Bundle bundle = new Bundle();
        bundle.putInt(DetailFragmentHC.ITEM_ID, itemId);
        detailFragmentFirstPane.setArguments(bundle);
        //Remplacez mainFragment par detailFragment
        FragmentTransaction fTransaction = fm.beginTransaction();
        // Définissez les animations
        fTransaction.setCustomAnimations(R.anim.anim_push_left_in, 
            R.anim.anim_push_left_out,
            R.anim.anim_push_right_in,
            R.anim.anim_push_right_out);
        // Remplacez, ajoutez à la backstack et commit
        fTransaction.replace(R.id.firstpane, detailFragmentFirstPane, detailFragmentFPTag);
        fTransaction.addToBackStack(activity.getString(R.string.main_fragment));
        fTransaction.commit();
    } 
}
/**
 * TwoPane Management
* Gestion du cas où il y a deux layouts
 * @param itemIdthe item to display
 */
public void onItemSelectedTwoPanes(int itemId) {
    // Trouvez le FragmentManager
    FragmentManager fm = activity.getFragmentManager();
    // Le fragment existe et a déjà été ajouté au layout
    // Ainsi, retrouvez-le et mettez-le juste à jour
    DetailFragmentHC detailFragmentSecondPane = (DetailFragmentHC)     fm.findFragmentByTag(detailFragmentSPTag);
    // Mise à jour donc :
    detailFragmentSecondPane.updateData(itemId);
}

Pour une activité qui met en place des fragments dynamiquement, il est une bonne pratique qui consiste à extraire de l'activité tout le code correspondant à la gestion des fragments dans une classe à part dédiée à cette problématique. Cette classe n'est autre que le FragmentSwitcher (vous pouvez l'appeler comme bon vous semble).

Ainsi, vous centralisez dans le FragmentSwitcher toute votre gestion des fragments. La classe FragmentSwitcher implémente tous les callbacks des fragments qu'elle gère.

Vous pouvez avoir plusieurs FragmentSwitchers pour une même activité. Par exemple, FragmentSwitcherHuman pour gérer les fragments affichant les humains, FragmentSwitcherDroid pour les fragments affichant les droids. Cela permet à la navigation de changer de contexte de fragments plutôt que de lancer une nouvelle activité pour afficher les droids.

Enfin, cela permet à l'activité de se concentrer sur ce dont elle est responsable : cycle de vie, écoute des Intents…

La liaison Activity-FragmentSwitcher est de type 1 - [0 ,1]. L'activité possède un ou 0 FragmentSwitcher, le FragmentSwitcher possède toujours une activité.

Les fragments ne connaissent plus l'activité, mais uniquement le FragmentSwitcher.

Il est naturel que certains fragments soient considérés comme des « activités » d'un point de vue utilisateur et que l'appui sur le bouton back réaffiche le fragment précédemment affiché. En effet, pour l'utilisateur, lancer une nouvelle activité ou afficher un nouveau fragment est pour lui transparent. Il doit donc pouvoir dépiler sa navigation au sein des fragments comme il le faisait avec les activités.

Pour mettre en place ce mécanisme, il suffit d'ajouter le fragment à la backstack.

// Ajoutez le fragment
fTransaction.replace(R.id.mainfragment, eventsListFragment, eventsListFragmentTag);
// Ajoutez la transaction à la backstack
fTransaction.addToBackStack(mainActivity.getString(R.string.main_htitle));
// Faîtes le commit
fTransaction.commit();

En fait, ce n'est pas le fragment qui est ajouté à la backstack, mais la transaction. Quand la backstack sera dépilée, la transaction sera inversée. Plus subtilement, cela signifie aussi que le fragment est conservé dans la backstack et dépiler la backstack le restaurera. Cela signifie au niveau du cycle de vie du fragment un petit changement.

Quand on supprime ou l'on remplace un fragment et qu'on le dépose dans la backstack :

• Les méthodes onPause, onStop et onDestroyView sont appelées sur le fragment quand il est placé dans la backStack.
• Et les méthodes onCreateView, onActivityCreated, onStart et onResume quand il en est dépilé.

Placer un fragment dans la backstack impacte le cycle de vie du fragment.

VI-D-4-a. Backstack : ne la supposez pas▲

Quand on manipule les fragments dynamiquement, il est toujours nécessaire de savoir où on en est ; quel est l'état de la backstack, quels sont les fragments instanciés, détruits.

En effet, quand on affiche ou réaffiche un fragment, le choix de la méthode show, add ou replace est primordial, de même que l'appel aux méthodes addToBackstack et popBackstack.

Pourtant, sur un simple exemple, s'il l'on considère le diagramme d'état de la backstack, on voit qu'il nous est impossible de prévoir l'état de la backstack :

Ainsi, au lieu d'imaginer que l'on sait quel est l'état de la backstack, il nous faut la requêter et, en fonction du résultat, faire un popBackStack, un ajout, un replace ou un show du fragment. C'est la bonne pratique « Toujours interroger la backstack avant d'instancier un fragment » expliquée plus bas dans l'article.

De la même manière que pour la gestion statique des fragments, vous allez mettre en place le système des redirections de vos layouts avec les fichiers du type :

<resources>
<itemname="main_activity"type="layout">@layout/activity_two_panes</item>
<boolname="twoPane">true</bool>
</resources>

L'objectif est de toujours connaitre le nombre de fragments affichés à l'écran et de centraliser vos fichiers de layout dans res\layout.

Pour mettre en place les animations lors des transitions entre les fragments, vous êtes obligés d'utiliser le parallel activity pattern étendu.

Il vous faut vérifier quelle est la version de l'appareil sur laquelle s'exécute votre application. Si cette version est inférieure à HoneyComb vous devez utiliser les TweenAnimations, si elle est supérieure à HoneyComb, vous mettrez en place les ObjectAnimators.

Vous allez donc avoir deux dossiers anim et anim-v11 possédant les mêmes fichiers (par exemple monAnim.xml), mais dans anim, vous utiliserez les TweenAnimation et dans anim-v11 vous utiliserez les ObjectAnimator.

Ainsi vous aurez les fichiers suivants :

res\anim\anim_push_left.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android">

<translate
    android:duration="500"
    android:fromXDelta="100%p"
    android:toXDelta="0"/>

<alpha
    android:duration="500"
    android:fromAlpha="0.0"
    android:toAlpha="1.0"/>

<scale
    android:duration="500"
    android:fromXScale="0.0"
    android:fromYScale="0.0"
    android:pivotX="50%"
    android:pivotY="50%"
    android:toXScale="1.0"
    android:toYScale="1.0"/>

</set>

res\anim-v11\anim_push_left.xml

<?xmlversion="1.0"encoding="utf-8"?>
<setxmlns:android="http://schemas.android.com/apk/res/android">

<objectAnimator
    android:duration="1000"
    android:propertyName="translationX"
    android:valueFrom="-250"
    android:valueTo="0"
    android:valueType="floatType"/>

<objectAnimator
    android:duration="1000"
    android:propertyName="scaleX"
    android:valueFrom="0.0"
    android:valueTo="1.0"
    android:valueType="floatType"/>

<objectAnimator
    android:duration="1000"
    android:propertyName="scaleY"
    android:valueFrom="0.0"
    android:valueTo="1.0"
    android:valueType="floatType"/>

<objectAnimator
    android:duration="1000"
    android:propertyName="rotationY"
    android:valueFrom="0"
    android:valueTo="360"
    android:valueType="floatType"/>

</set>

VI-G-2-a. Le fragment est lié au layout qui le contient▲

VI-G-2-b. Ne jamais réinstancier un fragment avec une référence obsolète▲

VI-G-2-c. Toujours utiliser les tags des fragments pour les identifier et les retrouver▲