Collecting the StateFlow is sending the initial State

[Kranthi94]

When we call permissionFlow.getMultiplePermissionState(*permissions) and use collect on it it is creating a state flow with an initial value this initial value is getting collected first and then permission dialog is shown to the user based on user action collect is again triggered. In the initial state permission is not granted and if the user also didn't grant the permission then collect block is called with the same permission state as initial state here how to identify these two states inside the collect block the initial state and the user denied state.

[PatilShreyas]

@Kranthi94 It's the original nature of the StateFlow that it always emits the current state. If you're using it for some purpose and don't want first update, just ignore the first emission of the StateFlow.

[Kranthi94]

@PatilShreyas To ignore i need a way to know it but the initiate state and the state when the permission is denied is the same. There is no difference between those two states, so i am finding it difficult to differentiate for ignoring.

[PatilShreyas]

Understood, actually, PermissionFlow is there to solve domain-specific issues and here the problem is occurring because you're using it for UI operations. It's meant for core use case only which only has live knowledge of permission and its state.

For your particular use case, you can do something like

private val permissionLauncher = registerForPermissionFlowRequestsResult { permissionMap ->
    if (permissionMap[Manifest.permission.____] == true) {
        // Permission granted
    } else {
        // Permission NOT granted
    }
}

Since in this case, flow will not give updates since state hasn't changed.

[PatilShreyas]

Meanwhile, I'll also think from an API perspective if something can be done for this as well or not.

[Kranthi94]

Thanks for the quick response

[PatilShreyas]

After thinking a lot from the API perspective, this use case doesn't actually fit for the library. Because the solution on this thread actually solves the issue and there's no need for special API.