Fournir un retour arrière personnalisé

Le retour arrière permet aux utilisateurs de revenir en arrière dans l'historique des écrans qu'ils ont déjà consultés. Tous les appareils Android proposent un bouton "Retour" pour ce type de navigation. Vous ne devez donc pas ajouter de bouton "Retour" à l'interface utilisateur de votre application. Selon l'appareil Android de l'utilisateur, ce bouton peut être un bouton physique ou un bouton logiciel.

Android conserve une pile "Retour" des destinations à mesure que l'utilisateur parcourt votre application. Cela permet à Android de naviguer correctement vers les destinations précédentes lorsque l'utilisateur appuie sur le bouton "Retour". Toutefois, dans certains cas, il se peut que votre application doive implémenter son propre comportement "Retour" afin d'offrir la meilleure expérience utilisateur possible.

Par exemple, lorsque vous utilisez un WebView, vous pouvez ignorer le comportement par défaut du bouton "Retour" pour permettre à l'utilisateur de revenir dans son historique de navigation Web plutôt que dans les écrans précédents de votre application.

Android 13 et versions ultérieures incluent la prévisualisation du geste Retour pour les appareils Android. Pour en savoir plus sur cette fonctionnalité, consultez Ajouter la prise en charge de la prévisualisation du geste Retour.

Implémenter un retour arrière personnalisé

ComponentActivity, la classe de base pour FragmentActivity et AppCompatActivity, vous permet de contrôler le comportement du bouton "Retour" à l'aide de son OnBackPressedDispatcher, que vous pouvez récupérer en appelant getOnBackPressedDispatcher().

OnBackPressedDispatcher contrôle la façon dont les événements du bouton "Retour" sont envoyés à un ou plusieurs objets OnBackPressedCallback. Le constructeur de OnBackPressedCallback utilise une valeur booléenne pour l'état initial activé. Lorsqu'un rappel est activé, c'est-à-dire que isEnabled() renvoie la valeur true, le dispatcher appelle la méthode handleOnBackPressed() du rappel afin de gérer l'événement du bouton Retour. Vous pouvez modifier l'état d'activation en appelant setEnabled().

Les rappels sont ajoutés à l'aide des méthodes addCallback. Nous vous recommandons d'utiliser la méthode addCallback(), qui accepte un LifecycleOwner. Cela permet de vous assurer que OnBackPressedCallback n'est ajouté que lorsque LifecycleOwner est défini sur Lifecycle.State.STARTED. L'activité supprime également les rappels enregistrés lorsque le LifecycleOwner associé est détruit. Cela permet d'éviter les fuites de mémoire et de pouvoir utiliser LifecycleOwner dans des fragments ou dans d'autres propriétaires de cycle de vie ayant une durée de vie plus courte que l'activité.

Voici un exemple d'implémentation du rappel :

class MyFragment : Fragment() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // This callback is only called when MyFragment is at least started
        val callback = requireActivity().onBackPressedDispatcher.addCallback(this) {
            // Handle the back button event
        }

        // The callback can be enabled or disabled here or in the lambda
    }
    ...
}

public class MyFragment extends Fragment {

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // This callback is only called when MyFragment is at least started
        OnBackPressedCallback callback = new OnBackPressedCallback(true /* enabled by default */) {
            @Override
            public void handleOnBackPressed() {
                // Handle the back button event
            }
        };
        requireActivity().getOnBackPressedDispatcher().addCallback(this, callback);

        // The callback can be enabled or disabled here or in handleOnBackPressed()
    }
    ...
}

Vous pouvez fournir plusieurs rappels à l'aide de addCallback(). Dans ce cas, les rappels sont appelés dans l'ordre inverse dans lequel vous les avez ajoutés. Le rappel ajouté en dernier est le premier à avoir la possibilité de gérer l'événement du bouton "Retour". Par exemple, si vous ajoutez trois rappels nommés one, two et three, dans cet ordre, ils sont invoqués dans l'ordre three, two et one.

Les rappels suivent le schéma de chaîne de responsabilité. Chaque rappel de la chaîne n'est invoqué que si le rappel précédent n'a pas été activé. Dans l'exemple précédent, cela signifie que le rappel two est invoqué uniquement si three n'est pas activé, et le rappel one est uniquement invoqué si two n'est pas activé.

Notez que lorsqu'un rappel est ajouté à l'aide de addCallback(), il n'est pas ajouté à la chaîne de responsabilité tant que LifecycleOwner ne passe pas à l'état Lifecycle.State.STARTED.

Nous vous recommandons de modifier l'état d'activation de OnBackPressedCallback pour les modifications temporaires, car cela permet de conserver l'ordre décrit ci-dessus. Ce point est particulièrement important si vous avez enregistré des rappels pour plusieurs propriétaires de cycle de vie imbriqués.

Si vous souhaitez supprimer entièrement OnBackPressedCallback, vous pouvez appeler remove(). Ce n'est généralement pas nécessaire, car les rappels sont automatiquement supprimés lorsque leur LifecycleOwner associé est détruit.

Activité onBackPressed()

Si vous utilisez onBackPressed() pour gérer les événements du bouton "Retour", nous vous recommandons d'utiliser plutôt OnBackPressedCallback. Toutefois, si vous ne parvenez pas à effectuer cette modification, les règles suivantes s'appliquent :

• Tous les rappels enregistrés via addCallback sont évalués lorsque vous appelez super.onBackPressed().
• Dans Android 12 (niveau d'API 32) et versions antérieures, onBackPressed est toujours appelé, quelles que soient les instances enregistrées de OnBackPressedCallback.