Introduction

ProgressDialog was deprecated because it encouraged a blocking, dialog-centric progress pattern that does not fit modern Android UI design. The replacement is not one single class. The better approach is to show progress inside the current screen, or in a lifecycle-aware dialog or notification, depending on what the user is waiting for.

The Usual Replacement: ProgressBar in the Layout

For most screens, the direct replacement is an embedded ProgressBar. Instead of interrupting the whole app with a modal dialog, show a loading indicator near the content it affects.

A simple XML layout might look like this:

1<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
2    android:layout_width="match_parent"
3    android:layout_height="match_parent">
4
5    <LinearLayout
6        android:layout_width="match_parent"
7        android:layout_height="match_parent"
8        android:orientation="vertical"
9        android:padding="16dp">
10
11        <TextView
12            android:id="@+id/statusText"
13            android:layout_width="wrap_content"
14            android:layout_height="wrap_content"
15            android:text="Ready" />
16    </LinearLayout>
17
18    <ProgressBar
19        android:id="@+id/loadingIndicator"
20        style="?android:attr/progressBarStyleLarge"
21        android:layout_width="wrap_content"
22        android:layout_height="wrap_content"
23        android:layout_gravity="center"
24        android:visibility="gone" />
25</FrameLayout>

And in an activity or fragment:

1class MainActivity : AppCompatActivity() {
2    private lateinit var progressBar: ProgressBar
3    private lateinit var statusText: TextView
4
5    override fun onCreate(savedInstanceState: Bundle?) {
6        super.onCreate(savedInstanceState)
7        setContentView(R.layout.activity_main)
8
9        progressBar = findViewById(R.id.loadingIndicator)
10        statusText = findViewById(R.id.statusText)
11
12        lifecycleScope.launch {
13            showLoading(true)
14            delay(2000)
15            statusText.text = "Finished"
16            showLoading(false)
17        }
18    }
19
20    private fun showLoading(loading: Boolean) {
21        progressBar.isVisible = loading
22    }
23}

This pattern is simple, non-blocking, and survives configuration changes more naturally.

Overlay, Inline, or Notification?

The right alternative depends on the task.

Use an inline ProgressBar when loading content already visible on the screen.

Use an overlay spinner when the user must wait briefly before interacting with the current screen.

Use a foreground service notification or system notification when the work should continue even if the user leaves the app, such as a file upload or long-running sync.

For determinate progress, use the horizontal style and update its progress value rather than showing an indeterminate spinner.

progressBar.isIndeterminate = false
progressBar.max = 100
progressBar.progress = 60

If You Still Need a Dialog

Sometimes a dialog presentation is appropriate, but you should use a normal DialogFragment with a custom view rather than ProgressDialog.

1class LoadingDialogFragment : DialogFragment() {
2    override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {
3        val progressBar = ProgressBar(requireContext())
4        return AlertDialog.Builder(requireContext())
5            .setTitle("Please wait")
6            .setView(progressBar)
7            .create()
8    }
9}

This gives you lifecycle-aware dialog behavior without relying on the deprecated API. Even then, use it sparingly. Dialogs should be the exception, not the default loading pattern.

State Management Matters More Than the Widget

A lot of ProgressDialog problems were actually state-management problems. Modern Android code should drive loading state from ViewModel, LiveData, or StateFlow, then let the UI react.

1class MainViewModel : ViewModel() {
2    private val _loading = MutableStateFlow(false)
3    val loading: StateFlow<Boolean> = _loading
4
5    fun loadData() {
6        viewModelScope.launch {
7            _loading.value = true
8            delay(2000)
9            _loading.value = false
10        }
11    }
12}

The fragment observes loading and toggles the progress UI. That architecture is more durable than manually showing and dismissing dialogs from callback chains.

Common Pitfalls

A common mistake is replacing ProgressDialog with AlertDialog and keeping the same blocking UX. That only changes the class name, not the design problem.

Another issue is using a spinner for long background work that should be reported through a notification or work manager flow instead.

Developers also sometimes forget to hide the indicator when an error occurs. Loading state should be cleared in both success and failure paths.

Finally, avoid keeping references to dialogs across activity recreation. Lifecycle-aware UI state is more reliable than imperative show and dismiss calls.

Summary

• 'ProgressDialog is deprecated because blocking dialogs are poor default UX.'
• Use ProgressBar inside the current layout for most loading states.
• Use determinate progress when the work has measurable completion.
• If a dialog is truly needed, prefer DialogFragment with a custom view.
• Drive progress from lifecycle-aware state instead of manual dialog control.