Editorial illustration.
Originally published 26 June 2023; rewritten and reviewed on 15 October 2026.
A confirmation dialog looks simple until the user rotates the device, taps the button twice or leaves the screen while it is open. The visible box is only one part of the interaction. Its owner and its result need to be clear as well.
Start with the decision being requested
Give the dialog a specific purpose: confirm deletion, choose an option or enter a small amount of information. Explain the consequence and use action labels that describe it. A generic “Yes” is harder to interpret when the user returns after an interruption.
For ordinary confirmations, a platform-appropriate alert dialog may be enough. For lifecycle-aware fragment applications, use the supported DialogFragment pattern rather than holding a long-lived Activity reference in a helper. Check the Android dialog guidance for the libraries your application uses.
Keep the result separate from the layout
The original example inflated a custom XML layout into a Dialog. That remains useful for understanding the view, but the surrounding application needs to own the selected action. Pass a result back through the application’s fragment or state-management mechanism instead of having the dialog modify unrelated screens directly.
Prevent duplicate openings and duplicate submissions. A positive-button tap should not cause the same operation to run twice if the UI takes a moment to respond.
Check dismissal and accessibility
Decide what Back, outside taps and cancellation mean. Preserve entered information where the workflow requires it, and do not display success until the operation has actually completed.
Test large text, keyboard navigation where applicable, screen-reader labels and rotation. A small modal can become difficult to use if the keyboard obscures its only action.
My preference is to keep dialogs short and decisions explicit. Longer editing tasks often work better on a dedicated screen where progress and recovery have room to be explained.