Introduction

The modern Android answer for receiving a result from a DialogFragment is usually the Fragment Result API. It lets the dialog publish a one-time Bundle result through the FragmentManager, and the host fragment or activity listens for that result without needing a brittle direct reference or custom cast-heavy listener interface.

The Recommended Pattern: Fragment Result API

If the dialog is returning a small one-time result, set a listener in the receiving fragment before showing the dialog.

Receiver fragment in Kotlin:

1class HostFragment : Fragment(R.layout.fragment_host) {
2
3    override fun onCreate(savedInstanceState: Bundle?) {
4        super.onCreate(savedInstanceState)
5
6        parentFragmentManager.setFragmentResultListener("confirm_request", this) { _, bundle ->
7            val accepted = bundle.getBoolean("accepted")
8            val note = bundle.getString("note").orEmpty()
9            println("accepted=$accepted note=$note")
10        }
11    }
12
13    fun showDialog() {
14        ConfirmDialogFragment().show(parentFragmentManager, "confirm_dialog")
15    }
16}

The dialog sends the result:

1class ConfirmDialogFragment : DialogFragment() {
2
3    override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {
4        return AlertDialog.Builder(requireContext())
5            .setTitle("Delete item?")
6            .setMessage("This action cannot be undone.")
7            .setPositiveButton("Delete") { _, _ ->
8                parentFragmentManager.setFragmentResult(
9                    "confirm_request",
10                    bundleOf(
11                        "accepted" to true,
12                        "note" to "User confirmed deletion"
13                    )
14                )
15            }
16            .setNegativeButton("Cancel") { _, _ ->
17                parentFragmentManager.setFragmentResult(
18                    "confirm_request",
19                    bundleOf("accepted" to false)
20                )
21            }
22            .create()
23    }
24}

This keeps the dialog and host loosely coupled and works well for one-shot responses.

Why This Is Better Than the Old Listener Pattern

Older Android code often used an interface like:

• dialog defines OnResultListener
• activity or fragment implements it
• dialog casts the host and calls back directly

That works, but it has weaknesses:

• more boilerplate
• runtime cast failures
• tighter coupling between dialog and host
• more awkward lifecycle behavior during recreation

The Fragment Result API removes most of that friction for ordinary dialog results.

Activity Hosts Can Use the Same Idea

If the dialog is hosted directly by an activity, register the listener on the activity’s supportFragmentManager instead of a fragment manager owned by another fragment.

The principle is the same:

• listener registered on the relevant FragmentManager
• dialog sets the result on that same manager

The key is that both sides use the same result key and the same manager scope.

Use a Shared ViewModel for Ongoing Shared State

If the dialog is part of a longer-lived interaction rather than a one-time response, a shared ViewModel may be a better fit. The Fragment Result API is ideal when the result is:

• small
• one-time
• naturally representable in a Bundle

If you need stream-like updates or more complex shared state, a shared ViewModel is usually cleaner.

Be Careful About the Right Fragment Manager

One of the easiest mistakes is mixing up:

• 'parentFragmentManager'
• 'childFragmentManager'

If the host listens on one manager and the dialog posts the result on another, nothing happens and the code looks mysteriously correct.

A useful rule is:

• show the dialog with a manager
• listen for the result on that same manager

That keeps the communication path consistent.

Java Example

The same pattern works in Java:

1getParentFragmentManager().setFragmentResultListener(
2    "confirm_request",
3    this,
4    (requestKey, bundle) -> {
5        boolean accepted = bundle.getBoolean("accepted");
6        String note = bundle.getString("note", "");
7        System.out.println(accepted + " " + note);
8    }
9);

And from the dialog:

1Bundle result = new Bundle();
2result.putBoolean("accepted", true);
3result.putString("note", "confirmed");
4getParentFragmentManager().setFragmentResult("confirm_request", result);

So the idea is not Kotlin-specific. It is a Fragment API pattern.

Common Pitfalls

• Using different result keys between the sender and receiver.
• Posting the result on a different FragmentManager than the one the listener is watching.
• Reaching for a custom listener interface when the result is just a simple one-time Bundle.
• Trying to pass large or complex objects that do not belong in a fragment result bundle.
• Forgetting to register the result listener before the dialog result is sent.

Summary

• For modern Android apps, the Fragment Result API is usually the best way to receive a result from a DialogFragment.
• Register a listener on the correct FragmentManager, then have the dialog call setFragmentResult.
• Use the same result key and the same manager on both sides.
• Prefer this over older listener interfaces for simple one-time dialog responses.
• Use a shared ViewModel instead when the communication is ongoing or more stateful than a single result.