architecture-samples | showcase different architectural tools and patterns | Architecture library

Your DAO returns suspend fun getAllUser(): List, meaning it's a one time thing. So when the app starts the first time, the DB initialization is not complete, and you get an empty list because the DB is empty. Running the app the second time, the initialization is complete so you get the data.

How to fix it:

1. Switch getAllUser() to return a Flow:

Not 100% sure, but I would bet you auto-converted the SingleLiveEvent Java code to Kotlin, and it declared it as a subclass of MutableLiveData instead of MutableLiveData.

In my case I had to use

My guess is that mixing Coroutines suspending function with Retrofit and LiveData leads to some side effect here.

I do not have a single solution, but some points they can help you.

In general I would avoid mixing LiveData with suspending functions. LiveData is concept of caching data for the UI/ViewModel layer. Lower layers do not need to know anything like Android concrete stuff like LiveData. More information here

In your repository or dataSource can either use a suspending function that returns a single value or Coroutines Flow that can emit more than one value. In your ViewModel you can then map those results to your LiveData.

DataSource

In your DataSource you can use suspendCoroutine or suspendCancellableCoroutine to connect Retrofit (or any other callback interface) with Coroutines:

yes, you are right. but if you looked up the implementation of the launch {} such in lifecycleScope.launch {} or viewModelScope.launch {} you would find out the "block" which is "the coroutine code which will be invoked in the context of the provided scope" is cast to be suspend, so any block of code between launch {} is suspend code block. so in your example filterItems is cast to suspend under the hood and it's wrapped with viewModelScope.launch{ } to do its heavy task not in main thread.

1. switchMap - The returned LiveData delegates to the most recent LiveData created by calling switchMapFunction with the most recent value set to source, without changing the reference. Doc

2. Yes, it'll keep listening to return the latest result in whole Lifecycle. distinctUntilChanged creates a new LiveData object that does not emit a value until the source LiveData value has been changed. The value is considered changed if equals() yields false.

3. Yes you can use that too but it'll keep emitting the values even the values are the same as the last emitted value. e.g. first emitted value is ["aman","bansal"] and the second is the same ["aman","bansal"] which you don't want to emit since the values are same. So you use distinctUntilChanged to make sure it won't emit the same value until changed.

I hope this helped.

Initiate ViewModel in below method of fragment

Yes, it is absolutely identical because LiveData.map is an extension function that provided from Transformations.kt file that is a part of dependency:

I will paste here the "danysantiago" response in a issue (https://github.com/google/dagger/issues/1972) related to your question:

Hilt ViewModel extension works by declaring modules that bind assisted factories to a map and not by binding concrete ViewModels. Therefore, what you want to do is bind the assisted factory of the concrete ViewModel using the key of the abstract ViewModel so that when HiltViewModelFactory looks up the factory based on class key it uses the assisted factory for the concrete ViewModel. This is suuuper obscure and hence why I mean not 'easily' available.

However, if you can expand on the test case your are trying to write that could help us provide some guidance, I'm not sure if you are trying to mock/fake the ViewModel itself for tests, but Hilt testing APIs should allow you to replace dependencies in the ViewModel so you can write a test with the Fragment and the ViewModel.