Benutzerdefinierte Zurück-Navigation bereitstellen

Nutzer navigieren mit der Rückwärtsnavigation auf den vorherigen Bildschirm. Die meisten Android-Geräte haben eine Zurück-Taste (physisch, softwarebasiert oder gestengesteuert). Normalerweise sollten Sie Ihrer App keinen Button „Zurück“ hinzufügen. Auf Android Automotive OS-Geräten (AAOS) im Kompatibilitätsmodus wird jedoch ein Button „Zurück“ des Systems verwendet. Diese übernimmt die Navigation, sodass Sie keine eigene hinzufügen müssen. Weitere Informationen finden Sie unter AAOS-Kompatibilitätsmodus.

Android führt einen Back-Stack mit Zielen, während der Nutzer in Ihrer App navigiert. So kann Android in der Regel richtig zu vorherigen Zielen navigieren, wenn der Button „Zurück“ gedrückt wird. Es gibt jedoch einige Fälle, in denen Ihre App ein eigenes Zurück-Verhalten implementieren muss, um die bestmögliche Nutzererfahrung zu bieten. Wenn Sie beispielsweise ein WebView verwenden, möchten Sie möglicherweise das Standardverhalten der Zurück-Taste überschreiben, damit der Nutzer stattdessen durch den Browserverlauf und nicht durch die vorherigen Bildschirme in Ihrer App navigieren kann.

Benutzerdefinierte Zurück-Navigation in Compose implementieren

In Jetpack Compose können Sie die benutzerdefinierte Rückwärtsnavigation mit der BackHandler zusammensetzbaren Funktion verarbeiten.

Wenn Sie Navigation Compose verwenden, verwenden Sie in der Regel NavController.navigateUp() oder NavController.popBackStack() , um zum vorherigen Bildschirm im Back-Stack zu navigieren. BackHandler ist jedoch nützlich, wenn Sie ein benutzerdefiniertes Verhalten implementieren möchten, wenn der Nutzer den Button „Zurück“ des Systems drückt oder die Zurück-Geste verwendet. Wenn Sie beispielsweise ein WebView in Ihrer App anzeigen, möchten Sie möglicherweise, dass Nutzer durch den Browserverlauf zurücknavigieren können, wenn sie den Button „Zurück“ des Systems drücken.

Grundlegende Nutzung

Hier sehen Sie ein Beispiel, wie Sie das Zurück-Ereignis abfangen können, um den benutzerdefinierten Status zu steuern (z. B. das Minimieren eines Panels):

@Composable
fun MyScreen() {
    var isExpanded by remember { mutableStateOf(false) }

    // Intercept the back button or gesture only when isExpanded is true
    BackHandler(enabled = isExpanded) {
        // Collapsing the content disables this handler, so it does not
        // receive the next back event.
        isExpanded = false
    }

    if (isExpanded) {
        Text("Expanded content. Go back to collapse it.")
    } else {
        Button(onClick = { isExpanded = true }) {
            Text("Expand")
        }
    }
}
CustomBack.kt

Abfangen des zusammensetzbaren Baums

Wenn Sie mehrere aktivierte BackHandler-Komposables auf verschiedenen Ebenen Ihres zusammensetzbaren Baums haben, fängt nur das innerste das Zurück-Ereignis ab.

Benutzerdefinierte Zurück-Navigation mit Ansichten implementieren

ComponentActivity, die Basisklasse für FragmentActivity und AppCompatActivity, ermöglicht Ihnen die Steuerung des Verhaltens des Buttons „Zurück“ mithilfe des zugehörigen OnBackPressedDispatcher, den Sie durch Aufrufen von getOnBackPressedDispatcher() abrufen können.

Der OnBackPressedDispatcher steuert, wie Ereignisse der Zurück-Taste gesendet werden an ein oder mehrere OnBackPressedCallback-Objekte. Der Konstruktor für OnBackPressedCallback verwendet einen booleschen Wert für den anfänglichen aktivierten Status. Nur wenn ein Callback aktiviert ist, z. B. wenn isEnabled() true zurückgibt, ruft der Dispatcher handleOnBackPressed() des Callbacks auf, um das Ereignis der Zurück-Taste zu verarbeiten. Sie können den aktivierten Status mit setEnabled() ändern.

Callbacks werden mit den Methoden addCallback hinzugefügt. Verwenden Sie die addCallback() Methode, die ein LifecycleOwner verwendet. So wird das OnBackPressedCallback nur hinzugefügt, wenn das LifecycleOwner ist Lifecycle.State.STARTED. Die Aktivität entfernt auch registrierte Callbacks, wenn der zugehörige LifecycleOwner zerstört wird. So werden Speicherlecks verhindert und die Verwendung in Fragmenten oder anderen LifecycleOwnern mit einer kürzeren Lebensdauer als die Aktivität ermöglicht.

Hier sehen Sie ein Beispiel für die Implementierung eines Callbacks:

class MyFragment : Fragment() {

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

        // This callback will only be 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
    }
    ...
}

Sie können mit addCallback() mehrere Callbacks angeben. In diesem Fall werden die Callbacks in umgekehrter Reihenfolge aufgerufen, in der sie hinzugefügt wurden. Der zuletzt hinzugefügte Callback hat als Erster die Möglichkeit, das Ereignis der Zurück-Taste zu verarbeiten. Wenn Sie beispielsweise drei Callbacks mit den Namen one, two und three in dieser Reihenfolge hinzugefügt haben, werden sie in der Reihenfolge three, two und one aufgerufen.

Callbacks folgen dem Muster der Verantwortungskette. Jeder Callback in der Kette wird nur aufgerufen, wenn der vorherige Callback nicht aktiviert wurde. Im vorherigen Beispiel wird der Callback two also nur aufgerufen, wenn der Callback three nicht aktiviert wurde. Der Callback one wird nur aufgerufen, wenn der Callback two nicht aktiviert wurde. Dieses Muster wird für alle zusätzlichen Callbacks fortgesetzt.

Wenn der Callback mit addCallback() hinzugefügt wird, wird er erst dann der Verantwortungskette hinzugefügt, wenn der LifecycleOwner den Status Lifecycle.State.STARTED erreicht.

Es wird dringend empfohlen, den aktivierten Status des Callbacks für vorübergehende Änderungen zu ändern, da so die zuvor beschriebene Reihenfolge beibehalten wird. Das ist besonders wichtig, wenn Callbacks für mehrere verschiedene verschachtelte LifecycleOwner registriert sind.

Wenn Sie den Callback vollständig entfernen möchten, rufen Sie remove() auf. Das ist in der Regel nicht erforderlich, da Callbacks automatisch entfernt werden, wenn der zugehörige LifecycleOwner zerstört wird.