Skip to content

SYSTEM Cited by 1 source

Android Fragment

Overview

An Android Fragment is a modular, reusable portion of a user interface within an Android Activity. Fragments were introduced in Android 3.0 (Honeycomb, 2011) to support tablet multi-pane layouts and became the dominant UI composition unit for Android apps built between ~2012 and the ~2024 pivot to Jetpack Compose.

A Fragment has:

  • Its own lifecycle (onCreate, onCreateView, onViewCreated, onDestroyView, onDestroy).
  • An XML layout inflated at onCreateView.
  • Back-stack integration via FragmentManager + FragmentTransaction.
  • Navigation integration via the AndroidX Navigation component — historically with XML nav graphs using resource-ID destinations (R.id.checkout_fragment).

Interop with Compose

Fragments and Composables coexist during a migration:

  • ComposeView — a View that hosts a Composable tree inside a Fragment's XML layout.
  • BaseComposeFragment-style wrapper — a Fragment subclass whose onCreateView returns a ComposeView rendering the Composable (the pattern the [[sources/2026-02-03-instacart-migrating-to-jetpack-compose|2026-02-03 Instacart post]] starts from).
  • navigation-fragment-compose — Google's library that registers a Composable as a Fragment-nav destination without requiring a dedicated wrapper class (the Phase-1 enabler in the Caper migration).

Why teams migrate away

  • Google's recommendation is Compose-first for new code.
  • Compose-native libraries, samples, and tooling dominate the modern Android ecosystem.
  • The Fragment lifecycle is notoriously error-prone ("nested Fragment state loss" is a recurring bug class).
  • XML layouts + findViewById + View-binding have been superseded by declarative state-driven rendering.
  • Teams staying on Fragments accumulate tech debt as the wider ecosystem moves on.

Seen in

  • sources/2026-02-03-instacart-migrating-to-jetpack-compose — canonical wiki instance. The Caper smart-cart Android app built on "Fragments and XML layouts" migrated in a deliberate four-phase plan: Phase 1 replaces explicit Fragment wrappers with Google's navigation-fragment-compose implicit hosts while keeping Fragment-based navigation; Phase 2 migrates the XML nav graphs + resource IDs to a type-safe Kotlin DSL while still Fragment-based (30+ sub-graphs, 130+ destinations); Phase 3 converts 100+ remaining Fragment features to pure Compose using a 17-step AI-skill workflow with Paparazzi visual- parity checkpoints; Phase 4 replaces Fragment-based navigation with Compose Navigation. Each phase decommissions one axis of Fragment-coupling independently.
Last updated · 319 distilled / 1,201 read