Back Press Handling sa Android: esensya, mekanismo, at implementasyon

Ano ang Back Press Handling

Back Press Handling — ay ang system mechanism ng Android na tumutukoy kung ano ang mangyayari kapag pinindot ng user ang hardware o software “Bumalik” na button. Depende sa konteksto, ang pagpindot ay maaaring: isara ang kasalukuyang screen at bumalik sa nauna, itago ang keyboard, isara ang Drawer o Bottom Sheet, lumabas sa application kung ang user ay nasa root screen.

Ang pag-uugali ng “Bumalik” na button ay umunlad sa bawat bersyon ng Android. Sa Android 10 lumitaw ang navigation gestures, sa Android 11 — OnBackPressedDispatcher bilang standard API, at sa Android 13 — pinahusay na suporta para sa predictive back gesture, kung saan ipinapakita ng system ang isang transition animation bago ang aktwal na pagpapatupad ng aksyon. Patuloy na gumagalaw ang Google patungo sa predictable at consistent na pag-uugali ng Back Press sa lahat ng device.

Ang tamang pagproseso ng “Bumalik” na button — kritikal na elemento ng UX sa Android application. Inaasahan ng user na ang pagpindot ng “Bumalik” ay magbabalik sa kanya sa nakaraang screen sa navigation stack, hindi isasara ang application nang biglaan. Ang paglabag sa inaasahan na ito ay isa sa mga pangunahing dahilan ng negatibong review at mababang rating sa Google Play.

Ebolusyon ng Back Press API: mula onBackPressed hanggang OnBackPressedDispatcher

Ang kasaysayan ng Back Press API sa Android ay sumasalamin sa pangkalahatang ebolusyon ng platform: mula sa isang simpleng paraan sa Activity hanggang sa isang flexible na callback system na may suporta sa lifecycle at Compose. Tingnan natin ang tatlong yugto ng pag-unlad.

Panahon ng onBackPressed (API Level 1–30)

Mula sa pinakaunang Android API, ang “Bumalik” na button ay pinoproseso sa paraan ng onBackPressed ng klase ng Activity. Ang developer ay nag-ooverride ng paraang ito at sumulat ng sarili niyang lohika. Ang problema ay hindi ma-intercept ng Fragment at View ang press — lahat ng control ay sa pamamagitan ng Activity. Ito ay humantong sa mga namamagang Activity at kumplikadong if-else chain para matukoy kung sino ang dapat mag-proseso ng press.

Paglitaw ng OnBackPressedDispatcher (Activity 1.0.0)

Sa Activity 1.0.0 (AndroidX) ipinakilala ng Google ang OnBackPressedDispatcher. Ito ay isang central dispatcher na tumatanggap ng callback mula sa anumang component — Activity, Fragment, Dialog, custom View. Ang mga callback ay nirerehistro na may pagtukoy ng pagkakasunud-sunod (sa pamamagitan ng priority) at maaaring idagdag o tanggalin nang dynamic. Ang OnBackPressedDispatcher ay tinatawag nang mas maaga kaysa sa lumang onBackPressed, na nagpapahintulot sa pag-intercept ng press bago ito iproseso ng Activity.

Predictive Back Gesture (Android 13+)

Android 13 ay nagpakilala ng predictive back gesture — isang system animation na nagpapakita kung saan patungo ang “Bumalik” na press, bago pa matapos ng user ang gesture. Para suportahan ang animation na ito, dapat gamitin ng mga developer ang OnBackPressedDispatcher at ipahiwatig kung sinusuportahan ng callback ang system animation sa pamamagitan ng property na isEnabled. Kung hindi sinusuportahan ng callback ang predictive animation, magpapakita ang system ng default na animation na maaaring hindi tumutugma sa konteksto ng application.

OnBackPressedDispatcher — arkitektura at chain ng callback

OnBackPressedDispatcher — ay ang core ng bagong Back Press API. Pinamamahalaan nito ang chain ng callback, tinatawag ang mga ito sa pagkakasunud-sunod hanggang sa unang mag-proseso ng event. Kung walang callback na nag-proseso ng press, ang dispatcher ay magsasagawa ng default na aksyon — pagtawag ng finish() para sa Activity o popBackStack() para sa Navigation Component.

Pagrehistro ng callback na may priyoridad

Ang callback ay nirerehistro sa pamamagitan ng addCallback na may pagtukoy ng LifecycleOwner at object ng OnBackPressedCallback. Ang callback ay naglalaman ng property na isEnabled — kung nakatakda sa false, nilalaktawan ang callback. Para sa priority ay maaaring magpasa ng halaga mula 0 (pinakamababa) hanggang Integer.MAX_VALUE. Ginagamit ng Fragment Activity Result API ang mekanismong ito para sa awtomatikong pagrehistro ng callback na nakatali sa lifecycle.

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)
}

Lifecycle-aware na paglilinis

Ang callback ay awtomatikong tinatanggal kapag ang LifecycleOwner ay lumipat sa estado DESTROYED. Nalulutas nito ang lumang problema ng pagtagas ng callback sa pag-ikot ng screen. Kung ang callback ay idinagdag sa Fragment, garantisadong tatanggalin ito kapag nawasak ang Fragment. Para sa pansamantalang pag-disable ng callback, gamitin ang property na isEnabled — maaaring ilipat nang hindi tinatanggal at muling nirerehistro.

