Almost all of us used these approaches before Flow and Compose. However, the main question is:

What is the problem with these approaches?

The main issue is that they cannot prevent sending new requests when a configuration change occurs.

Configuration of android application can change by many ways, such as:

• Screen orientation
• Font size and weight
• Locale
• Dark mode versus light mode
• Etc.

You can find more in here. There is my example:

The example above shows that the app sends requests again when the theme changes. Therefore, if you follow this approach, your app may send multiple requests due to users who frequently change configurations while the screen is open.

How about “init” function of ViewModel?

Yes, it survives configuration changes. However, it creates a dependency on ViewModel creation. For instance, if you want to write a unit test without triggering the initial loading during ViewModel creation, you can’t avoid it because the init function runs as soon as the ViewModel is created.

If this is not an issue for your project or test cases, then in my opinion, this approach is still valid.

3) My Personal Preference 👀

Instead of sending request from Fragment or Compose sides, my choice is fetching data from ViewModel side:

data class ScreenState(
    val text: String = "",
    val counter: Int = 1,
)

@HiltViewModel
class HomeViewModel @Inject constructor() : ViewModel() {

    private val screenState = MutableStateFlow(value = ScreenState())
    val uiState = screenState
        .onStart {
            fetchArticleList(from = "ViewModel")
        }
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted
                .WhileSubscribed(stopTimeoutMillis = 5000L),
            initialValue = screenState.value,
        )

    suspend fun fetchArticleList(from: String) {
        delay(timeMillis = 2000L)

        Log.i("CANER", "--> fetchArticleList from: $from")

        screenState.update { state ->
            state.copy(
                text = "Fetch Data ${state.counter}",
                counter = state.counter + 1
            )
        }
    }
}

Then, UI side can collect state:

val uiState = homeViewModel.uiState.collectAsStateWithLifecycle()

HomeScreen(
    text = uiState.value.text
)

As summary, below gif shows that app does not send a new request when configuration changes. However, app sends a new request when it waits more than 5 seconds on background.

Final result.

More details are that we have screenState as StateFlow which has ScreenState data class with default values. When app would like to collect state in compose function, uiState provides value of screenState. First time, default value of text is empty string. So, we see just “Hello Caner,” text in first time.

Then, onStart function runs. You can call suspend function in onStart. In our example, we can see that screenState is updated in fetchArticleList() function. Thus, uiState provides new value and app shows “Hello Caner, Fetch Data 1”.

Next, gif shows that app goes background and foreground under 5 seconds, so app does not send a request in view model. It is happening because of giving 5 seconds in here: WhileSubscribed(stopTimeoutMillis = 5000L). Basically, if the compose function still subscribed for 5 seconds, the flow provides same result. However, when app waits more than 5 seconds, onStart function re-run. So, app shows “Hello Caner, Fetch Data 2” text.

Because of above explanation, theme changing (one of the configuration change ways) does not trigger screen loading because it happens under 5 seconds.

Hence, 5 seconds are important duration. If your app must need to show fresh data every time, you should not use 5 seconds. There can be zero duration: WhileSubscribed(stopTimeoutMillis = 0L). In this way, you will always have fresh data with screen opening.