How to manage dependent Kotlin coroutines in Android

You could do this by having the ViewModel monitor when the two tasks are complete and set loading state LiveData variable to indicate that the UI should only update once both tasks are complete. For example:

class MainViewModel : ViewModel() {

    private var completedA = false
    private var completedB = false

    private val dataALiveData = MutableLiveData("")
    val dataA: LiveData<String>
        get() = dataALiveData

    private val dataBLiveData = MutableLiveData("")
    val dataB: LiveData<String>
        get() = dataBLiveData

    private val dataIsReadyLiveData = MutableLiveData(false)
    val dataIsReady: LiveData<Boolean>
        get() = dataIsReadyLiveData

    // You can trigger a reload of some of this data without having to reset
    // any flags - the UI will be updated when the task is complete
    fun reloadB() {
        viewModelScope.launch { doTaskB() }
    }

    private suspend fun doTaskA() {
        // Fake task A - once it's done post relevant data
        // (if applicable), indicate that it is completed, and
        // check if the app is ready
        delay(3200)
        dataALiveData.postValue("Data A")
        completedA = true
        checkForLoaded()
    }

    private suspend fun doTaskB() {
        // Fake task B - once it's done post relevant data
        // (if applicable), indicate that it is completed, and
        // check if the app is ready
        delay(2100)
        dataBLiveData.postValue("Data B")
        completedB = true
        checkForLoaded()
    }

    private fun checkForLoaded() {
        if( completedA && completedB ) {
            dataIsReadyLiveData.postValue(true)
        }
    }

    // Launch both coroutines upon creation to start loading
    // the two data streams
    init {
        viewModelScope.launch { doTaskA() }
        viewModelScope.launch { doTaskB() }
    }
}

The activity or fragment could observe these three sets of LiveData to determine what to show and when, for example to hide the displayed elements and show a progress bar or loading indicator until it is done loading both.

If you wanted to handle error states, you could have the dataIsReady LiveData hold an enum or string to indicate "Loading", "Loaded", or "Error".

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    binding = ActivityMainBinding.inflate(layoutInflater)
    setContentView(binding.root)

    val model: MainViewModel by viewModels()

    binding.textA.visibility = View.INVISIBLE
    binding.textB.visibility = View.INVISIBLE
    binding.progressBar.visibility = View.VISIBLE

    model.dataA.observe(this) { data ->
        binding.textA.text = data
    }

    model.dataB.observe(this) { data ->
        binding.textB.text = data
    }

    // Once the data is ready - change the view visibility state
    model.dataIsReady.observe(this) { isReady ->
        if( isReady ) {
            binding.textA.visibility = View.VISIBLE
            binding.textB.visibility = View.VISIBLE
            binding.progressBar.visibility = View.INVISIBLE

            // alternately you could read the data to display here
            // by calling methods on the ViewModel directly instead of
            // having separate observers for them
        }
    }
}

When you launch coroutines, they return a Job object that you can wait for in another coroutine. So you can launch a Job for 1, and 3 can await it before starting its flow that joins tables.

When working with Retrofit and Room, you can define your Room and Retrofit DAOs/interfaces with suspend functions. This causes them to generate implementations that internally use an appropriate thread and suspend (don't return) until the work of inserting/updating/fetching is complete. This means you know that when your coroutine is finished, the data has been written to the database. It also means it doesn't matter which dispatcher you use for 2, because you won't be calling any blocking functions.

For 1, if parsing is a heavy operation, Dispatchers.Default is more appropriate than Dispatchers.IO, because the work will truly be tying up a CPU core.

If you want to be able to see if the Job from 1 had an error, then you actually need to use async instead of launch so any thrown exception is rethrown when you wait for it in a coroutine.

3 can be a Flow from Room (so you'd define the query with the join in your DAO), but you can wrap it in a flow builder that awaits 1. It can return a Result, which contains data or an error, so the UI can show an error state.

2 can operate independently, simply writing to the Room database by having user input call a ViewModel function to do that. The repository flow used by 3 will automatically pick up changes when the database changes.

Here's an example of ViewModel code to achieve this task.

private val parsedTextJob = viewModelScope.async(Dispatchers.Default) {
    // read file, parse it and write to a database table
}

val theRenderableList: SharedFlow<Result<List<SomeDataType>>> = flow {
    try {
        parsedTextJob.await()
    } catch (e: Exception) {
        emit(Result.failure(e)
        return@flow
    }
    emitAll(
        repository.getTheJoinedTableFlowFromDao()
            .map { Result.success(it) }
    )
}.shareIn(viewModelScope, SharingStarted.WhileSubscribed(5000), replay = 1)

fun onNewUserInput(someTextFromUser: String) {
    viewModelScope.launch {
        // Do query from Retrofit.
        // Parse results and write to database.
    }
}

If you prefer LiveData to SharedFlow, you can replace theRenderableList above with:

val theRenderableList: LiveData<Result<List<SomeDataType>>> = liveData {
    try {
        parsedTextJob.await()
    } catch (e: Exception) {
        emit(Result.failure(e)
        return@liveData
    }
    emitSource(
        repository.getTheJoinedTableFlowFromDao()
            .map { Result.success(it) }
            .asLiveData()
    )
}