I want to hide the bottom sheet from inside a ViewModel (after a backend call succeeded). To do this...
l

Lukasz Kalnik

about 3 years ago
I want to hide the bottom sheet from inside a ViewModel (after a backend call succeeded). To do this, I need to emit a
StateFlow
from the ViewModel which contains a boolean property
showBottomSheet
. In my screen's composable, I can then remember (and reinitialize) the bottom sheet state like this:
val modalBottomSheetState = rememberModalBottomSheetState(if (screenState.showBottomSheet) Expanded else Hidden)
That takes care of hiding the bottom sheet. But how do I keep the
showBottomSheet
state in the ViewModel synchronized with the composable, when e.g. the user swipes down the bottom sheet? For this I included a callback in the composable:
onBottomSheetDismissed
. I called this callback in the
confirmStateChange
lambda parameter of `rememberModalBottomSheetState()`:
// Composable

val modalBottomSheetState = rememberModalBottomSheetState(
    initialValue = if (screenState.showBottomSheet) Expanded else Hidden,
    confirmStateChange = {
        onBottomSheetDismissed()
        true
    }
)

// ViewModel

val screenState: StateFlow<ScreenState> = _screenState.asStateFlow()
private val _screenState: MutableStateFlow<ScreenState>

fun onBottomSheetDismissed() {
    _screenState.update { it.copy(showBottomSheet = false) }
}
But it appears that this callback is called very early in the dragging process, and my
showBottomSheet
variable in the ViewModel gets reset to
false
as soon as the user even drags the bottom sheet one pixel down and the bottom sheet immediately disappears (see video in thread) Is there a better way to handle opening/closing the bottom sheet from a viewmodel and keeping the state synchronized between the two?
🧵 1
Hi! Is there a reason why `DefaultDispatcher-worker` threads would keep getting spawned without any ...
j

Julia Samól

about 2 years ago
Hi! Is there a reason why
DefaultDispatcher-worker
threads would keep getting spawned without any limits? I’ve been debugging an Android app which is supposed to run in the background and periodically execute tasks that could be async (the async code uses coroutines). After running the app for long time it looks like the app gets bloated with
DefaultDispatcher-worker
threads (I can see an increasing number of threads in the Profiler and increasing ids of the threads when I print their names) and eventually crashes with the
OutOfMemory
error (it happened once in a coroutine running on a
DefaultDispatcher-worker-739
thread - yes, 739). The coroutine handling in the app is quite poor, yes - that’s what I’m trying to fix, amongst others - and we use mostly the IO dispatcher. The only dependency we use that comes with a suspend interface that I’m aware of is Ktor. There’s also a place where we create a
newSingleThreadContext
and run a coroutine on that single thread. The single thread doesn’t seem to be an issue, though, the context gets closed after it’s no longer needed and I don’t see any zombie threads stacking over time coming from that part of the code. So at this moment it looks like whatever is spawning
DefaultDispatcher-worker
threads is causing the problem. I thought, however, that both
Dispatchers.Default
and
<http://Dispatchers.IO|Dispatchers.IO>
are built on a limited thread pool, so I can’t understand how it could be possible that hundreds of such threads get spawned.