Back Press Handling in Android: essenza, meccanismi e implementazione

Cos'è Back Press Handling

Back Press Handling è un meccanismo di sistema in Android che determina cosa succede quando l'utente preme il pulsante Indietro hardware o software. A seconda del contesto, la pressione può: chiudere lo schermo corrente e tornare a quello precedente, nascondere la tastiera, chiudere un Drawer o Bottom Sheet, uscire dall'app se l'utente si trova sullo schermo principale.

Il comportamento del pulsante Indietro si è evoluto con ogni versione di Android. Android 10 ha introdotto la navigazione gestuale, Android 11 ha presentato OnBackPressedDispatcher come API standard, e Android 13 ha portato il supporto migliorato per predictive back gesture, dove il sistema mostra un'animazione di transizione prima che l'azione venga effettivamente eseguita. Google si muove costantemente verso un comportamento prevedibile e coerente del Back Press su tutti i dispositivi.

La corretta gestione del pulsante Indietro è un elemento UX critico in un'app Android. L'utente si aspetta che premendo Indietro si ritorni allo schermo precedente nello stack di navigazione, non che l'app si chiuda inaspettatamente. Violare questa aspettativa è una delle principali cause di recensioni negative e valutazioni basse su Google Play.

Evoluzione di Back Press API: da onBackPressed a OnBackPressedDispatcher

La storia dell'API Back Press in Android riflette l'evoluzione generale della piattaforma: da un semplice metodo in Activity a un sistema flessibile di callback con supporto del ciclo di vita e Compose. Esaminiamo tre fasi di sviluppo.

L'era di onBackPressed (API Level 1–30)

Fin dalla prima API Android, il pulsante Indietro veniva gestito nel metodo onBackPressed della classe Activity. Lo sviluppatore sovrascriveva questo metodo e scriveva la propria logica. Il problema era che Fragment e View non potevano intercettare la pressione — tutto il controllo passava attraverso l'Activity. Questo portava ad Activity gonfiate e a complesse catene if-else per determinare chi dovesse gestire la pressione.

L'arrivo di OnBackPressedDispatcher (Activity 1.0.0)

Con Activity 1.0.0 (AndroidX), Google ha introdotto OnBackPressedDispatcher. Questo è un dispatcher centrale che accetta callback da qualsiasi componente — Activity, Fragment, Dialog, View personalizzata. I callback vengono registrati con un ordine (tramite priority) e possono essere aggiunti o rimossi dinamicamente. OnBackPressedDispatcher viene invocato prima del vecchio onBackPressed, permettendo di intercettare la pressione prima che l'Activity la gestisca.

Predictive Back Gesture (Android 13+)

Android 13 ha introdotto il predictive back gesture — un'animazione di sistema che mostra dove porterà la pressione di Indietro prima che l'utente completi il gesto. Per supportare questa animazione, gli sviluppatori devono utilizzare OnBackPressedDispatcher e indicare se il callback supporta l'animazione di sistema tramite la proprietà isEnabled. Se il callback non supporta l'animazione predittiva, il sistema mostra un'animazione predefinita che potrebbe non corrispondere al contesto dell'app.

OnBackPressedDispatcher — Architettura e catena di callback

OnBackPressedDispatcher è il cuore della nuova API Back Press. Gestisce una catena di callback, invocandoli in ordine fino a quando il primo gestisce l'evento. Se nessun callback gestisce la pressione, il dispatcher esegue l'azione predefinita — chiamare finish() per un'Activity o popBackStack() per il Navigation Component.

Registrazione di callback con priorità

Un callback viene registrato tramite addCallback con un LifecycleOwner e un oggetto OnBackPressedCallback. Il callback ha una proprietà isEnabled — se impostata su false, il callback viene saltato. Per la priorità, è possibile passare un valore da 0 (più bassa) a Integer.MAX_VALUE. L'API Fragment Activity Result utilizza questo meccanismo per la registrazione automatica di callback legati al ciclo di vita.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val callback = object : OnBackPressedCallback(enabled = true) {
        override fun handleOnBackPressed() {
            if (isDrawerOpen) { closeDrawer() }
            else { isEnabled = false; onBackPressed() }
        }
    }
    onBackPressedDispatcher.addCallback(this, callback)
}

Pulizia Lifecycle-aware

I callback vengono rimossi automaticamente quando il LifecycleOwner passa allo stato DESTROYED. Questo risolve il vecchio problema di perdite di callback durante la rotazione dello schermo. Se un callback viene aggiunto in un Fragment, è garantito che venga rimosso quando il Fragment viene distrutto. Per disabilitare temporaneamente un callback, utilizzare la proprietà isEnabled — è possibile commutarla senza rimozione e ri-registrazione.

Catena di invocazione

