What the interviewer is testing

The interviewer is checking whether you understand the difference between carrying state and owning or persisting state.

A strong answer explains where Bundles appear, why they should remain small, and why passing an ID is usually safer than packing an entire object graph into one.

❌ Common mistake

If they ask you to elaborate

Why Android invented Bundle

Imagine you open an order details screen.

The next screen only needs one value:

orderId = 42

Now rotate the device. Android destroys and recreates the screen, but the new screen still needs to know which order was open.

The same problem appears when Android launches another Activity, creates a Fragment, navigates between destinations, or restores UI state.

Rather than inventing a different transport mechanism for every API, Android uses the same small container everywhere: Bundle.

Small pieces of state
          │
          ▼
        Bundle
          │
          ├── Intent extras
          ├── Fragment arguments
          ├── Navigation arguments
          └── Saved instance state

The important mental model is simple: Bundle is for carrying, not storing. Android standardized on one transport container instead of inventing a different one for every API.

A senior engineer usually passes the smallest stable identifier possible. Instead of putting an entire Order into a Bundle, pass orderId and let the destination load the current order from its repository.

That avoids stale copies, keeps component boundaries clear, and makes recreation easier.

Production consideration

Bundles travel through Android's Binder transaction system, which is designed for small payloads.

In practice, keep Bundles small, prefer IDs over complete objects, and reload durable data from its source whenever possible.

Although Bundles support primitives, strings, nested Bundles, and Parcelable objects, treat that as a transport capability—not a reason to pass entire object graphs.

Code example

private const val ARG_ORDER_ID = "order_id"

class OrderDetailsFragment : Fragment(R.layout.fragment_order_details) {

    private val orderId: Long by lazy {
        requireArguments().getLong(ARG_ORDER_ID)
    }

    companion object {
        fun newInstance(orderId: Long) = OrderDetailsFragment().apply {
            arguments = bundleOf(ARG_ORDER_ID to orderId)
        }
    }
}

The Bundle transports only the stable identifier (orderId). The Fragment (or ViewModel) loads the actual Order from the repository.

This keeps screens independent, avoids stale serialized objects, and makes recreation straightforward. The same principle applies to Intent extras, navigation arguments, and saved state.

Follow-up questions

What separates a senior answer

Key takeaways

Learn more