Chain ng pagtawag

Ang pagkakasunud-sunod ng pagtawag ay kabaligtaran ng pagkakasunud-sunod ng pagdaragdag: ang pinakahuling idinagdag na callback ay unang nakakakuha ng kontrol. Ito ay lohikal dahil ang pinakaloob na UI element (halimbawa, Bottom Sheet sa loob ng Fragment) ay dapat mag-proseso ng press nang mas maaga kaysa sa parent Fragment. Kung ang pinakamalalim na callback ay hindi nag-proseso ng press (isEnabled = false), ang kontrol ay ililipat sa susunod sa chain.

Back Press sa Fragment at mga dialog

Fragment API ay nagbibigay ng sariling integration sa OnBackPressedDispatcher sa pamamagitan ng paraan na requireActivity().onBackPressedDispatcher. Simula sa Fragment 1.2.0, bawat Fragment ay maaaring magrehistro ng sarili nitong callback na awtomatikong nakatali sa lifecycle ng Fragment at tinatanggal kapag nawasak ito.

Callback sa Fragment

Pagrehistro ng callback sa Fragment ay ginagawa sa onCreate, onViewCreated, o kahit sa View mismo — mahalaga lang na ang LifecycleOwner (Fragment) ay aktibo. Kapag ang Fragment ay lumipat sa estado STARTED, ang callback ay i-activate, sa STOPPED — deactivate. Ito ay ginagarantiyahan na ang nakatagong Fragment (sa ViewPager) ay hindi mag-proseso ng “Bumalik” na press.

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 at BottomSheetDialog

Mga dialog at BottomSheet ay awtomatikong nag-iintercept ng “Bumalik” na press para isara. Kung kailangan mong magsagawa ng karagdagang aksyon bago isara — magrehistro ng callback na may mas mataas na priyoridad. Mahalaga: kung nagtakda ka ng setCancelable(false) sa Dialog, hindi gagana ang callback — ito ay system behavior.

Back Press Handling sa Jetpack Compose

Jetpack Compose ay nagbibigay ng declarative API para sa pagproseso ng “Bumalik” na button sa pamamagitan ng composable function na BackHandler. Ang BackHandler ay tumatanggap ng enabled (boolean value) at onBack — callback na tinatawag kapag pinindot. Kung enabled = false, ang press ay ipapasa pa sa chain.

BackHandler sa Compose

BackHandler ay awtomatikong nagrerehistro ng OnBackPressedCallback sa OnBackPressedDispatcher ng parent Activity. Isinasaalang-alang nito ang lifecycle ng composable: kapag lumabas sa composition, ang callback ay tinatanggal. Ang enabled ay maaaring iugnay sa estado — halimbawa, magpakita ng confirmation dialog lang kung may mga hindi nai-save na pagbabago sa form.

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

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

Predictive Back sa Compose

Predictive back gesture sa Compose ay sinusuportahan simula sa Compose 1.5.0. Awtomatikong pinangangasiwaan ng BackHandler ang system transition animation kung ito ay naka-enable sa device. Para sa custom na predictive animation, gamitin ang modifier na predictiveBackHandler, na nagbabalik ng progreso ng gesture mula 0 hanggang 1.

Mga karaniwang pagkakamali at best practices

Back Press Handling ay tila simple, ngunit sa praktika ang mga developer ay gumagawa ng isang serye ng mga sistematikong pagkakamali. Tingnan natin ang mga pinakakaraniwang problema at paraan ng paglutas batay sa mga rekomendasyon ng Google at karanasan ng komunidad.

Pagkakamali: pagtawag ng finish() nang hindi sinusuri ang navigation stack

Direktang pagtawag ng finish() sa handleOnBackPressed ay maaaring humantong sa hindi inaasahang paglabas mula sa application kung may mga background screen sa navigation stack. Palaging suriin ang NavController.backStack sa pamamagitan ng Navigation Component o Coordinator bago isara ang Activity.

Pagkakamali: pagbalewala sa lifecycle kapag nagrerehistro ng callback

Kung magrerehistro ka ng callback nang walang LifecycleOwner (gamit ang lumang addCallback na walang parameter), ang callback ay mabubuhay magpakailanman at maaaring magdulot ng NullPointerException kung ang Activity ay nawasak na. Palaging gamitin ang addCallback(this, callback) na may LifecycleOwner.

Best Practice: pagputol ng chain para sa modal windows

Para sa modal windows (Bottom Sheet, Dialog) palaging itakda ang isEnabled = true lang kapag nakikita ang window. Gumamit ng addCallback na may lambda na sumusuri sa estado ng window. Awtomatikong pinangangasiwaan ito ng Navigation Component para sa NavHost.

Best Practice: paghawak ng double press

Ang mabilis na double press ng “Bumalik” ay maaaring humantong sa double na pagtawag ng finish(). Gumamit ng flag o throttleLast para sa proteksyon laban sa paulit-ulit na tawag sa loob ng 500 ms. Awtomatikong pinangangasiwaan ng Navigation Component ang sitwasyong ito, ngunit sa custom na mga senaryo kailangan mong implementahin ang proteksyon nang manu-mano.

private var lastBackPressTime = 0L

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