L'ordine di chiamata è l'inverso dell'ordine di aggiunta: l'ultimo callback aggiunto riceve il controllo per primo. Questo è logico perché l'elemento UI più annidato (ad esempio, un Bottom Sheet all'interno di un Fragment) dovrebbe gestire la pressione prima del suo Fragment padre. Se il callback più profondo non gestisce la pressione (isEnabled = false), il controllo passa al successivo nella catena.

Back Press in Fragment e finestre di dialogo

L'API Fragment fornisce la propria integrazione con OnBackPressedDispatcher tramite il metodo requireActivity().onBackPressedDispatcher. A partire da Fragment 1.2.0, ogni Fragment può registrare il proprio callback, che viene automaticamente legato al ciclo di vita del Fragment e rimosso quando viene distrutto.

Callback in Fragment

La registrazione di un callback in un Fragment viene effettuata in onCreate, onViewCreated o anche nella View stessa — l'importante è che il LifecycleOwner (Fragment) sia attivo. Quando il Fragment passa allo stato STARTED, il callback viene abilitato; quando è STOPPED, viene disabilitato. Questo garantisce che un Fragment nascosto (in ViewPager) non gestirà la pressione di Indietro.

class EditorFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val callback = object : OnBackPressedCallback(true) {
            override fun handleOnBackPressed() {
                showDiscardDialog()
            }
        }
        requireActivity().onBackPressedDispatcher.addCallback(this, callback)
    }
}

Dialog e BottomSheetDialog

Dialoghi e BottomSheet intercettano automaticamente la pressione di Indietro per chiudersi. Se è necessario eseguire un'azione aggiuntiva prima della chiusura — registrare un callback con priorità più alta. Importante: se si imposta setCancelable(false) su un Dialog, il callback non si attiverà — questo è comportamento di sistema.

Back Press Handling in Jetpack Compose

Jetpack Compose fornisce un'API dichiarativa per gestire il pulsante Indietro tramite la funzione composable BackHandler. BackHandler accetta enabled (stato booleano) e onBack — un callback invocato alla pressione. Se enabled = false, la pressione viene passata più avanti nella catena.

BackHandler in Compose

BackHandler registra automaticamente un OnBackPressedCallback nell'OnBackPressedDispatcher dell'Activity padre. Rispetta il ciclo di vita del composable: quando si esce dalla composizione, il callback viene rimosso. enabled può essere legato allo stato — ad esempio, mostrare un dialogo di conferma solo se il modulo contiene modifiche non salvate.

@Composable
fun EditScreen(hasUnsavedChanges: Boolean) {
    BackHandler(enabled = hasUnsavedChanges) {
        // Show confirmation dialog
    }

    Column {
        TextField(value = ..., onValueChange = ...)
    }
}

Predictive Back in Compose

Il predictive back gesture in Compose è supportato a partire da Compose 1.5.0. BackHandler gestisce automaticamente l'animazione di transizione di sistema se abilitata sul dispositivo. Per animazioni predittive personalizzate, utilizzare il modificatore predictiveBackHandler, che restituisce il progresso del gesto da 0 a 1.

Errori comuni e buone pratiche

Back Press Handling sembra semplice, ma nella pratica gli sviluppatori commettono una serie di errori sistematici. Esaminiamo i problemi più comuni e le loro soluzioni basate sulle raccomandazioni di Google e sull'esperienza della comunità.

Errore: chiamare finish() senza controllare lo stack di navigazione

La chiamata diretta di finish() in handleOnBackPressed può portare a un'uscita imprevista dall'app se ci sono schermi in background nello stack di navigazione. Controllare sempre NavController.backStack tramite Navigation Component o Coordinator prima di chiudere l'Activity.

Errore: ignorare il ciclo di vita durante la registrazione dei callback

Se si registra un callback senza LifecycleOwner (usando il vecchio addCallback senza parametro), il callback vivrà per sempre e potrebbe causare una NullPointerException se l'Activity è già stata distrutta. Utilizzare sempre addCallback(this, callback) con un LifecycleOwner.

Buona pratica: interrompere la catena per finestre modali

Per finestre modali (Bottom Sheet, Dialog), impostare sempre isEnabled = true solo quando la finestra è visibile. Utilizzare addCallback con una lambda che controlla lo stato della finestra. Il Navigation Component gestisce automaticamente questo per NavHost.

Buona pratica: gestione della doppia pressione

Una rapida doppia pressione di Indietro può portare a una doppia chiamata di finish(). Utilizzare un flag o throttleLast per proteggersi da chiamate ripetute entro 500 ms. Il Navigation Component gestisce questa situazione nativamente, ma in scenari personalizzati è necessario implementare la protezione manualmente.

private var lastBackPressTime = 0L

override fun handleOnBackPressed() {
    val currentTime = System.currentTimeMillis()
    if (currentTime - lastBackPressTime > 500) {
        lastBackPressTime = currentTime
        navigateBack()
    }
}