Creating custom dialogs and bottom sheets in Android

Custom dialogs and bottom sheets help Android apps present focused actions without forcing users away from the current screen. A dialog is useful when a decision needs immediate attention, while a bottom sheet feels more natural for menus, filters, sharing options and short forms.

For Australian users, context matters. Someone checking an app while changing trains in Sydney may need a quick, thumb-friendly choice, while a customer browsing on a slower connection in regional Queensland may benefit from a lightweight interface. Good modal design keeps the task clear, accessible and easy to dismiss.

Choosing between a dialog and a bottom sheet

A dialog places a compact surface above the current content, usually in the centre of the screen. It works well for confirmation messages, destructive actions, sign-in prompts and small data-entry tasks. Use it when the user must make a decision before continuing, such as confirming an order or granting permission.

A bottom sheet slides up from the lower edge and preserves more of the surrounding context. It suits an action list, location picker, sort controls or a filter panel. A modal bottom sheet can temporarily block the underlying screen, while a persistent sheet remains available as part of the layout. On a large phone used in Melbourne, a bottom sheet can provide more room than a narrow alert dialog without feeling like a separate page.

Avoid turning every notification into a modal. Interruptions are costly when people are walking through Brisbane’s CBD or checking a delivery status between tasks. If the user can continue safely without responding, use an inline message, snackbar or non-blocking banner instead.

Building a polished custom dialog

In Jetpack Compose, AlertDialog provides a reliable starting point for a custom confirmation or input experience. You can supply a title, text, confirm button and dismiss button, then style the content with your app’s Material theme. For a more flexible layout, use Dialog with a custom surface, rounded corners and controlled width.

A View-based application can use DialogFragment, which handles lifecycle concerns more safely than creating a raw Dialog inside an activity. Inflate a dedicated XML layout, keep button actions inside the fragment, and communicate results through a shared ViewModel or Fragment Result API. This approach helps prevent a dialog from holding onto an obsolete activity after rotation.

A well-designed dialog should explain one thing and offer a clear next step. Keep the title specific, such as “Delete saved address”, rather than “Are you sure?”. Use a short supporting message and make the primary action visually distinct. Destructive buttons should use direct labels like “Delete” instead of vague wording such as “OK”.

Designing flexible bottom sheets

Compose offers ModalBottomSheet for temporary surfaces and BottomSheetScaffold for layouts that keep a sheet attached to the screen. Define the sheet’s content as a separate composable so it can be tested independently. Include a drag handle where appropriate, and let the sheet expand naturally when the content requires additional space.

In the Android Views toolkit, BottomSheetDialog and BottomSheetDialogFragment are suitable for modal sheets. Set the sheet’s behaviour deliberately: decide whether it can be dragged, whether it should start expanded, and what should happen when the user taps outside it. A filter sheet might open at a partial height, while a payment review may need to open fully so the complete summary is visible.

Bottom sheets should support both gestures and explicit controls. Some users will swipe down, but others rely on a close icon or the system back button. Do not hide essential actions below an uncertain drag area. On smaller devices, keep primary buttons visible or make the content scroll while the action area remains easy to reach.

Handling state, focus and accessibility

A modal surface should have one clear source of truth. In Compose, keep visibility in remembered or state-holder data, and update that state when the user confirms or dismisses the surface. With fragments, avoid storing important form values only inside the dialog view; preserve them in a ViewModel if the process or configuration may change.

Focus management is especially important for custom forms. When a dialog opens, move focus to the first meaningful field only when that behaviour is helpful. Show the keyboard after the layout is ready rather than immediately on construction. When the modal closes, return focus to the control that opened it where possible, giving screen-reader users a predictable path.

Use content descriptions for icon-only buttons, sufficient colour contrast and touch targets of at least 48 density-independent pixels. Test TalkBack navigation, font scaling and landscape mode. Australian teams should also consider the Digital Service Standard and WCAG expectations when building public-facing services, including apps used by councils, banks and government departments.

Practical recommendations for production-ready modal UI

A reusable component can apply consistent spacing, typography, corner shapes and button treatment across the app. Centralising these choices makes it easier to support a brand refresh or meet different platform requirements without editing every screen individually.

Before release, test on a compact Android handset, a large phone and a tablet. Check long Australian place names, larger accessibility text, offline states and keyboard overlap. An address such as “Wagga Wagga” or a long business name should not force an action button off-screen.

• Use a dialog for a focused decision and a bottom sheet for a set of related options.
• Give every modal an obvious dismissal path, including the back button.
• Keep destructive actions visually distinct and label them with precise verbs.
• Preserve form state through rotation, process recreation and temporary network loss.
• Test touch targets, TalkBack, font scaling, contrast and keyboard behaviour.
• Make scrollable content and fixed action areas work together on small screens.
• Verify loading, error and empty states before the modal reaches production.

Performance also affects perceived quality. Avoid loading a large image or making a network request before the sheet becomes visible. Render the basic surface quickly, show a clear progress state, and load optional content afterwards. This is useful for people travelling through areas with inconsistent coverage, including parts of regional Western Australia and the Northern Territory.

Testing interactions across real devices

Automated UI tests should verify that opening, confirming, cancelling and dismissing the component produce the expected state changes. In Compose, use semantic test tags sparingly and prefer accessible text or roles where practical. For fragments, test lifecycle recreation and ensure that a second instance is not created after a configuration change.

Manual testing still reveals issues that scripted tests miss. Try swiping the sheet with one hand, rotating the device while the keyboard is open, and pressing back at each stage. Check that a tap outside the surface does not accidentally submit a form. Test with slow animations and poor connectivity so timing problems become visible.

Google Play users in Australia use a wide mix of manufacturers, Android versions and screen sizes. A modal that looks fine on a recent Pixel may clip on an older Samsung device or behave differently with a system navigation configuration. Include representative hardware in your test matrix rather than relying only on an emulator.

Clear modal patterns make an app feel calm and dependable. Review each dialog and bottom sheet against the task it supports, remove unnecessary interruptions, and validate the result with accessibility tools and real devices. Then package the components into a small design system so future screens can reuse the same reliable behaviour.