Updating MutableLiveData from Coroutines in Kotlin: setValue vs postValue

By the end of this page, you will understand why MutableLiveData.value can only be set on the main thread, how postValue() differs from setValue(), and how to use coroutines safely with LiveData in Android. You will also learn better coroutine patterns than GlobalScope.launch for real projects.

MutableLiveData is designed to hold UI-related state in Android. Because UI state is closely tied to the main thread, LiveData enforces a simple rule:

• Use value / setValue() on the main thread
• Use postValue() from a background thread

In your example, GlobalScope.launch does not guarantee execution on the Android main thread in a way that makes your value assignment safe for all cases. When the coroutine runs on a background thread and you call:

AddressList.value = getAddressList()

that internally calls setValue(), which throws this exception:

IllegalStateException: Cannot invoke setValue on a background thread

This matters because Android UI code must be thread-safe. If multiple threads could directly change UI-observed state without coordination, apps would become unpredictable and crash more often.

The usual solutions are:

• call postValue() from a background thread
• switch to Dispatchers.Main before assigning to value

Think of MutableLiveData like a notice board in a school office.

• setValue() is like walking into the office and pinning a note directly onto the board. You can only do that when the office is open and staff are present — that is the main thread.
• postValue() is like dropping the note into a mailbox. Staff will later take it out and pin it to the board safely — that is a background thread posting work to the main thread.

So if your coroutine is working in the background, you should not walk straight to the board. You should either use the mailbox (postValue) or return to the office (Dispatchers.Main) first.

The two most important ways to update MutableLiveData are:

liveData.value = newValue      // main thread only
liveData.postValue(newValue)   // safe from background thread

Example 1: Using postValue() from a coroutine

val addressList = MutableLiveData<List<Address>>()

fun getAddressesLiveData(): LiveData<List<Address>> {
    addressList.value = emptyList()

    GlobalScope.launch(Dispatchers.IO) {
        val result = getAddressList()
        addressList.postValue(result)
    }

    return addressList
}

Here:

• Dispatchers.IO is used for background work
• getAddressList() runs off the main thread
• postValue(result) safely schedules the update

Example 2: Switching back to the main thread

val addressList = MutableLiveData<List<Address>>()

fun getAddressesLiveData(): LiveData<List<Address>> {
    addressList.value = emptyList()

    GlobalScope.launch(Dispatchers.IO) {
         result = getAddressList()
        withContext(Dispatchers.Main) {
            addressList.value = result
        }
    }

     addressList
}

Consider this example:

val users = MutableLiveData<List<String>>()

fun loadUsers() {
    users.value = emptyList()

    GlobalScope.launch(Dispatchers.IO) {
        val result = listOf("Ana", "Ben", "Chris")
        users.postValue(result)
    }
}

Step by step:

1. users.value = emptyList() runs on the current thread.

   • If called from the UI layer, this is usually the main thread.
   • users now contains an empty list.

2. GlobalScope.launch(Dispatchers.IO) starts a coroutine on an IO/background thread.

   • This is suitable for network or database work.

3. val result = listOf("Ana", "Ben", "Chris")

   • The background work completes and produces data.

4. users.postValue(result) is called.

   • Because this is a background thread, postValue() is the safe choice.
   • Android schedules the LiveData update to happen on the main thread.

This pattern appears often in Android apps:

• API calls: fetch data in Dispatchers.IO, then update LiveData
• Database queries: read from Room or another database in the background and publish results
• File loading: parse files or JSON off the main thread, then notify the UI
• Form validation: compute validation results, then expose them to the screen
• Progress updates: background work posts loading, success, or error state

Example with loading state:

data class UiState(
    val loading: Boolean,
    val addresses: List<Address> = emptyList(),
    val error: String? = null
)

A ViewModel may update this state before, during, and after a request. The key idea stays the same: background work should not directly call setValue() unless you first switch back to the main thread.

In real projects, developers rarely expose a mutable LiveData directly. A common pattern is:

private val _data = MutableLiveData<List<Address>>()
val data: LiveData<List<Address>> = _data

This prevents outside classes from modifying the value.

Common patterns

1. Early loading state

_addresses.value = emptyList()

or a dedicated loading flag:

_loading.value = true

2. Background fetch + main-thread update

viewModelScope.launch {
    try {
        val result = withContext(Dispatchers.IO) {
            repository.getAddressList()
        }
        _addresses.value = result
    } catch (e: Exception) {
        _error.value = e.message
    }
}

3. Error handling

Coroutines often wrap repository calls in try/catch so the UI can observe failures safely.

4. Repository separation

A repository usually fetches data, while the ViewModel updates LiveData:

1. Using value from a background thread

Broken code:

GlobalScope.launch(Dispatchers.IO) {
    liveData.value = fetchData()
}

Why it fails:

• value calls setValue()
• setValue() must run on the main thread

Fix:

GlobalScope.launch(Dispatchers.IO) {
    liveData.postValue(fetchData())
}

or:

GlobalScope.launch(Dispatchers.IO) {
    val result = fetchData()
    withContext(Dispatchers.Main) {
        liveData.value = result
    }
}

2. Using GlobalScope for UI work

Broken idea:

GlobalScope.launch {
    // UI-related async work
}

Why it is risky:

• it is not tied to Activity or ViewModel lifecycle
• it may leak work or update dead screens

Better:

viewModelScope.launch {
    
}

liveData.value = data      // main thread only
liveData.postValue(data)   // background thread safe

Rules

• value and setValue() must run on the main thread
• postValue() can be called from a background thread
• Use Dispatchers.IO for blocking work
• Use Dispatchers.Main for UI state updates
• Prefer viewModelScope over GlobalScope in Android UI code

Common coroutine pattern

viewModelScope.launch {
    val result = withContext(Dispatchers.IO) {
        repository.loadData()
    }
    _liveData.value = result
}

Background-thread alternative

viewModelScope.launch(Dispatchers.IO) {
    val result = repository.loadData()
    _liveData.postValue(result)
}

Good encapsulation

private  _items = MutableLiveData<List<Item>>()
 items: LiveData<List<Item>> = _items

Why does MutableLiveData.value crash inside a coroutine?

A coroutine can run on different threads. If it is running on a background thread, assigning to value calls setValue(), which is only allowed on the main thread.

Should I use postValue() or value with coroutines?

Use postValue() if you are on a background thread. Use value if you are already on the main thread or after switching with withContext(Dispatchers.Main).

Is GlobalScope.launch a good idea for LiveData updates?

Usually no. In Android UI code, viewModelScope is preferred because it is lifecycle-aware and cancels work automatically when the ViewModel is destroyed.

Can I call postValue() on the main thread?

Yes, but it is usually unnecessary. If you are already on the main thread, value is often clearer.

What is the difference between value and setValue()?

They are effectively the same for . is Kotlin property syntax that calls .

• LiveData — the observable data holder that UI components watch for changes.
• MutableLiveData — the writable version of LiveData used inside ViewModels.
• Kotlin coroutines — the async programming tool used to run work without blocking the main thread.
• Dispatchers.IO — used for background work such as network and database calls.
• Dispatchers.Main — used when code must run on the Android main thread.
• viewModelScope — a lifecycle-aware coroutine scope for ViewModels.
• withContext — switches a coroutine to a different dispatcher.
• Android ViewModel — holds UI state across configuration changes.
• Threading in Android — explains why UI-related updates must happen on the main thread.